Connecting MCP to opencode means adding a server entry to opencode.json so the agent can call that server's tools. For a hosted service, that is a remote server entry: a URL plus whatever headers it needs to authenticate.
What Does a Remote Entry Look Like?
A remote MCP server is declared under the mcp key:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"your-server": {
"type": "remote",
"url": "https://example.com/mcp",
"enabled": true,
"headers": {
"X-API-Key": "YOUR_KEY"
}
}
}
}
The important fields are type: "remote", the url, enabled: true, and the headers object. If your server expects a bearer token instead, use "Authorization": "Bearer YOUR_KEY".
A remote entry is self-contained. opencode reads it on startup, connects to the endpoint, and lists the tools the server advertises. You do not register each tool individually, and the agent picks up new tools automatically when the server adds them. That is the practical upside of a protocol over hand-wired integrations.
How Is This Different From a Local Server?
opencode supports both. A local server runs as a command on your machine — think a filesystem or database tool scoped to your device. A remote server connects over HTTP to a hosted endpoint, which is how a shared platform is meant to be used.
The MCP ecosystem has been moving toward remote servers precisely because they reach more clients. Cloudflare's overview notes that remote MCP is "the missing piece to reach everyone on the Internet," whereas local servers are great for developers but limited to a single machine (Cloudflare).
The shift is measurable. Postman's 2025 State of the API, based on responses from more than 5,700 developers, architects, and executives, reported that MCP is early but gaining momentum as a way to connect non-human callers to tools (Postman).
How Do You Verify It Works?
After saving and reloading opencode, ask the agent a read-only question about the server. For Conbersa, that would be "List my devices." A data response confirms the URL, headers, and tool discovery.
Then test scope. With an API-key server, the agent should only see what that key owns. If it sees more, stop and correct the credential. GitGuardian's 2025 State of Secrets Sprawl found 23,770,171 new hardcoded secrets in public GitHub repositories in 2024, a 25% increase, so leaked keys are common and over-broad ones are worse (GitGuardian).
How Do You Manage Secrets?
The straightforward answer: never commit a config with a live key.
- Keep secret-bearing config out of version control, or use environment-variable references.
- Use one key per integration so a single revocation does not disrupt everything.
- Rotate immediately if the file is exposed.
opencode configs are project-friendly, which is exactly why this matters. A committed opencode.json with an API key is a credential leak, not a convenience.
If your team shares configs, keep a template that contains the structure only and inject the key at runtime. The committed file then carries no secret at all, and each developer supplies their own credential locally.
When Should You Run Multiple Entries?
If a service issues multiple credentials, you can register it more than once. For example, an admin key and a read-only key as two entries let you keep a cautious default (read-only) and opt into elevated access deliberately. It costs a few lines of config and buys real safety.
How Conbersa Works With opencode
The Conbersa MCP server is a remote Streamable HTTP server authenticated with a per-user API key, so it fits opencode's remote entry shape directly. Add https://api.conbersa.ai/mcp with an X-API-Key header, and opencode can operate a real-phone fleet: post across accounts, run engagement, and manage schedules from plain-language instructions. Setup is in Connect opencode to Conbersa.