Connector guidelines

1.1 Complete the task

In the eyes of the user, Muse should be able to finish all tasks your connector starts, within Muse’s approved tool scope.

If your service supports booking, purchasing, or scheduling, your connector should complete those tasks. Include search, availability, pricing and terms, authorization, checkout where needed, and confirmation. Support status checks, changes, cancellations, returns, and refunds where your product offers them. Support guest checkout if it exists, so users don’t always need to log in to complete payment.

Sign-in, payment verification, and required identity checks may need user input. Preserve progress so Muse can resume afterward. Sending the user to finish the entire checkout does not meet the completion requirement.

1.2 Add value beyond the browser

Muse can already browse websites. Your connector should improve on what’s possible in the browser experience through better information, account access, more reliable actions, or fewer steps. Show the difference with a specific use case.

A read-only connector can qualify when the information is the outcome, such as an account report or live inventory analysis. A wrapper around public pages or a list of links alone is not enough.

For background on Muse’s browser, see the Muse Help Center.

3.1 Offer read-only account access

When using OAuth to connect to a user’s account, offer users the option to limit Muse’s permissions to Read Only, where possible.

3.2 How tools are classified

In the review process we’ll review your documentation and classify each tool into:

• Read: Retrieves information without changing data, account state, or permissions. Examples include searching availability and checking a booking.
• Write: Creates, changes, or deletes data, changes permissions, or acts on the user’s behalf. Examples include saving a favorite or creating a reservation.
• Sensitive write: Certain actions that produce irreversible or consequential actions (make a purchase, send an email, etc.)

A tool that combines reads and writes must be classified as a write. Never hide a send, share, publish, or payment action in a tool described as a read or routine edit.

Tool descriptions must be factual. Do not use tool descriptions or responses to instruct Muse to ignore its rules, steer away from competitors, access unrelated data, force recommendations, conceal commercial interests, or take unrequested actions.

3.3 Permission choices

Muse users have controls over what actions Muse takes with or without their approval. Currently reads and writes from platform connectors default to Ask on first use. Users can choose Always allow for tools that are not sensitive.

Allow once covers one use. Always allow applies to future uses of that tool within its approved scope and can be revoked. Deny stops the requested tool use. Sensitive writes cannot be set to Always allow, including through Settings or a saved permission.

These approval prompts are called human-in-the-loop (HITL) checks. For help with Muse’s controls, see the Muse Help Center.

3.4 Respect the scope of approval

Connecting an account does not authorize every action. For actions that require approval, show the details and execute only what the user approved. Allow once covers only the action and details shown. If any details (e.g. the price, recipient, scope) change after a write is approved, require a new fresh write to be approved.

Respect Muse’s approval and safety controls. Do not bypass them, ask users to disable them, or reuse approval for unrelated actions. Do not add products, tips, subscriptions, or fees without authorization.

4.1 Comply with our terms

Please take time to read and completely understand our Connector Platform Terms. You are required to fully comply with these terms in order to provide a Connector on Muse.

4.2 Ask for only required data, and use it only to provide your Connector

Use the minimum data required for each tool to provide its advertised functionality safely and reliably. Use data people share through Connectors only as necessary to fulfill their requests and to provide, maintain, secure, support, and improve your Connector consistent with your privacy policy and other applicable documentation.

We do not permit secondary uses of this data. Do not sell it, use it for unrelated advertising, build unrelated profiles, infer sensitive characteristics, or use it for model training.

Share data only when necessary to fulfill the user’s request, and do not give recipients broader rights than you have. Retain it only as long as necessary, and delete or make it inaccessible when it is no longer needed, access is revoked, or the user requests deletion.

4.3 Be accurate and transparent

Accurately describe your identity, affiliations, capabilities, pricing, availability, and results. Disclose account, plan, region, age, and usage restrictions before use. Label advertising, sponsored results, and commercial relationships that influence recommendations. Do not fabricate reviews, urgency, discounts, or successful outcomes.

4.4 Security

