📘

Looking for user docs on Apps?

If you want to connect existing apps to your copilots, see Apps and MCP instead.

How the Fuel iX MCP ecosystem works

The Fuel iX MCP ecosystem has two components: the Fuel iX MCP Client and the Fuel iX MCP Registry.

The MCP Client is a fully MCP-specification-compliant client built into Fuel iX Copilots. It enables copilots to connect to remote MCP servers, invoke their tools, retrieve data, and execute actions as part of agentic workflows.

The MCP Registry is Fuel iX's curated list of approved remote MCP servers. Servers can be registered at three scopes:

• Public — available to all Fuel iX organizations
• Organization level — available to all users within a specific organization
• Team level — configured for specific teams within an organization

❗

Important

Fuel iX does not develop, operate, manage, host, or maintain MCP servers registered through the Fuel iX MCP Registry. Full ownership and operation of the server remains with you.

The MCP Client is designed for user-initiated interactions within the Fuel iX Copilots UI. It does not support API-based or application-level usage.

Access control and scoping

Understanding how access flows through the platform helps you plan your rollout and set appropriate expectations before submitting.

Access flows through four layers:

1. Fuel iX registers your server and makes it available to one or more organizations based on the scope you request (public, org-level, or team-level).
2. Org admins enable your server within their organization and control which users and/or teams are permitted to add it to their copilots. They can restrict this to a single user, specific teams, a combination, or open it to all org users. This step must happen before any user in that org can configure a copilot with your server.
3. Copilot builders (the users the org admin has permitted) decide whether to add your server to their copilots. A user may build one copilot using your server or several — that's their decision as the copilot owner.
4. Your server's own authentication is the final and most important access gate. Even if a copilot with your server is shared broadly, each user must authenticate individually. Your server controls what data and actions each user can access based on their own credentials and permissions.

What this means for scoping requests: The registration scopes (public, org, team) control who can configure your server on a copilot — not who can ultimately use a copilot that has your server connected. If a permitted user builds a copilot with your server and shares it broadly, any user of that copilot can interact with it. Whether they can retrieve data or take action depends on your server's own authentication.

There is no per-copilot registration scope. If you need to limit access to a narrow audience, request team-level or org-level registration and design your server's authentication to enforce the appropriate data access controls.

❗

Do not rely on Fuel iX configuration to control data access. Your OAuth implementation is the enforcement point. Build your authentication to enforce the right access limits for each user.

What can and cannot be submitted

You can submit:

• Partner or first-party servers: integrations with established platforms (Atlassian, GitHub, Notion, etc.)
• Custom servers: internally developed or third-party tools built for your organization's specific use cases

Fuel iX will not accept:

• Servers that don't meet the technical requirements below
• Servers with unresolved security vulnerabilities
• Servers that haven't been validated using MCP Inspector before submission

Technical requirements

Before submitting, your server must meet these requirements.

Hosting and transport

• Publicly accessible via HTTPS
• Supports Streamable-HTTP transport protocol (SSE is deprecated)
• Responds to MCP protocol handshakes and tool discovery requests
• Provide both a staging URL and a production URL

Authentication

If your server requires authentication:

• Implement OAuth 2.0 with authorization_code grant type (for initial authorization) and refresh_token grant type (for session maintenance)
• Implement Dynamic Client Registration (DCR) if feasible — this simplifies onboarding. If DCR isn't feasible, provide client credentials securely during the registration process
• Configure a session TTL of 60–120 minutes (recommended)

Tool schema

• Each tool must have a clear, descriptive name and description
• Tool input parameter names: alphanumeric characters, hyphens, and underscores only
• Tool names: under 40 characters recommended
• All tool inputs must be validated before execution
• Tools must complete within 30 seconds
• Return structured, parseable responses with clear error handling

Pre-validation (mandatory)

Validate your server using MCP Inspector before submitting. The validation must confirm:

• Successful MCP handshake and protocol compliance
• Correct exposure of tools, resources, and prompts
• Proper authentication and authorization flows
• Stable connectivity and predictable server responses

Fuel iX will not onboard servers that haven't been validated with MCP Inspector.

Submitting your server

Step 1: Gather your server information

You'll need:

• Server name — visible to users in the Apps Marketplace
• Server unique ID — a unique identifier, kebab-case recommended (e.g., my-company-docs)
• Server URLs — staging and production
• Transport type — confirm Streamable-HTTP
• Authentication — specify whether OAuth 2.0 is required; if yes, provide your OAuth endpoints
• Application logo — optional SVG (1:1 square ratio, light and dark mode versions preferred)
• Server type — 1P/Partner or Custom
• Contact information — name, email, and phone for the server owner or maintainer

Step 2: Plan your UAT rollout

Before your server goes live to all permitted users, plan a limited rollout for user acceptance testing. Indicate your UAT approach in your submission.

How UAT works with Fuel iX: The recommended approach is to make your server available to a test organization or a restricted set of users within the target org first. Validate the integration end-to-end before broadening access.

Important — Fuel iX personnel will not have credentials to your server. The Fuel iX team configures your server in the registry and performs compatibility checks, but they cannot perform full end-to-end testing that requires authenticated access to your data or tools. Plan for your own team to conduct E2E testing using real credentials once the server is configured.

In your submission, indicate:

• Whether you want an initial limited rollout before broad enablement, and if so, which users or teams should receive access first
• Your staging URL (the endpoint the Fuel iX team will reference during technical review — this is your server's pre-production endpoint, not a Fuel iX staging environment)
• Your intended production rollout timeline

Step 3: Submit via Fuel iX Ideas

Submit an Idea Request via Fuel iX Ideas with all the information above. Clearly indicate the server type and include your contact details — the Fuel iX team will reach out during review.

Step 4: Review, testing, and onboarding

Once submitted, the Fuel iX team will:

1. Review your submission for completeness and technical compliance
2. Conduct security and compatibility testing
3. Contact you with questions or required clarifications
4. Configure your server in the MCP Registry
5. Perform internal validation

Standard SLA: one sprint cycle (approximately 14 days). Actual timelines may vary based on server complexity or required clarifications.

After your server is registered

Shared responsibility model

Once registered, responsibilities are divided:

Fuel iX is responsible for: maintaining the MCP Registry and client integrations, enforcing platform-level policies, monitoring integration health, and managing server enablement within the platform.

You are responsible for: server uptime, reliability, and performance; authentication and credential rotation; security controls and vulnerability remediation; backward compatibility; and compliance with applicable data protection requirements including TELUS requirements.

Server lifecycle stages

Lifecycle state changes are managed by the Fuel iX team in coordination with you.

Change management

Notify the Fuel iX team in advance of:

• Authentication model changes
• Endpoint or protocol changes
• Tool or resource schema changes
• Planned downtime or maintenance windows

Failure to provide adequate notice may result in temporary restriction or removal from the registry.

Deprecation and removal

Fuel iX may deprecate or remove servers if the server is unmaintained, has unresolved security vulnerabilities, repeatedly fails reliability expectations, or no longer aligns with platform policies. Advance notice will be provided where possible.

Getting started

1. Review the technical requirements in this guide
2. Validate your server using MCP Inspector
3. Prepare your server information and contact details
4. Plan your UAT rollout approach
5. Submit your request via Fuel iX Ideas
6. Collaborate with the Fuel iX team during review and onboarding

For questions about MCP server integration, contact the Fuel iX platform team or submit through Fuel iX Ideas. For general MCP documentation, visit modelcontextprotocol.io.