How to Use MCP in OpenCode Without Eating Into Your LLM Context Window

OpenCode has recently gained significant popularity in the open-source space. It’s an alternative to Claude Code.

But what if I told you could 100x your Opencode experience with just one MCP? Yes, with Composio Connect, that’s totally possible.

After building a thousand managed MCP integrations and speaking with countless users, we found that while MCP is a force multiplier, it still has physical limitations.

Adding even a single GitHub server will take 20k tokens from your LLM's context window; adding Jira/Linear, Supabase, etc., will essentially choke the models.

This is what an MCP gateway is for

The fix isn't to install fewer MCP servers. It's to stop installing them one at a time in the first place.

An MCP gateway sits between your AI client (OpenCode, Claude, Cursor, whatever you're using) and the actual tools you want to call. Instead of wiring each MCP server directly into your client — and paying the context-window cost for every one of them — you connect to a single gateway endpoint that brokers access to all of them. Tool discovery, authentication, and execution all happen at the gateway layer. Your client only sees the tools it actually needs for the task in front of it.

Composio MCP gateway is what we've built around this idea. One endpoint for 1,000+ managed integrations behind it, and a small set of meta-tools exposed to the client, so the context window stays clean no matter how many apps you connect.

Specifically, here's how Composio handles it:

• Exposes only a few meta tools (Search, Planner, Remote Workbench, etc.) instead of loading every available tool upfront

• Search tool fetches only relevant tools from Composio-managed apps when the agent needs them, keeping the LLM's context space clean

• Remote Workbench handles complex issues by chaining multiple tools together programmatically

• Large artefacts aren't dumped into context — Rube stores them in a file system and fetches results only as needed

Here in this blog post, I’ll walk you through how to set up Composio MCP with Opencode. You can add any other remote MCP the same way.

You can also use the CLI for connecting any apps to OpenCode.

Connect external apps with OpenCode

1. Add the Composio MCP server

   opencode mcp add

   This launches an interactive prompt.

2. Fill in the fields

   Field	Value
   Name	composio
   Type	remote
   URL	https://connect.composio.dev/mcp
   Require OAuth	Yes
   Have client ID	No

Alternatively, you can skip the interactive prompt and paste the configuration directly into your OpenCode config file.

Open your global OpenCode config:

open ~/.config/opencode/opencode.json

Add this under the mcp key and save the file.

{
  "mcp": {
    "composio": {
      "type": "remote",
      "url": "<https://connect.composio.dev/mcp>",
      "enabled": true
    }
  }
}

3. Authenticate

Authenticate Composio MCP you just added

opencode mcp auth composio

This will open a browser session, authorise Composio, and you’re done

4. Verify Installation

opencode mcp list

5. Connect any app with OpenCode

Now, in the chat, ask the agent to connect to Gmail (or any app) or give it any Gmail-related task.

For example, ask it to:

• "Summarise unread emails from this morning"

• "Create draft replies to urgent messages"

• "Fetch contact details for recent senders"

It will prompt you to authenticate and authorize access to Gmail.

That is it. Composio tools are now available in Cursor, and your Gmail account is ready to use.

Some use cases

1. Using OpenCode to automate Code Review & Update

For the 1st task, we will ask OpenCode to find bugs across all files in a code repository, prepare a report, and send it to Gmail. (can use Slack as well)

Paste the following prompt:

Act as an autonomous code auditor. Given access to a source code @ repository, recursively scan all files, detect bugs, vulnerabilities, logical errors, performance issues, and bad practices, classify them by severity, suggest concrete fixes, and generate a structured report (summary, critical issues, file-wise findings, recommendations). Use Rube MCP to handle the Gmail task and send the full report to devloper.hs2015@gmail.com. At the end, output a concise execution summary of all tasks completed. Prioritize real execution over explanation; keep results actionable and production-ready.

In simple terms, the prompt asks the LLM to review the codebase, identify bugs, generate a summary, and email it to the user. The output should include a summary and a link to email. And all this should be done using rube’s Gmail tool.

And here’s the Output it generated:

Note: you may need to login to Gmail, if using first time.

For simplicity, the report is kept short. Feel free to expand it using a format you prefer.

Now let’s look at the 2nd use case!

2. Using Composio MCP to handle Supabase Database for Apps

For the next task, let’s ask OpenCode to handle creating the Supabase database using Composio MCP for a vehicle parking management app.

Paste the following prompt:

Build a minimal Parking Management System using Python, Supabase, HTML, and CSS with a Google Material Minimal aesthetic.

Project Setup
Create a new folder named `vms` and build the entire application inside it.
Create a `.venv` using `python3` and activate it before installing dependencies.
Use Supabase project ID: `<supabase-project-id>`.

Phase 1: Database Setup (via rube_mcp)
Use rube_mcp to create database `parking-system` and models:
User(id, name, email, created_at)
Admin(id → User.id, role, created_at) [predefined]
ParkingLot(id, name, location, total_spots)
ParkingSpot(id, lot_id → ParkingLot.id, spot_number, is_available)
Reservation(id, user_id → User.id, spot_id → ParkingSpot.id, start_time, end_time, status)
Establish all relationships and seed: 1 Admin, 3 ParkingLots, 10–15 Spots per lot, 5–10 Users, 8–12 Reservations.

Constraints
All Supabase operations via rube_mcp, production-ready code, env vars for secrets, clean error handling.

We prompt the LLM to create a parking system model and define the relationship, and then pull in mock data defined in Supabase’s student-db using crud api’s.

Here is the output:

OpenCode defined the task and worked on it incrementally, while Rube handled the heavy lifting.

3. Using Composio MCP to generate a Build Log-based Social Media Post for X

For the final task, we will ask OpenCode to draft us an X/Twitter thread by analysing the entire project (handled by OpenCode) and save it to Notion
Here is the prompt:

Analyze the entire @vehicle-parking-app project to identify its key 
problems, milestones, and achievements. Then, write a 5-tweet 
engaging X(Twitter)thread using a problem–solution narrative. 
The first tweet should hook readers, and the last should include 
a call-to-action. Keep each tweet under 250 characters, separated 
with "1/". Use only bold or italic formatting (no headings or code). 
Save the final formatted thread to the Notion page at {your notion doc}

The prompt asks OpenCode to analyse the project, identify its key problems, milestones, and achievements, use them to generate an engaging X thread based on the given instructions, and save it to the given Notion sheet.
How it worked out for me:

• It launched its subagents to focus on analysing the project

• while the Rube MCP performs the notion page retrieval,

• Then use the results of the subagent to generate the thread and

• Add it to the given Notion page

But so far, we have looked at individual use cases. OpenCode + rube combination can do more. Let’s give it a final challenge!

End Note

The opening claim was that one MCP could 100x your OpenCode experience. The reason it's true isn't magic — it's that the bottleneck in agentic coding isn't model capability anymore,

it's how much useful context you can fit alongside the task. Loading every tool you might need into the context window was the wrong abstraction. A gateway that exposes a few meta-tools and fetches the rest on demand is the right one.