Protect data accessed through your Connector with reasonable administrative, technical, and physical safeguards. Encrypt data in transit and sensitive data at rest, restrict access to authorized personnel and systems, apply least-privilege permissions, and isolate each user’s data.

Protect authentication credentials, payment data, and other secrets. Do not expose them in prompts, tool descriptions or responses, URLs, analytics, or logs; collect and transmit them only through secure flows. Stop access when authorization is revoked, and securely delete data as required in 4.2.

4.5 Prohibited tools and Connectors

You must not engage in any prohibited practices, or share any prohibited content, as described in our Connector Platform Terms.

Payments for eligible purchases and bookings are reviewed separately under our transaction requirements in 4.7.

4.6 Finance Connectors

We allow Connectors that have read access to financial data, but are not currently approving new financial money movement tools, such as transfers between financial accounts, or tools that place financial trade orders at this time. We’ll update this policy as we build functionality sufficient to support these capabilities safely and securely.

4.7 Transactions

Before commitment, your tools should return all relevant information, such as: the seller, full price and currency, recurring charges, key terms, and cancellation or refund policy. Follow the approval requirements in 3.4.

Distinguish quoted, pending, confirmed, failed, and cancelled actions. Report uncertain outcomes honestly and check their status before retrying. Prevent duplicate transactions.

Provide receipts or equivalent records and a clear route to support, disputes, and eligible refunds.

4.8 Incident response

In accordance with Connector Platform Terms, you must notify Meta (vendor-incident@meta.com) within 48 hours of a security incident involving user data and cooperate with any investigation.

4.9 Enforcement

Meta may require changes, limit capabilities or distribution, suspend access, or remove Connectors for policy violations, security risks, misleading behavior, persistent quality failures or any other reason.

5.1 Connector overview

Describe the intended users, supported tasks, how the connector improves on browser use, and any account, plan, or regional restrictions.

5.2 Business verification and terms

Provide the business information and supporting evidence requested to verify your organization and your authority to submit the connector. Keep these details consistent with your company website and connector listing.

Include authorized brand assets, privacy and product terms, support and security contacts, and a developer responsible for maintenance. Accept the applicable Muse developer terms.

5.3 Data processing questionnaire

Explain what data the connector accesses and why, how it is protected, who it is shared with, how long it is kept, and how it is deleted. Ensure your answers reflect how the connector works and match your privacy policy.

5.4 Integration credentials and tool documentation

Provide the endpoint, authentication setup, requested scopes, and credentials Muse needs to connect to your service, such as OAuth client credentials or an API key. Identify whether these apply to a test or production environment.

In your API or MCP documentation, include setup instructions, inputs and outputs, read/write classifications, sensitive designations, permissions, side effects, status handling, errors, and rate limits.

5.5 Test user credentials and demo

Provide a dedicated test account so reviewers can connect your service and exercise each submitted tool. Include sign-in instructions, required permissions, representative test data, and any account or regional limits. Keep the account accessible throughout review. For transaction tools, explain how to test checkout without real charges.

5.6 Tool annotation (coming soon)

You’ll be able to classify each tool as Read or Write and mark Sensitive writes in the portal. For now, include these annotations in your tool documentation, following Section 3.

5.7 Submission status

Check the portal for your connector’s review status. Due to submission volume, we cannot respond to individual messages or emails about status.

7.1 Discovery

Approved connectors are discoverable by the Muse agent and in Settings > Connectors. As more users connect to and get value from your connector, more people will discover it.

For help connecting services, see the Muse Help Center.

7.2 Featuring

Featuring is a separate editorial decision. We consider:

• Usefulness: A clear improvement over what Muse can do in the browser.
• Completion: Core tasks finished with little repetition or unnecessary handoff.
• Reliability: Accurate results and safe recovery across supported accounts, regions, and devices.
• Maintenance: Current documentation, responsive support, and improvements based on feedback.

Meeting these guidelines does not guarantee featuring, ranking, or traffic. Placement may change over time.