Time: ~60 minutes
Skill level: Advanced
What you'll have by the end: A custom copilot connected to an external app via MCP, with a working configuration and tested workflows.

What MCP copilots can do

A standard copilot can write, analyze, and reason — but it can't take action in your external tools. An MCP-powered copilot can. Connect it to Atlassian and it can search Confluence, create Jira tickets, and update issue fields. Connect it to Notion and it can read and write pages. Connect it to GitHub and it can interact with repos, issues, and pull requests.

The copilot becomes a working layer between you and your tools — not just generating outputs, but doing things.

Before you start

You need:

• A custom copilot (or you'll create one)
• An account with the external service you want to connect (Atlassian, Notion, etc.)
• The app enabled for your organization by an admin (if you don't see it in your copilot settings, contact your admin)
• Your own authentication credentials authenticated via Profile → Connections

Authenticate your apps first →

Step 1: Clarify what you want the copilot to do (5 minutes)

MCP copilots work best when they're designed around specific workflows. Before you build, define:

• What external service are you connecting to?
• What actions do you want the copilot to take? (Search, create, update, read?)
• What's the trigger — what does the user ask that causes the copilot to use the app?
• What's the output format?

Strong use case: "A project assistant that can search Confluence for relevant documentation, create Jira tickets from action items, and update ticket status — all from a single chat."

Weak use case: "A copilot that's connected to Atlassian." (What does it do with that connection?)

Write a one-sentence description of the workflow your copilot will enable.

Step 2: Create the copilot and connect the app (10 minutes)

1. Click + Create your own copilot in the sidebar.
2. Name it for the workflow: "Jira Assistant," "Project Hub," "Docs & Tickets."
3. Write your system prompt (see Step 3 before you finalize this).
4. In the tools or Apps section, find your target app in the marketplace.
5. Click Add to Copilot.
6. Complete authentication when prompted — use your own credentials for the service.
7. Save your copilot.

Apps and MCP reference →

Step 3: Write a system prompt that uses the app (10 minutes)

Your system prompt should explicitly instruct the copilot to use the connected app for relevant requests. Without this, the copilot may answer from its training knowledge when it should be querying the live system.

Example system prompt for an Atlassian-connected project copilot:

You are a project assistant with access to the team's Atlassian workspace 
(Confluence and Jira).

When users ask about documentation, processes, or existing work — search 
Confluence first and base your response on what you find there.

When users describe a bug, task, or action item — offer to create a Jira ticket. 
Ask for the project key, priority, and assignee before creating.

When users ask about ticket status or details — look it up in Jira.

Always cite the Confluence page or Jira ticket number in your response so 
users can navigate directly.

If you can't find relevant information in the connected systems, say so and 
offer to answer from your general knowledge instead.

Adapt this to your specific app and workflow. The key elements:

• Explicit instruction to use the app for relevant requests
• Guidance on when to use each capability
• What to ask the user before taking action
• How to handle cases where the app doesn't have the answer

Step 4: Test with real scenarios (15 minutes)

Start a new chat and run through the actual workflows you want the copilot to handle. Use real examples:

Test retrieval:

"What does our onboarding documentation say about account setup?"

Does it search Confluence and return relevant content? Does it cite the source page?

Test creation:

"Create a Jira ticket for the login bug we've been discussing. Project is ENG, priority high."

Does it create the ticket? Does it ask for required information you didn't provide?

Test updates:

"Add a comment to ENG-245 saying the fix is deployed to staging."

Does it find the right ticket and add the comment?

Test graceful degradation:

Ask something that isn't in Confluence or Jira.

Does it say it couldn't find it and offer to help another way? Or does it silently answer from training data without telling you?

For each test, check the result in the external system to confirm accuracy.

Step 5: Refine based on what you find (10 minutes)

Common issues and fixes:

Copilot answers from training data instead of querying the app → Make your system prompt more explicit: "Always search [system] before answering questions about [topic]."

Copilot creates tickets missing required fields → Add to system prompt: "Before creating a ticket, always ask for: project key, summary, priority, and assignee."

Copilot cites the wrong page or ticket → Add: "Always include the exact URL or ticket number in your response."

Authentication errors → Go to Profile → Connections, revoke access for the app, and re-authenticate.

Step 6: Share it (5 minutes)

MCP-powered copilots are especially valuable when shared — one well-built copilot can save your whole team from context-switching.

Important things to communicate to people you share it with:

• They need their own authentication. Each user authenticates with their own credentials when they first use an app feature. They only access data they already have permission to see.
• Specific syntax or patterns. If your system prompt works best with specific phrasings, include those as conversation starters.

Sharing guide →

When things go wrong

MCP copilots have more moving parts than standard copilots, so when something breaks it's worth a quick diagnostic before escalating.

Step 1: Check the copilot settings. The most common cause of an app not working is that it simply isn't enabled on that specific copilot. Open settings → Apps and confirm the app is listed. This is a copilot configuration issue — easy to fix, nothing to escalate.

Step 2: Check the thinking tags. When an app tool fails, the error is usually surfaced in the expandable thinking section above the response. Expand it and read the error. Tool errors indicate the app server is having trouble executing — not a problem with Fuel iX itself.

Step 3: Check authentication. If the error mentions authentication or authorization, go to Profile → Connections, revoke and re-authenticate the app. If you've recently changed your password or permissions in the external service, this is the likely cause.

If the issue persists after those three checks, it may be a platform or server issue outside your control. Before escalating, create a support ticket at support.fuelix.ai — even if you're also reaching out to someone directly. The ticket ensures the right team has the detail they need to investigate.

When you file the ticket, include: which copilot is affected, what the user was trying to do, what happened instead, any error messages visible in the chat or thinking tags, and whether others are experiencing the same issue.

📘

"It's not working" isn't enough to diagnose. The more specific you are — which copilot, which action, what error — the faster it gets resolved. A vague escalation without a support ticket typically adds multiple back-and-forth cycles before anyone can help.

Next steps

• Apps and MCP reference — full documentation on app connections
• Scaling a copilot across your team — getting your team to use what you built
• Building MCP servers for Fuel iX — for developers who want to build custom integrations