DEV Community: Composio

Top Skills & Plugins to use with Grok Build 2026

Developer Harsh — Thu, 30 Jul 2026 13:39:35 +0000

xAI released Grok Build in May, and it’s been improving steadily since then.

With support for spawning up to 8 parallel subagents and a recently added system for skills and plugins, Grok is now a full-fledged ecosystem that rivals contenders like Claude Code and Codex.

However, unlike Claude or Codex, Grok comes with a superpower - it can scrape X data, the real-time engine behind every major announcement, quality content, trends and conspiracies, all with your X subscription.

This gives Grok Build a unique edge for research-heavy workflows. You can track launches as they happen, pull insights from real conversations, spot emerging trends, and turn that live context into apps, agents, or automated workflows.

Access to real-time data is only one part of the equation, though. To make that information useful, Grok needs the right tools to search, process, design, code, and take action across different platforms.

But with so many options in place for a single need, it's hard to find the right one.

This guide aims to cover which ones are worth installing on your first install, why to install them, and how to install them.

Let’s begin with a quick refresher on what skills and plugins are and why you should install them.

What are Skills & Plugins & Why They Matter

The concept of skills and plugins is not new, yet people still often interchange them. Both extend the capabilities of Grok Build and are related but not the same.

Skills are small, reusable instruction packs (usually a SKILL.md plus optional scripts) that turn Grok into a consistent specialist.

They eliminate repetitive, long prompts, enforce high-quality practices such as TDD or careful planning, reduce token waste through focused behaviour, and deliver the same reliable results across projects.

On the other hand;

Plugins are larger, one-command packages that bundle one or more skills with MCP servers, automation hooks, sub-agents, and platform integrations, giving Grok real superpowers.

With plugins, Grok Build can do live web research, control browsers, perform database operations, analyse production errors, and enable seamless deployments.

This is essential for complex agentic workflows and is easy to install, adopt, and share.

With that clarification done, let’s look at how to install skills and plugins in Grok Build before looking at some of the best skills and plugins you should check out/install first.

Related: Best OpenCode Skills

How to install Skills & Plugins in Grok Build

kills

The Official ones listed on the marketplace can be accessed using /marketplace inside Grok Build itself.

Or you can try manual placement

Put skills in ./.grok/skills/ or ~/.grok/skills/

or add an extra path in the ~/.grok/config.toml under [skills] .

Plugins

Grok Plugins can be installed using:

 grok plugin install <name> --trust

and then verify the plugin by doing /plugin .

If it fails, use the Grok Build Marketplace to add it as a plugin.

Or you can add extra paths in ~/.grok/config.toml under [plugins]

For both skills and marketplace, Grok Build comes with automatic compatibility support for .claude/skills and agent/skills. Just put skills there and let grok build pick it up.

Alternative

For non-official skills packs like skills.sh use:

npx skills@latest add <skill>

We will use any one of the methods listed going forward. Now time to look at top skills and plugins.

Top Skills to Use with Grok Build CLI in 2026

These are the top skills I would install if I reinstall Grok Build. Most of them still live in my workspace.

1. Composio CLI: Power Grok with 1000+ apps from GitHub, Linear, to Figma, Canva.

Composio provides Grok Build with access to more than 1,000 applications via a single remote MCP connection. Instead of loading every integration action into the model’s context, it exposes seven meta-tools that let the agent find tools, initiate authorisation, and execute actions when needed.

This makes it useful for workflows involving applications such as GitHub, Linear, Jira, Figma, and other external services. When an application has not been connected, Composio can generate an OAuth authorisation link for the user.

You can install Composio using:

grok mcp add --transport http composio https://connect.composio.dev/mcp

Then type /mcp , select Composio and complete the OAuth flow.

Note: In WSL you can’t access the browser directly, so copy-paste the produced URL and configure it.

Alternatively;

You can type /mcp inside Grok Build, in the mcp window press a to add a new mcp. Add the https://connect.composio.dev/mcp and initiate the OAuth flow

Or install the Composio CLI directly. It's a CLI for everything Composio that can handle authentication management, tool calling, bash scripting and everything in-between.

This gives a more composable way for Grok CLI to work with Composio toolkits.

You can install it with:

curl -fsSL https://composio.dev/install | bash
composio login

Complete the OAuth flow and then add the composio-cli skill

composio --install-skill composio-cli claude

This ensures that composio-cli, used by Grok Build, follows the correct instructions and doesn’t hallucinate.

The reason I put this one at the top is because , it offers the skill, plugins and mcp all bundled together under one ecosystem, so one time config is all you need.

2. Matt Pocock Skills: Add disciplined planning, TDD, debugging, and handoff workflows.

Matt Pocock Skills adds proper engineering discipline to Grok Build.

Similar to superpowers, it helps the agent plan more effectively, avoid common failure modes, and follow structured processes rather than jumping straight into code.

It includes practical skills like /grill-me for questioning plans, /tdd for test-first development, /diagnosing-bugs for testing hypotheses before fixing, and handoff for clean session transfers.

This is still one of the highest-signal skill packs available across coding agents and one of my favourites.

You can install Matt Pocock Skills using:

npx skills@latest add mattpocock/skills

Then run /setup-matt-pocock-skills once inside Grok Build so it learns your project conventions.

Related: Top Codex Skills

3. Caveman: Cut token waste with terse, high-signal agent responses.

Caveman is an answer for those who want to reduce token waste on long sessions. It forces Grok to drop the unnecessary politeness and over-explanation that usually appears in agent responses like Claude Code, Codex, and so on.

In practice, it can cut output length by roughly 65% on average (ranging from ~22–87% depending on the task) while keeping the useful content intact. It's a small skill but one worth keeping enabled almost all the time.

You can install Caveman using:

npx skills@latest add JuliusBrussee/skills --skill caveman

Once installed, toggle it with: /caveman or by saying "talk like caveman"; turn it off with "normal mode."

Companion commands include

/caveman-commit (terse commit messages),
/caveman-review (one-line PR comments), and
/caveman-stats (session savings).

4. Whathappened: Turn real-time X conversations into structured briefings.

If you are X-savvy or want real-time information about X in a structured way, what happened is the answer.

WhatHappened turns real-time X data into clean, structured briefings rather than raw noise, summarises what happened, maps public opinion, surfaces live debates, and pulls key receipts, all using Grok’s built-in X tools.

Note : This skill only works properly inside Grok Build.

You can install whathappened using:

npx skills add kunchenguid/whathappened

and then use: /whathappened <query>

5. XActions Skills: Scrape, monitor, and automate X workflows without the official API.

XActions takes whathappend ability to the next level by doing more than just reading X. It packages scraping, monitoring, and automation capabilities into ready-to-use agent skills.

You can scrape profiles, followers, threads, monitor accounts, or run simple automation tasks without needing the official X API. This is one of the cleaner ways people have begun to package Grok’s X advantage.

You can install XActions Skills by cloning the repository and placing the skills you want under your skills folder:

git clone <https://github.com/nirholas/XActions

Then copy the relevant skill folders into ~/.grok/skills/ or your project’s .grok/skills/.

6. Wangnov/grok-skills: Combine web/X research with image, video, and ffmpeg workflows.

Haven’t tried it yet, but on my to-do list.

Wangnov/grok-skills is especially useful when your workflow needs both research and media generation. It combines web and X research with image generation, video generation, and basic ffmpeg post-processing.

Everything runs through a logged-in Grok session, so you avoid extra API costs for media tasks. It’s a practical all-in-one skill for research-plus-assets work.

You can install Wangnov/grok-skills using:

npx skills add Wangnov/grok-skills

You can learn more at: https://github.com/Wangnov/grok-skills

7. Agentic-Code-Review & Repo-Health-Check: Review code and understand unfamiliar repos safely.

These two skills from the awesome-grok-build starter kits are especially useful for properly reviewing code and getting oriented in unfamiliar repositories.

agentic-code-review focuses on correctness, security, tests and regression risk. repo-health-check helps you quickly understand a new codebase and propose the smallest, safe-first change. Both work well with Plan Mode.

You can install them by cloning the community kit and copying the skill folders:

git clone <https://github.com/DominikTobureto/awesome-grok-build>

Then place the skill folders into your .grok/skills/ directory. Learn more at: https://github.com/DominikTobureto/awesome-grok-build

### 8. GodotPrompter: Give Grok better Godot, GDScript, scenes, and signal context.

If you are building games with Godot and want Grok Build to understand Godot-specific patterns, project structure, and common workflows.

It gives the Grok/Cursor agent better context around GDScript, scenes, signals, and Godot conventions so the suggestions stay more accurate and less generic.

This is one of the cleanest game-engine-focused plugins currently available for Grok Build.

You can install GodotPrompter using:

grok plugin install jame581/GodotPrompter --trust

Then enable it with:

grok plugin enable godot-prompter

Learn more at: https://github.com/jame581/GodotPrompter

9. Hyperframes: Create and edit programmatic videos with HTML, CSS, and JavaScript.

Hyperframes is for those who want a Grok Build or similar agent to create and edit videos using HTML, CSS, and JavaScript rather than traditional timeline editors.

It ships a full set of agent skills that teach the correct patterns for planning compositions, writing valid HyperFrames HTML, adding animations, linting, previewing and rendering.

The main entry skill is /hyperframes, which routes “make me a video” requests to the right workflow.

You can install Hyperframes skills using:

npx skills add heygen-com/hyperframes

and use it with /hyperframes in grok build. Learn more at: https://hyperframes.heygen.com/

10. Remotion Skills: Build production-ready motion graphics and videos with React and TypeScript.

Remotion is similar to Hyperframes in that it allows you to create motion graphics and programmatic videos using React and TypeScript.

It teaches the agent Remotion best practices like compositions, animations, sequencing, rendering and project structure

This makes the output clean and production-ready, rather than generic React code that happens to render video.

You can install Remotion Skills using:

npx skills add remotion-dev/skills

You can learn more at: https://www.remotion.dev/docs/ai/skills

Note: Remotion skill work best inside an existing Remotion project, so better first create it.

Related: Top Design Skills

Top Plugins to Use with Grok Build

Skills are great; some even perform tasks, but for a seamless experience, plugins are mandatory. These are the ones that still reside directly in my skills.

11. Firecrawl: Search, scrape, crawl, and extract clean data from websites.

Firecrawl is especially useful for research, document retrieval, competitive analysis, and data collection from websites.

It gives Grok Build live access to the web through search, scraping, crawling, website mapping, structured extraction, and browser interaction.

It can render JavaScript-heavy pages, handle common anti-bot restrictions, and return content as clean Markdown or structured data.

You can install Firecrawl using:

/marketplace

Then search for firecrawl and press i to install it.

Note: Firecrawl may request authentication when you first use its hosted MCP server.

12. Superpowers: Add structured engineering workflows for planning, TDD, and debugging.

Superpowers is for those who want their agent to plan carefully, validate its work, and follow a more disciplined development process instead of immediately generating code.

It adds structured software engineering workflows to Grok Build, and the current implementation includes test-driven development, systematic debugging, collaboration patterns, and repeatable engineering processes.

I personally use this before switching to Matt Pocock's skills.

You can install it with:

grok plugin install superpowers --trust

Note: Review the plugin before using --trust, since that option skips the interactive trust prompt.

13. Exa: Get fast, high-quality agent-oriented web search results.

Exa provides fast, high-quality agent-oriented search. It works particularly well as a complement to Firecrawl.

Exa's API is purpose-built for LLMs, so results come back structured and filtered rather than cluttered with ads and navigation, fast enough for an agent to search mid-task without breaking flow.

For teams, that means less time and token spend per lookup, so search-heavy steps (competitor checks, source verification, quick fact lookups) stop being a bottleneck inside the coding session itself

Use Exa for quick, accurate retrieval, and switch to Firecrawl for full-page scraping or site crawling.

You can install the Exa plugin using:

/plugin

Then search for exa and press ito install it.

14. Vercel: Let Grok manage deployments, environment variables, logs, and domains.

Vercel is for those who want their agents to deploy their projects on the Vercel platform. It gives Grok direct control over deployments, environment variables, build logs, and domains.

It also keeps Grok aware of current Vercel features, which reduces outdated suggestions.

For teams, this pairing of live platform knowledge with real deploy/env/log access leads to fewer review cycles spent catching agent suggestions that no longer reflect how Vercel actually works.

This fixes a common issue with agent integrations: context drift.

You can install the Vercel plugin using:

/plugin

Then search for vercel and install it using i .

15. Cloudflare: Build and deploy Workers, Durable Objects, and edge apps with platform-aware guidance.

Cloudflare is for those scenarios when part of your stack lives on the other side of the world. It provides skills for Workers, Durable Objects, and related Cloudflare tooling.

The plugin covers the entire Cloudflare developer platform: Workers, Durable Objects, the Agents SDK, MCP servers, Wrangler CLI, and web performance, functioning as a skill library that maps Cloudflare concepts directly to prompts.

This makes scaffolding and deploying edge projects noticeably smoother inside Grok Build for business and working with it easier.

You can install Cloudflare skills or plugins using:

/plugin

Then search for cloudflare and install it using i

Note: Don’t get confused by the name, if you go to official repo , its given as a plugins.

16. Chrome DevTools: Debug frontend issues through live browser inspection, traces, and network data.

Chrome DevTools is useful for frontend debugging and performance work. It lets Grok control a live browser session. (not on WSL)

You can record performance traces, inspect network requests, evaluate JavaScript, and take DOM snapshots without leaving the agent workflow.

Under the hood, this runs on the official Chrome DevTools MCP server, which lets a coding agent control and inspect a live Chrome browser and acts as a Model Context Protocol server, giving the assistant access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.

This means that instead of an engineer manually opening DevTools, reproducing the issue, and reporting back what they saw, Grok can drive the same browser session directly and return a trace, a failing request, or a DOM state as evidence.

You can install the Chrome DevTools plugin using:

/plugin

Then search for chrome-devtools and install it using i

Related: Top Claude Code Plugins

17. Sentry: Pull production errors and stack traces into Grok for faster fixes.

Sentry closes the loop between local development and production.

It lets Grok pull real error data and stack traces. Combined with Seer-powered analysis, it helps turn production issues into concrete fixes faster.

This works through Sentry's official Grok plugin, which connects Grok to Sentry via the Sentry MCP server, providing real production issue-debugging context, code review with Sentry data, and monitoring configuration- on top of SDK setup for any platform.

This means less engineer time spent context-switching between logs, code, and chat to reconstruct what broke, and a shorter gap between an alert firing and a fix landing.

You can install the Sentry plugin using:

/plugin

Then search for sentry and install it. Part of the official Grok Build Marketplace.

18. Unity MCP + CLI: Drive the Unity editor and iterate on game projects from Grok.

If you are like me and like to build games in Unity and want Grok Build to actually drive the editor and project instead of just writing C# in isolation.

People are already using this combination to let Grok open scenes, modify GameObjects, work with the Asset Store, and iterate on playable prototypes much faster. It is currently one of the most practical ways to pair Grok Build with Unity.

You can set it up by installing the Unity MCP server and connecting it through Grok’s MCP system, then pairing it with a simple Unity-focused skill that teaches the agent your project conventions.

2. In Unity, open Package Manager → Add package from git URL

https://github.com/CoderGamester/mcp-unity.git

After the package is installed, open Tools → MCP Unity → Server Window and click Force Install Server.

Then connect it to Grok Build with:

grok mcp add unity

Note: There is no single official marketplace plugin yet. Most people combine the Unity MCP with grok build and a lightweight custom skill for best results.

Conclusion

Skills give Grok better judgment and consistency. Plugins give Grok real tools and reach, but don’t install them all at once.

Start with a solid foundation:

Cross-app workflows: Composio CLI or MCP
Engineering discipline → Matt Pocock Skills + Superpowers
Token control → Caveman
X advantage → what happened or XActions
Web power → Firecrawl + Exa
Game development → GodotPrompter or Unity MCP setup

Then add the platform plugins that match the work you actually do (Vercel, Cloudflare, Sentry, etc.).

Use both skills and plugins, but do it with a clear understanding of the use case. Only then does Grok Build start to feel like a real system instead of just another coding agent.

Sources

Official docs: https://docs.x.ai/build/features/skills-plugins-marketplaces
Plugin Marketplace announcement: https://x.ai/news/grok-plugin-marketplace
Firecrawl roundup: https://www.firecrawl.dev/blog/best-grok-plugins
Matt Pocock Skills: https://github.com/mattpocock/skills
Superpowers: https://github.com/obra/superpowers
whathappened: https://github.com/kunchenguid/whathappened
XActions: https://github.com/nirholas/XActions
Wangnov/grok-skills: https://github.com/Wangnov/grok-skills
awesome-grok-build: https://github.com/DominikTobureto/awesome-grok-build

What Actually Is an MCP Gateway?

Sunil Kumar Dash — Tue, 28 Jul 2026 14:21:38 +0000

Every team that connects agents to real tools hits the same wall at roughly the same time. It usually looks like a Slack message: "Who has the Jira token?"

Here's what's underneath that, and what a gateway does about it.

The N×M problem

You have N agents and M tools. Connect them directly, and you get N×M integrations. Each one carries its own credentials, its own auth flow, its own error handling, its own version drift.

Three agents and four tools is twelve connections. Ten agents and twenty tools is two hundred. Nobody plans for that number — you arrive at it one integration at a time.

A gateway collapses it to N+M. Agents connect once to the gateway. The gateway connects once to each tool.

Before:  agent ──┬──> GitHub
                 ├──> Slack
                 └──> Jira        (× every agent)

After:   agent ──> gateway ──┬──> GitHub
                             ├──> Slack
                             └──> Jira

What an MCP gateway actually does

Routing and aggregation — one endpoint fronting many MCP servers, with tool filtering so agents don't blow past context limits
Authentication — holds credentials centrally, runs OAuth flows, passes through per-user identity
Authorisation — who can call which tool; RBAC, allowlists, blocking destructive actions
Audit — logs every call: user, tool, action, outcome, including denied ones
Threat handling — tool poisoning, rug-pull updates, cross-server shadowing, prompt injection via tool descriptions
Reliability — rate limits, retries, timeouts, absorbing schema drift when upstream APIs change

The threat handling deserves a note, because it's genuinely new. Tool descriptions are input the agent trusts. A server can change its tool definitions after you've approved it. Generic API security doesn't cover this, and most gateways describe their handling of it vaguely.

Gateway ≠ server ≠ client

Constantly confused, so:

Client — the agent (Claude, Cursor, ChatGPT)
Server — the thing exposing tools over MCP
Gateway — sits between them, governs the traffic

And it's not an API gateway. An API gateway routes HTTP between services. An MCP gateway is protocol-aware — it understands tools and tool-call semantics, which is what lets it enforce per-tool policy.

The landscape splits four ways

Purpose-built managed

Built for MCP from the start. They differ mainly in whether they also supply the tools.

Composio MCP gateway — 1,000+ managed integrations behind per-team scoped endpoints. SCIM, action-level blocking, exportable audit. Managed, VPC, or self-hosted.
TrueFoundry — one control plane for LLM and MCP traffic. Publishes <5ms p95 overhead. Bring your own servers.
Lunar MCPX — granular RBAC, immutable audit, centralised secrets. ~4ms p99. Open source core.
MintMCP — governance-first. SOC 2 / HIPAA / GDPR log formats, SCIM-driven bundles, per-agent identity. BYO servers.
Operant AI — runtime security rather than routing. Scans servers, maps threats to OWASP, catches shadow MCP usage on dev machines.
StackOne — per-user OAuth into HRIS/ERP/CRM, plus meta-tools that keep you under client tool-count caps.

Open source / self-hosted

You run it, you own it. No licence cost, real operational cost.

Obot — multi-role RBAC, curated server catalogue, composite servers. Names MCP-specific threats explicitly, which most don't. Kubernetes or Docker.
Docker MCP Gateway — one container per server with signed images and resource limits. Security via isolation rather than policy. 50–200ms overhead, and no built-in RBAC or audit.
Microsoft MCP Gateway — MIT, Kubernetes-native, session-aware stateful routing. Genuinely useful plumbing; tightly coupled to AKS in practice. Not to be confused with Agent 365, which is a different product with a similar name.
IBM ContextForge — Apache 2.0. Federates MCP, A2A, REST and gRPC through one endpoint, 40+ plugins, OTel tracing. Broadest scope here; also the heaviest lift.
MCPJungle — gateway and registry in one lightweight package. Basic RBAC, minimal ceremony.
Lasso — open-source, security-first. Server reputation scanning and PII redaction, at 100–250ms.

API gateways extended

If you already run one, MCP becomes another middleware in a chain you understand.

Kong — Agent Gateway (3.14, April 2026) covers LLM, MCP and A2A on one runtime. Autogenerates MCP tools from existing REST endpoints, which is the shortest migration path if your services are already APIs.
Traefik Hub — MCP as middleware, acting as an OAuth 2.1 resource server. Task-Based Access Control lets policies key on amounts, time windows and record types, not just tool names.
Portkey — MCP registry alongside its LLM gateway. Remote HTTP servers only; local stdio needs wrapping.

Automation platforms extended

Enormous catalogues, thinner governance. Fastest route to a working prototype.

Zapier — 9,000+ apps, 30,000+ actions, browser-based setup. Task-based pricing gets unpredictable once an agent is driving.
Workato — 12,000+ enterprise connectors, existing recipes exposed over MCP. Compelling if you're already on it, hard to justify buying for MCP alone.

For a longer and detailed read, check out: Best MCP Gateway

The trade-off nobody states plainly

Most gateways are strong on governance or strong on integration breadth. Rarely both.

Governance-first products — MintMCP, Lunar, Obot — do RBAC and audit well and supply zero connectors. Bring your own servers. That's a real ongoing cost: OAuth setup, schema maintenance, security review, per tool, forever.

Breadth-first products — Zapier, Workato — hand you thousands of integrations and much less control over who calls what.

Work out which of those is your actual constraint before you shortlist anything.

Choosing, briefly

In rough order, because the early ones eliminate options:

Deployment — managed SaaS, self-hosted, or VPC. Data residency rules kill whole categories before anything else matters.
Compliance — SOC 2, ISO, HIPAA if relevant. Then check the audit trail actually exports.
Identity — SSO and SCIM, or you're provisioning access by hand.
Integration depth — do they supply connectors, or do you?
Pricing model — agents are chatty. Per-task pricing that's fine for human-triggered automation gets weird when an agent fans one request into forty tool calls. Model your volume first.

Latency comes lower than you'd think. TrueFoundry publishes sub-5ms, Lunar around 4ms p99, Docker 50–200ms. Real differences — but a gateway that saves 3ms and costs six months of integration work is a bad trade for most teams.

The short version

If you're prototyping, grab whatever's fastest to wire up and move on.

If you're going to production, the question isn't which gateway is best. It's whether connector maintenance or governance is the thing that'll actually bite you — and then picking the one that solves that, knowing you'll compromise on the other.

Check out https://composio.dev/mcp-gateway for building agents with secure and auditable access to tools

Kimi K3 vs GLM-5.2: What a practical test between 2 taught me

Developer Harsh — Tue, 28 Jul 2026 13:36:28 +0000

Moonshot AI released Kimi K3 on July 16, 2026, and it landed with a statement: 2.8 trillion parameters, 1 million token context, and open weights by July 27. The previous month, GLM-5.2 was released and is already in production

This proves that open-source models aren't just catching up to closed ones; they're reshaping what developers and businesses expect.

This is a comparison built for people who are building things. No benchmark chasing. No marketing narratives.

Just what each model does, where it shines, and what matters when you're shipping.

TLDR

Kimi K3: 2.8T params, 1M context, always-on reasoning, native multimodal. Best for long agent loops that need sustained reasoning and visual understanding. Frontier pricing.
GLM-5.2: 744B params (40B active via MoE), 1M context, flexible reasoning effort. Best for coding, math, and cost-efficient throughput. Open weights (MIT) available now.
Pick K3 if: agents need to reason for hours, handle images/UI, cost isn't the bottleneck.
Pick GLM-5.2 if: you want open weights today, need cheap high-volume inference, or your work leans coding/math.
Few personal builds like games, physics-driven simulation, coding, and behavioral tasks.
Bottom line: Both close the gap with closed models fast. Choice comes down to workload, not hype.

Architecture: Two Very Different Paths to Scale

Aspect	Kimi K3	GLM-5.2
Total Parameters	2.8 trillion	744 billion total
Active Parameters	Not yet disclosed	~40 billion active (MoE)
Context Window	1 million tokens	1 million tokens
Key Architecture	Kimi Delta Attention (KDA) + Attention Residuals	Mixture-of-Experts (MoE)
License	Not yet published	MIT (no regional limits)
Release Date	July 16, 2026	June 13, 2026

Kimi K3: Raw Scale Meets Long-Horizon Design with KDA

Kimi K3 is built on Kimi Delta Attention (KDA), a hybrid linear attention mechanism, and Attention Residuals. Moonshot engineered this for sustained agent workloads, not just bigger benchmarks.

The move from K2's 1 trillion parameters to K3's 2.8 trillion is deliberate. Moonshot is charging frontier rates to make the price-to-capability tradeoff hard to ignore.

You're not getting a discount model trying to go above its weight. Instead, you're getting brute-force capability with specialised attention for long reasoning chains.

Note: The full model weights will be released by July 27, 2026, but the technical report with full sparsity ratios and active parameter counts is still pending. You can build on K3 API today, but deep architectural details aren't locked in yet.

GLM-5.2: Efficiency First, Capability Everywhere with MOE & Index Share

GLM-5.2 is a 744-billion-parameter Mixture-of-Experts model with approximately 40 billion active parameters per token.

That MoE design means only a fraction of the model activates per token. This enables throughput that larger dense models can't match.

The standout innovation of GLM is its IndexShare, which reuses the same indexer across every four sparse attention layers, reducing per-token FLOPs by 2.9× at a 1M context length. For you, this means GLM-5.2 makes the 1M context practical, not theoretical.

Note : GLM-5.2 is released under an unrestricted MIT license, which matters if you're deploying locally or need no-strings-attached weights. Deploy on your own hardware, fine-tune, fork with no regional restrictions.

Kimi K3 vs GLM 5.2: Composio Golden Eval

What does the bench look like?

Composio Golden Eval is a real-account tool-use benchmark. Claude Code drives multi-step SaaS tasks through the hosted Composio MCP router against live accounts, then the final state is checked by reading the actual account back through APIs.

The grader checks what changed in the account, which is why I care. The verifier reads the account state: labels, Sheets rows, Salesforce or HubSpot records, calendar edits, access lists. There is no transcript-only judgment that the agent basically got it.

The accounts stay safe because writes are tag-scoped and cleaned up afterwards. Every run leaves tagged artefacts that can be removed after grading, which is the only sane way to run this kind of thing on live Gmail, Google Calendar, Google Drive, Google Sheets, Salesforce, HubSpot, GitHub, Linear, and Slack accounts.

The run covered 12 scenarios across 24 trials. Seven are historical cases that a competent tool-use model should clear: CRM identity dedup, calendar free/busy checks, recurring-event repair, Drive external-share audits, Gmail label batches, GitHub access audits, and GitHub/Linear reconciliation.

Five are the harder frontier-kill stress cases: cross-app “sync and reconcile” workflows where the agent has to read Gmail threads, apply exclusion rules, append exact rows to a Sheet ledger, send per-item replies, and write one ops-thread tally.

The pass condition is an exact final state. These tasks mix exact-set reconciliation, dedup, cross-app joins, and audits with negative constraints. If the agent gets 90% of the rows right but includes one disqualified item, the run still fails. Failed runs can show partial-credit check counts like 8/13, but the outcome metric is still pass, fail, or DNF (did not finish).

How I ran it

I ran both models through the same 12 Golden Eval cases against the same live accounts. The readback checks were identical, with the same check names and denominators. There is one harness caveat: Kimi K3 ran under the pi agent harness, while GLM 5.2 ran under Claude Code pointed at OpenRouter. I treat the pass/fail result as a same-task, same-grader comparison, and effort numbers as harness-dependent.

Grading used real-account API readback, tag-scoped cleanup, pass/fail/dnf per trial, with partial-credit check counts on failures.

Frontier-kill task	Kimi K3 checks	GLM 5.2 checks	Kimi tool calls	GLM tool calls	Kimi runtime tokens	GLM input tokens	Kimi agent time	GLM agent time
Invoice sync	8/13	8/13	16	17	896,094	1,020,844	389.8s	507.4s
Refund ledger	8/13	8/13	21	20	1,309,483	1,334,127	685.8s	458.9s
Roster sync	8/13	7/13	13	19	609,233	1,058,024	505.1s	418.9s
Vendor directory	11/13	11/13	16	23	820,613	1,683,579	788.5s	803.7s
Ticket sync	17/24	dnf	23	dnf	1,745,612	dnf	713.5s	dnf

Runs used the hosted Composio MCP router. Kimi ran under the pi agent harness; GLM ran under Claude Code pointed at OpenRouter. Kimi token counts are total runtime tokens (input + output); GLM's column is input tokens, with another 18K to 46K output tokens per task. Ticket sync is the one task GLM 5.2 did not finish inside the 30-minute cap.

Pass rate was flat: Kimi K3 solved 7 of 12, and GLM 5.2 solved 7 of 12. That is 58% each.

With the harness caveat above, effort favored Kimi on several finished frontier-kill runs.

On the four frontier-kill tasks both models finished, Kimi used fewer tool calls on invoice, roster, and vendor, while GLM used one fewer on refund. Kimi also finished Ticket sync in 713.5s with 23 tool calls and 1,745,612 runtime tokens; GLM hit dnf inside the 30-minute cap.

Time did not point one way: GLM was faster on refund ledger and roster sync, while Kimi was faster on invoice sync and slightly faster on vendor directory.

Findings

Here is the task-for-task result on the same 12 cases.

Task	Band	Kimi K3	GLM 5.2
CRM identity dedup	Historical	✅	✅
Calendar free/busy	Historical	✅	✅
Recurring instance repair	Historical	✅	✅
Drive external-share audit	Historical	✅	✅
Gmail label batch	Historical	✅	✅
GitHub access audit	Historical	✅	✅
GitHub / Linear reconciliation	Historical	✅	✅
Invoice sync	Frontier kill	❌ 8/13	❌ 8/13
Refund ledger	Frontier kill	❌ 8/13	❌ 8/13
Roster sync	Frontier kill	❌ 8/13	❌ 7/13
Ticket sync	Frontier kill	❌ 17/24	❌ dnf
Vendor directory	Frontier kill	❌ 11/13	❌ 11/13
Solved		7/12	7/12

Fractions on the failed rows are partial-credit verifier checks: how many graded assertions the model got right before missing the exact-final-state bar. dnf means GLM 5.2 did not finish Ticket sync inside the 30-minute per-task cap, so no partial score was recorded.

Kimi K3 and GLM 5.2 both cleared the historical seven, both fell on all five frontier-kill workflows, and both ended at 7/12, 58%. The only score gap in the entire suite is one verifier check on Roster sync: Kimi got 8/13, GLM got 7/13.

The historical band did not separate them. Both passed all seven cleanly, including CRM identity dedup, which spans Salesforce, HubSpot, and Gmail. Calendar free/busy, recurring instance repair, Drive external-share audit, Gmail label batch, GitHub access audit, and GitHub / Linear reconciliation all landed green for both models.

What it costs

I priced the finished runs from their token counts against current OpenRouter list rates, before cache discounts. The dollar amounts are estimates, but the price gap is wide enough that the direction is clear.

OpenRouter currently lists Kimi K3 at $3/M input and $15/M output. (openrouter.ai) For GLM 5.2, I used OpenRouter’s current model API rate of about $0.82/M input and $2.59/M output.

Model	Tokens on the finished frontier-kill cases	Estimated cost per case	Four-case estimate
Kimi K3	~609K to 1.75M runtime tokens	~$1.83 to $5.25	~$7.31 to $21.00
GLM 5.2	~1.02M to 1.68M input, plus 18K to 46K output	~$0.89 to $1.50	~$3.55 to $6.02

GLM sometimes spent more tokens. Its finished cases ran ~1.02M to 1.68M input tokens, while Kimi’s runtime-token band started lower at ~609K. But Kimi’s input rate is about 3.6x GLM’s, so the extra GLM context still comes out cheaper in this estimate.

Tool calls landed in similar ranges, 13 to 23 per case for both. So the extra GLM tokens on roster and vendor work did not buy extra passes. The scores tied, with GLM carrying the cheaper bill.

At 1,000 four-case batches, that envelope turns into roughly $7.3K to $21K for Kimi and $3.6K to $6.0K for GLM before cache discounts.

Verdict

Kimi K3 and GLM 5.2 tied on pass rate, 7/12 each, 58%. I’d give the practical win to Kimi because it finished the biggest frontier case at 17/24 while GLM hit the 30-minute cap, and GLM spent more tokens on roster and vendor for the same or worse result.

I would pick Kimi K3 when finishing the long tool workflow matters more than the cheaper rate. Ticket sync shows why: Kimi got through 24 turns, posted 17/24, and burned 1.75M runtime tokens. GLM did not finish inside the 30-minute cap. On Roster sync, Kimi also scored 8/13 while GLM scored 7/13, because Kimi posted the cover replies GLM dropped. It did that with 13 tool calls and 609K runtime tokens, while GLM used 19 tool calls and 1.06M input tokens.

GLM 5.2 makes sense if your workload looks more like the easier historical band, or if you already want the Claude Code via OpenRouter setup and can live with the frontier misses. It matched Kimi’s top-line score, cleared the same 7/7 historical cases, and tied Kimi on Invoice sync, Refund ledger, and Vendor directory by score. Refund ledger is the one frontier case where GLM was cleaner on latency: 458.9s versus Kimi’s 685.8s, with both landing at 8/13.

Kimi K3 vs GLM 5.2: On personal builds

So let me share some of the builds I tried with GLM and Kimi K3, along with prompt, time, cost, and builds.

For all builds I have used open router chatroom

Meteor City (revival)

Used Kimi K3 + GLM 5.2 to build Meteor City Revival, a game where you race to destroy the entire city before it can regenerate itself.

The task was initially given to GLM 5.2, but for some reason it stopped mid-session, so I took all the code and asked Kimi to refine and recreate the entire build.

Cost was approx. $4.3, used around 18.1M Tokens, Time: 1 hr 45 min. This is justified cause without explicitly mentioning it, it generated 10K procedural buildings, the engine, and figured out the lighting, ray tracing, shaders, and optimized the game for mobile as well as web.

You can play the game at: https://meteor-city-revival.vercel.app/

Prompt Used

Create a complete, self-contained, single HTML file using Three.js (via CDN only — no other external dependencies or files) that implements a large-scale 3D photorealistic procedural meteor impact city destruction game/simulation.

**Core Gameplay (must be fully implemented and preserved exactly):**
- Procedural city with buildings that can be damaged and destroyed.
- Clickable "Launch Meteor" button that fires a meteor. User can launch multiple times.
- Buildings regenerate over time.
- **Push-and-wait mechanic**: Holding/clicking the Launch Meteor button charges a larger, more powerful meteor (powerup style).
- **Infinity powerup**: When activated, launches 5 big meteors in quick succession that deal massive damage (enough to push the destruction bar to ~95%).
- Powerups (larger meteor charge and Infinity) drop from meteor impacts and are automatically collected when the player is near them.
- Destruction progress bar that tracks overall city damage.
- At 100% destruction, display the text: "Now I am become Death, the destroyer of worlds."
- UI sliders for meteor size, speed, angle, time of day, and destruction intensity.
- Meteor and impact sounds using Web Audio API.
- Playable simulation/game with smooth performance.

**Visual & Technical Polish Requirements (focus here for realism and quality):**
- Highly realistic procedural city at night: varied building heights (low-rises to skyscrapers), realistic facades with window grids using InstancedMesh (windows have individual emissive colors that flicker or turn off when damaged), different roof styles, subtle material variation (concrete, glass, brick), minor architectural details like ledges.
- Use seed-based procedural variation so the city feels organic. Add roads, paths, and scattered green areas/parks between building clusters.
- Heavy use of InstancedMesh and LOD (Level of Detail) for performance.
- Realistic ground/terrain with subtle height variation, road networks, and support for crater formation on impact.
- Rich night sky: procedural starfield with twinkling stars, subtle moon glow, gradient sky with horizon haze and light pollution from the city. Add very subtle atmospheric effects.
- High-quality meteor: glowing fiery body with long dynamic particle trail (fire, sparks, smoke) that intensifies on entry.
- Realistic impact sequence: bright flash, expanding shockwave (particles + ground ripple), crater, layered particle systems for fire/explosions, dense rising dust/smoke plumes, and flying debris with gravity and tumbling.
- Improved building destruction: pieces break off with dust, structures partially crumble or lean, and damaged areas show reduced lighting/exposed sections.
- Dynamic lighting: moonlight + hemisphere light, multiple flickering point lights from fires and impact, emissive building windows, and fire effects. City lights progressively dim or extinguish with damage.
- Materials: Use MeshStandardMaterial where appropriate. Add subtle specular/roughness variation and rim lighting for depth.
- Special effects: Performant particle systems, screen shake on impact, bloom-like glow on bright elements, subtle motion blur during fast movement or camera fly-through, atmospheric perspective, and fog for depth.
- Overall cinematic yet realistic look with balanced night-time color grading (cool tones with warm fire accents).

**Camera, Controls & Performance Polish:**
- Smooth OrbitControls-style camera (mouse drag to orbit/pan, scroll to zoom) with optional free-fly mode (WASD + mouse look).
- Smooth camera interpolation and gentle auto-orbit when idle.
- Refined slow-motion replay with smooth timeScale control.
- Aggressive performance optimizations for stable 60+ FPS: InstancedMesh, LOD, frustum culling, efficient particle pooling, minimal draw calls.
- Subtle ambient animations (random window flickering, gentle dust movement).

**Technical Requirements:**
- Output ONLY the complete single HTML file (nothing else before or after).
- Must be immediately runnable in a modern browser with no errors.
- Include helpful inline comments explaining key visual, lighting, particle, and optimization techniques.
- Prioritize photorealistic visuals, cinematic quality, smoothness, and immersion while keeping all gameplay mechanics fully functional and unchanged.

Generate the full polished HTML code now.

Output

Plane Currents

I always wanted to try low-poly 3D graphics, so I tried it with Kimi K3.

Use Kimi K3 to build a paper plane simulator where the player passes through rings to gather points and complete the course. All while having a relaxing scene and music going in the background. (no 3d assets)

This took around 16 minutes to generate, cost me approx $0.45, and used 30K tokens.

You can play the game by opening the game file.

Prompt Used

Build me a self contained  Relaxed 3D paper-plane flying gameplay where you launch and steer a customizable plane through glowing rings and floating islands over an ocean, collecting score multipliers in short, physics-light runs with easy controls (hold to launch, mouse/keyboard steering) with stylized low-poly 3D with clean cel-shaded visuals and a sleek, colorful indie-game UI featuring customizable paper planes, glowing rings, floating islands, and simple HUD element graphics. Output a single HTML file.

And the output generated by the above prompt.

Gargantua Black Hole Geodesic Ray Tracer (Complex Physics Game/Sim) - inspo from X

I was scrolling X and found this massive black hole geodesic ray tracer simulation made by someone. Being the space nerd I am, I wanted to make this too.

So I did a bit of research and constructed a prompt that requires the model to think through the actual light-bending physics and math that happens near the event horizon of a black hole.

I was completely hopeless cause fable and GLM 5.3 gave up on the calculation task earlier, but anyway I entered the prompt. To my surprise, Kimi K3 actually went through the maths and solved it in its thinking traces.

After approx 14 minutes and burning through 33K tokens, which costed around $0.51 (operouter), it handed me the complete code.

I ran it, and here are the results

Prompt Used

Create a complete, self-contained single HTML file (no external libraries like Three.js) that implements a real-time geodesic raytracer for a Schwarzschild black hole inspired by Gargantua.

Use raw WebGL2 with GLSL ES 3.00 in a single fragment shader. Implement accurate physics: null geodesic integration with 4th-order Runge-Kutta solver, event horizon, photon sphere, accretion disk with proper rendering, gravitational lensing, Doppler beaming, and gravitational redshift effects. Target stable 60 FPS performance.

Include mouse-controlled camera orbiting/zooming, and a cyberpunk-style control panel with sliders for parameters (mass, spin, disk density, view angle, etc.). Add subtle particle effects for matter falling in and dynamic lighting/shadows.

The output must be 100% complete, immediately runnable in a modern browser, with no black screen, NaNs, errors, or missing features. Prioritize numerical correctness, boundary handling, solver discipline, and physical accuracy above all. Verify and comment key physics equations in the code. Make it visually stunning and interactive like a premium physics demo/game.

Game File

Yup, the code, math, and physics engine are all built by Kimi K3, and Fable failed to build the simulation with such a level of detail, which makes its claim worth the hype.

I also tried 2 more tests to verify my doubts, sharing them as a bonus.

Bonus Test 1 (Held Karp Problem Solution (NP-Hard)

It's not a surprise to me that Kimi K3 and GLM 5.2 were both able to solve this in no time, but I ran the test to check just raw coding + reasoning ability.

The task was simple: fix the bug, create an optimal path, load env, run code, and give an answer to the buggy Held-Karp problem. Yup, the task has multiple steps for testing instruction following

The test cost 0.03 cents, used 82K tokens (most on reasoning), and the result was out in 5 minutes. You can check the buggy code and fixed code from the attached files.

Game File: problems.py , solution.py

The prompt I used:

Fix all bugs in the Held-Karp code in @file:problem.py so it correctly computes the minimum-cost tour for this 12-city TSP instance. Make the DP, base cases, transitions, and path reconstruction fully correct in  @file:fixed.py. Then create a new environment (.env) inside @file:held-karp-problem, install the dependencies, activate the environment, and run it to output the optimal cost and the tour as a list of cities starting and ending at 0.

Result

I even validated it with one of my code geek friends and Grok 4.5 (expert)

Models don’t just need to output code; they also need to maintain behavioural constraints, so I tested both with a behavioural question. The result was similar.

The task was simple: to resolve a conflict between team and stakeholder using the STAR Method

Prompt

Act as an experienced tech interview coach. Answer the following behavioral interview question using the STAR method (Situation, Task, Action, Result). Make the answer concise, professional, and impactful for a software engineering or tech role. Include quantifiable results where possible and highlight leadership or collaboration skills.

Question: Tell me about a time when you had to resolve a conflict within your team or with a stakeholder.

Both models thought for a very short time and delivered the result in almost the same time.

Model Name	Token Count	Cost	Duration
GLM 5.2	592	$0.00162095856	25.0 s
Kimi K3	763	$0.012987	18.3 s

However, Kimi K3 won as it delivered a more credible, business-aligned conflict story with quantified stakeholder impact ($200K ARR, measurable failure reduction).

A product manager and backend engineer clashed over shipping a checkout feature on deadline versus fixing payment failures (affecting 3% of transactions). The tech lead reframed both concerns as "reliable payments delivered fast," then proposed shipping the feature behind a flag while hotfixing the top failure points. The plan shipped on time, cut failures from 3% to 0.4%, retained a $200K client, and became a team standard practice.

On the other hand, GLM tells a technically impressive but somewhat predictable "engineering debate resolved by benchmarking" narrative.

Two senior engineers deadlocked over GraphQL vs REST for an API redesign, stalling the team for two weeks. The tech lead ran a proof-of-concept benchmark showing GraphQL won on performance (35% payload reduction), then added REST endpoints for backward compatibility to honor both perspectives. Development resumed in 3 days; the API improved response times 30% and maintained support for 12 existing clients.

Simple table for understanding

Criterion	GLM 2.5	Kimi K3
Stakeholder Range	Two engineers only	PM + Engineer (broader influence)
Business Context	Process improvement	Revenue at risk ($200K)
Conflict Complexity	Technical disagreement	Business vs. tech risk trade-off
Resolution Approach	Proof-of-concept (predictable)	Phased delivery + data compromise (creative)
Lasting Impact	Team velocity restored	Process adoption + trust rebuilt + client retained
Interviewer Appeal	Shows technical leadership	Shows business acumen + technical leadership

This shows Kimi K3 is more aligned with the workspace and can provide factual answers when needed. Really impressive.

With this, we have come to the end of this deep dive, but here is what I have to say at the end.

Conclusion: The Gap is Closing

Six months ago, comparing open-source models to Claude and GPT meant accepting tradeoffs with performance, quality, builds, and output.

Today, models like Kimi K3 are extremely competitive across coding, agentic, and multimodal tasks.

Also, GLM-5.2 shows competitive performance across industry-standard evaluations, frequently rivalling or approaching proprietary models such as GPT-5.5 and Claude Opus 4.8.

Here is what most people are missing.

The talk is no longer about closed vs open source; It's about specialised vs general, and long-context practical vs theoretical.

Both K3 and GLM-5.2 are proving that open-source can own specific workloads better than models 10x the marketing budget.

For builders:

Choose Kimi K3 if you're building agents that reason for hours, need multimodal perception, or can absorb frontier pricing.
Choose GLM-5.2 if you want open weights today, need fast inference on a GPU, or are optimizing for math and code.

Either way, you're not choosing good models. You're choosing the right model for the right task, and that matters.

How to connect MCP servers to Slackbot

Shrijal Acharya — Sat, 18 Jul 2026 11:57:47 +0000

Slackbot recently added support for MCP, which means you can now connect it with external apps and let it take actions across your work tools directly from Slack

But the native app list is still limited. By the time of writing this post, there's just about 20 apps that you can connect from the Slack marketplace.

And for most teams, that's not enough.

But luckily, Slack allows you to set up or use your custom MCP servers and not have to be limited by the number of apps available in marketplace.

That's where Composio helps you. It can connect your slack bots to 1000+ apps that you can use.

In this guide, we’ll go through how to connect Slackbot with Composio’s MCP server in 3 steps.

ℹ️ The steps will be pretty much the same with other MCP servers as well.

What We're Building

Once this is set up, you can ask Slackbot things like:

Find my latest unread Gmail emails.
Search my Notion workspace for launch notes.
Check my Google Calendar for meetings tomorrow.

And a bunch more. Imagine all the stuff you can do with 1000+ apps. 😵‍💫

I'll leave the rest to your imagination...

Slackbot sends the request to Composio Connect, Composio finds the right tool, asks you to connect the app if needed (one time), and then executes the action.

Prerequisites

Before we begin, make sure you have:

A Slack workspace with Slackbot MCP client access (comes with Business+ and Enterprise plan)
Permission to create or configure a Slack app.
A Composio account.

That's it.

Step 1: Get the Composio Connect MCP URL

First, you need the MCP server URL from Composio.

For this setup, use Composio Connect:

https://connect.composio.dev/mcp

This is Composio’s hosted MCP server that gives your AI agent access to 1,000+ apps with just 7 meta-tools that let the slackbot discover what's available, authorize apps on demand, and execute tools across apps in parallel through a single connection.

You don’t need to create a custom MCP server for this guide.

Composio also supports custom MCP servers for more scoped project-specific use cases, but those can require API-key-based auth. For Slackbot, Composio Connect is the simpler path because it works with OAuth-based MCP client flows.

Step 2: Add Composio Connect to a Slack App

Now, we need to register the Composio MCP server inside a Slack app.

Go to the Slack developer dashboard and create a new app.

Once the app is created:

Open your Slack app.
In the left sidebar, go to Features.
Click MCP Servers.

Click Get Started.

Now fill in the MCP server details.

Use:

Name: Composio (or anything you wish)
URL: https://connect.composio.dev/mcp
Auth Type: Dynamic Client Registration

For the auth type, select Dynamic Client Registration.

ℹ️ This is the right option for MCP servers that support OAuth discovery and client registration. Slack handles the client registration automatically, so you don’t need to manually create OAuth credentials first.

Now, if you click the three dots and then Tools, you should see that it currently cannot fetch the tools because the MCP server uses a dynamic connection and must be installed in your workspace first.

So, now head over to the Install App tab, and install it to the workspace you selected when creating the app.

If your workspace requires approval, send the app request to your admin.

Step 3: Connect Composio inside Slackbot

Once your Slack app is installed and approved, open a DM with Slackbot.

Then, just type in a prompt that requires using the app, Slack will use the correct app automatically for you.

Click Connect, and you’ll be taken to a confirmation page.

Click on Continue, and then confirm it on the Composio end.

If everything went well, you should see that your account is connected.

After that, Slackbot should be able to discover Composio’s MCP tools.

Start with a simpler test:

What tools are available from Composio?

Once that goes through, now try an actual app action.

For example:

Send a mail to x@y.com saying 'Hi, from Composio 👋 inside Slackbot'

If Gmail is not connected yet, Composio should generate an OAuth link for you to connect it. Once you approve it, the connection persists for future use. So, you don't have to repeat this step again and again.

Slackbot may ask you to approve the action before it writes data to another app.

That's expected. Once connected, Slackbot can use that app through Composio.

Voilà, you've successfully connected Slackbot to Composio MCP. 🎊

Here’s a quick workflow for initiating a connection and running an actual app action:

Final Thoughts

Slack's own marketplace is good, and if it covers all the tools you require, you can completely stick to it.

But for some of you, that's simply not enough. I hope this helps overcome that problem.

So instead of jumping between different tools, you can ask Slackbot to find information, create tasks, update records, and run actions across your apps from inside Slack.

This is a much-needed quality-of-life improvement for teams that already live in Slack.

Slackbot gives you the interface. MCP gives you the protocol.

And Composio gives you the app layer. 👌

Shrijal AcharyaFollow

SDE • GOLD @Microsoft Student Ambassador • Prev Lead Collab and Dev-Team Lead @oppiaorg • Mail for collaboration

Cursor Vs Claude Code: Which one you should pick (or both)

Developer Harsh — Thu, 16 Jul 2026 17:10:26 +0000

Cursor and Claude Code are 2 leading products that engineers reach out for nowadays.

Both can refactor whole codebases, hunt for bugs, run spec-driven builds, and handle vibe coding needs, in the same ecosystem (skills, mcps, plugins, hooks ) and harness that ties the agent loop together. Same rig, yet both cater to a different workflow.

And Cursor had recently become hard to ignore as SpaceX signed a $60 billion all-stock deal to buy its parent company, Anysphere (closes Q3 2026), and around the same time, it shipped Origin, its own githost for agents, plus cloud agents, Composer 2.5, and Grok 4.5.

As for me, I use both every single day. I even rewrote my X bio in their honor: I touch Claude Code, Cursor for a living.

None of this is free, though. For 6 months, I have happily paid $20/mo for Cursor and $100/mo for Claude Code because neither tool excels at everything in my workflow.

However, not everyone needs both, and not everyone wants to spend $120 a month to find out. If that is you, the question shifts to what you actually get for each dollar.

This is what this guide answers. Let’s begin

TLDR

Section	Which to pick
Models and tooling	Claude Code for depth on one model;
Cursor for option across many
Billing cost's real story	Claude Code on focused tasks (pay per fetch, ~5.5x fewer tokens);
Cursor for huge monorepos, but you pay to keep the index fresh
Task delegation (async agents)	Cursor for supervised and visual;
Claude Code for raw delegated horsepower
The harness	Cursor for UI-heavy work you want to watch and control;
Claude Code for repeatable, version-controlled instructions that run themselves
Everyday usage	Cursor for hands-on control over every edit;
Claude Code for reviewing finished work instead of keystrokes
Pricing	Cursor for simple, predictable flat pricing;
Claude Code's $100 only pays off on token-heavy work
Extensibility (MCP, Skills, plugins)	Cursor to distribute a governed toolset to a large team;
Claude Code for reproducible agent behavior that lives in the repo
Data privacy	Claude Code for a narrower footprint;
Cursor will soon route your whole stack through one owner (SpaceX)

But before moving forward, I would like to clear up a common paradox people get caught up in.

The common paradox

Most people think Cursor is an AI editor with tools, while Claude Code is an AI agent you hand tasks to. That is not their fault tbh.

But my friend, that framing died twice.

First, the interfaces merged:

Claude Code now runs in VS Code, as a desktop app, and in the browser.
Cursor runs as a desktop app, in a terminal, in the cloud, on iOS, and on the web.

I even run Claude Code inside Cursor most days now.

Second, Cursor stopped being a code editing tool and became a platform. It now owns the full software factory, top to bottom:

Write your code in Cursor,
Review it with Bugbot,
Host it on Origin (new release),
Run it on models trained by its own group.

Look at the last seven months alone:

Date	Move	What it means
Dec 2025	Acquired Graphite	Owns code review: stacked PRs, merge queues
Feb 2026	Bugbot went reviewer to fixer	Spots a bug, spins its own agent, tests a fix, proposes it
Jun 2026	Announced Origin, a GitHub rival	Git hosting for the agentic era, AI merge-conflict resolution. Waitlist, ships fall 2026
Jun 16, 2026	SpaceX agreed to acquire Cursor	$60B all-stock per an SEC 8-K filing, close expected Q3 2026, into the xAI group

This tells you that the platform is no longer what it was 6 months ago; the cursor now owns the entire integrated software factory stack. More about it on the Product Hunt discussion.

So if the interfaces are roughly the same now, what actually separates these two tools? Read on.

Two years ago, the model was the moat. In 2026, it hardly is.

Claude Code runs on Claude, currently Opus 4.8. The tool and the model are tuned for each other, and you feel it in how confidently it plans multi-step work.
Cursor lets you select your own brains: GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro, Grok 4.5, and its own Kimi K2.5 finetuned Composer 2.5. Pick the right model per task, pay Cursor to route.

On my 12-file NASA JPL refactor, Claude Code read most of the tree before writing a line, and the first pass barely needed correction.

As for the cursor, it also handled things smoothly with a one-time correction with a function. It was because a model API call failed and was partially completed.

This has also been a concern for the cursor teams, and they aim to be the lab, rather than a model router. Also, it aims to invent a new kind of programming where any idea can just be represented in English.

Truell’s June 16 Compile keynote & later in Lenny’s podcast addresses this nicely:

"Our goal with Cursor is to invent a new type of programming. It looks like a world where you have a representation of the logic of your software that does look more like English. You can imagine kind of an evolution of programming language towards pseudocode. You have written down the logic of the software, and you can edit that at a high level. It won't be the impenetrable millions of lines of code, it'll instead be something that's much terser and easier to understand and easier to navigate."

Now that’s training its first frontier model from scratch, 1.5 trillion parameters, on xAI's Colossus cluster, under SpaceX's $60 billion deal. It seems the company is heading into its next phase and aims to become the model developer.

Who wins?

If you want a model tuned straight into the tool, go to Claude Code.
If you want model variety today and a bet on Cursor's own lab tomorrow, go with Cursor.

2. Pricing: Cursor vs Claude Code

Most of us stop at the sticker price.

Cursor

Tier	Price	Notes
Hobby	Free	Limited
Pro	$20/mo
Pro+	$60/mo	3x usage
Ultra	$200/mo	20x usage
Teams	$40/user ($120 Premium seat)
Enterprise	Custom

Every paid plan runs on usage credits, with on-demand billing past your allotment. Turn on spend limits the day you start.
Auto mode is the cheap lever: it runs Composer 2.5 or routes to a capable model automatically, and it is unlimited on paid plans.

Claude Code

Tier	Price	Notes
Free	None	No free tier
Pro	$20/mo
Max	$100/mo ($200 for 20x)	Unlocks Opus, up-to-1M context
Teams	$25/seat ($20 annual)	Caps at 150 seats
Enterprise	Base seat + API usage	Cheaper light, pricier heavy

No free tier; the cheapest door is Pro at $20.
Limits run on two clocks at once: a 5-hour rolling window plus a weekly cap, so an all-day session can hit the wall mid-task.
To trim spend, route routine edits to Sonnet or Haiku, save Opus for hard refactors.

On paper, both start at $20, and the offerings look even. It isn’t!

The sticker price hides what it actually costs to run a task.

On a widely repeated refactor test, the same job cost wildly different amounts of compute:

Tokens used on the same refactor (lower is better)

Source

That is a 5.5x gap for identical output.

One honest note: this is a single community benchmark; the two agents ran different models under the hood, and at least one prints the numbers flipped. Treat it as a strong signal, not a law. It also does not hold everywhere.

This happens because each tool loads the context differently:

Cursor retrieves using a hybrid stack: a semantic index, grep, and an Explore subagent. Index-backed and targeted, strong on huge monorepos, but the index carries a standing cost to build and keep fresh. You pay for it.
Claude Code skips the index and greps, globs, and reads on demand. Index-free and just-in-time, so you pay only for what it pulls into context.

One caveat: both start to degrade beyond roughly 150k tokens of genuinely relevant context, so neither truly wins at extreme scale.

So, who wins?

Cursor: Use it if you want simple, predictable flat pricing.
Claude Code: the $100 only pays off on token-heavy work.
Pro tip: Model both against your own usage, then decide.

3. Task Delegation with Async agents

The refactor task I gave to Claude and the bug hunt task to Cursor were not from the terminal/app UI; they were through my mobile phone. In fact, I barely touch my pc while traveling.

Essence is simple.

In short, task delegation is here, but both Claude Code and cursor build around this differently.

Cursor

Cursor builds this around cloud agents and Automations:

Launches cloud dev environment in under 10 minutes, snapshot it, reuse it.
/in-cloud spins a subagent on its own VM and branch, while your laptop stays unaffected.
/automate creates jobs in plain language, with GitHub and Slack triggers.
Bugbot review runs ~3x faster, roughly 90 seconds a pass, and can be called with /review before you push.

Claude Code

Claude Code builds this around agent teams and background sessions:

Cloud dev environment for remote sessions, spun up automatically the first time you run a remote feature, no manual web setup.
/agents launches a coordinated team where one session leads and others execute, viewable and steerable in the claude agents view.
Background agents run on separate git worktrees; kick one off from claude agents, then steer it from your phone via Remote Control in the mobile app.
/code-review runs a review pass on your changes, improved on Opus 4.8 across effort levels, and /security-review scans for vulnerabilities before you push.

Who wins?

Supervised and visual, go for Cursor.
Raw delegated horsepower, go for Claude Code.

4. The Harness

Strip as an agent down to its core, and that is a model in a loop with tools.

Everything wrapped around that loop:

The memory,
The standing instructions (system prompt),
The automatic hooks

decides whether the loop is reliable and works. Some people call this layer the rig, but it's commonly called a harness.

Both Claude code and cursor ships with this harness, but are targeted for different workflows:

Claude Code

Ships the harness native and documented:

CLAUDE.md: standing instructions, the agent reads every session.
Skills: packaged workflows you invoke like /review-pr.
Hooks: shell commands that fire on lifecycle events, so a formatter runs after every edit.
Artifacts: session work captured as a live web page (a PR walkthrough, a dashboard), a non-terminal teammate can read, with private org sharing and version history.

Cursor

Its harness version exists too, and it is growing fast:

A single Customize page pulls together plugins, skills, MCP servers, subagents, rules, commands, and hooks, with a marketplace on top.
Design Mode lets you point at UI elements in the browser or on a canvas, select several at once, and narrate changes by voice while agents edit beneath the surface.

The difference is the center of gravity:

Cursor's harness orbits the editor and the visual surface, and yes, it's amazing. I give one instruction in the 1st prompt, and it carries forward until the chat ends.

Claude Code orbits the agent loop and the command line. In my experience, I tend to forget important instructions mid-conversation if the topic strays too far or the chat goes on too long.

So, who wins?

Cursor: For UI-heavy work where you want to see every change and be in control. (not true delegation, but secure)
Claude Code: For repeatable, version-controlled instructions (a CLAUDE.md file plus Hooks) that your whole team inherits automatically, so the rules run on their own instead of relying on you to remember them. (true delegation, but feel less secure)

5. Everyday Usage

Cursor feels at home;

It is a VS Code fork, so it looks like the editor I already use,
Tab autocomplete predicts my next several edits as I type.
Within an hour of writing by hand, I felt faster when I tried it for the 1st time 6 months back.

Claude Code feels like running a company;

It's terminal + ui native, no autocomplete to fall for. Mainly for task delegation.
Once I have written a good enough CLAUDE.md and wired a couple of Hooks, Specs, and project-level skills, it runs whole tickets across multiple subagents in parallel while I go through the diff.
Mainly for task delegation, the payoff arrives late but is bigger than the current.

Review style	Cursor	Claude Code
What you see	Each change inline, accept or edit before it lands	The finished result plus the reasoning
Best for	UI edits where you eyeball every pixel	Delegated tickets you review as a whole
Tests	You trigger them	It runs them, iterates on failure, reports back

Who wins?

Tight control over every edit and well-controlled task delegation with AGENTS.md, go with Cursor.
Review finished work instead of keystrokes, go with Claude Code.

6. Extensibility: MCP, Skills, plugins

Both speak MCP, the protocol for wiring outside tools and data into an agent. Both turned it into a team-management surface rather than a solo toy.

Cursor

With the cursor, teams can:

Configure Team MCP servers once, push them across cloud agents, the agents window, the IDE, and the CLI.
Publish approved integrations to a team marketplace so members can install without touching config.
Added GitLab, BitBucket, and Azure DevOps support for those imports.

Claude Code

With the Claude Code, teams can

Leans on Skills, Hooks, and a plugin system, plus MCP for outside connections.
Use Cowork brings agent machinery to knowledge work within a local, isolated VM with access to their files.
A computer-use preview lets Claude open files, click, and navigate for you.
A Slack integration (Team and Enterprise plans) lets you tag Claude to hand off a task without leaving the channel.
Treats extensibility as a code check-in.

But what about solo dev’s?

Solo Devs

For the solo dev, none of the above matters; it's about speed, for example: how fast can you load tools, skills, and MCP that follow on every machine and get work done.

Cursor is the easy on-ramp.
- Adding an MCP server is a few clicks with OAuth built in, no config file to hand-edit, and you inherit the entire VS Code extension library on day one.
- The Customize page works at the user level, too, so your rules, skills, and MCPs live in one place as local instructions.
Claude Code gives a solo dev the same files-in-repo power the teams get.
- The CLAUDE.md skills, hooks, and plain files are plain files that users can commit to, so their agent behaves identically on their laptop, desktop, or any box they clone into.

Either way, the setup is only half the battle.

Often, we solo developers struggle to connect to multiple tools, manually pass API keys, worry about security, and hope for optimized tool calls. ‘

So for this, I use composio, which helps me connect to 1000+ tools/services in one click, while handling all the issues I mentioned earlier. - Just a practical experience here, your call.

Who wins?

Distribute a governed toolset to a large team through a marketplace. Cursor leads today.

Reproducible agent behavior that lives in the repo, Claude Code fits how engineers already work.

7. Most Important Factor

This is the point most take for granted. The data privacy.

Cursor is on its way to becoming a SpaceX subsidiary, folded into the xAI group, once the $60B deal closes in Q3.

Pair that with Origin (its own git host) and Composer (its own model), and one company could soon own the tool that writes your code, the place that stores it, and the model that learns from it. That is genuinely new. No prior git host has also owned the model doing the writing.

I am not calling it a trap, and I am not assuming bad intent. But if you work on client repos with strict rules about where code can live, as I do, think about this before you migrate anything.

Always read the terms. Watch where the data goes.

Claude Code keeps a narrower footprint, an agent and a harness rather than a whole hosting stack, though your code still travels to Anthropic's API either way.
Cursor soon will own the stack, your code, your tool calls, your decision, plan, and all builds will go through the cursor for better model training.

The Verdict

You are...	Your pick	Why
UI / product engineer	Cursor	Editor you know, inline autocomplete, visual diffs, pick a model per task. The best AI code editor you can buy.
Systems / backend engineer	Claude Code	Delegate whole tickets, reproducible agent behavior from repo files, orchestrate several agents, review finished work. Its rig is the more serious engineering today, and its token efficiency is a real cost edge.
Most of us	Both	$120/mo total, for a month. Let the work sort it out.

The engineers I know who ship fastest stopped treating this as a loyalty test and started treating it as two tools for two kinds of tasks.

Cursor for the hands-on sessions.
Claude Code for the delegated automations.

The debate between cursor and clauded code ends the moment you stop arguing and start building. This is where I landed after six months with the two subscriptions.

Remember, your repo and your habits will move these numbers in the future, so borrow my framework, not my conclusion.

The Enterprise MCP Gateway Buyer's Guide: SSO, SCIM, Audit, and Governance Requirements

Dumebi Okolo — Sun, 05 Jul 2026 22:31:54 +0000

MCP gateways are becoming mandatory infrastructure for any organization deploying AI agents at scale. Here is what they actually do, what they must do, and how to evaluate one honestly.

In November 2024, Anthropic released the Model Context Protocol: a wire format for connecting AI clients to tools, data sources, and APIs. Eighteen months later, MCP has crossed 78% adoption among production AI engineering teams. The public registry has passed 9,400 servers. Anthropic, OpenAI, Google, and Microsoft all support it. Practitioners have started calling it "the USB-C of AI applications."

The protocol's success created an infrastructure problem that nobody anticipated at quite this speed. Every MCP server connection expands an organization's attack surface. Every AI agent operating with tool access can read private data, write to production systems, and execute commands under the permissions of whoever authorized it. Without a governance layer, these agents are black boxes: no audit trail, no access control, no identity attribution, no way to answer "what did this agent do?" to an auditor.

The answer the market has converged on is an MCP gateway: a control plane that sits between AI agents and the tools they call. But the term covers a lot of ground, from lightweight protocol proxies to full enterprise governance platforms. The differences are significant. Getting the choice wrong creates compliance exposure; getting it right creates the foundation for scaling AI safely.

What a gateway actually is

The core function of an MCP gateway is collapsing what engineers call the N×M integration problem. Without a gateway, every AI agent manages its own credentials, authentication flows, and access policies for every tool it connects to.

Ten agents and twenty tools produce two hundred independent connection paths, each with its own credentials, each potentially leaking secrets, each invisible to anyone trying to govern AI behavior centrally. A gateway reduces that to a single control point: N agents connect to the gateway; the gateway manages access to M tools.

That description makes it sound like a proxy. It is not just a proxy. The proxy, the routing layer, accounts for roughly five percent of what an enterprise-grade gateway actually delivers. The remaining ninety-five percent is everything else: identity federation, automated user provisioning, audit logging, role-based access control, policy enforcement, and protection against attack vectors that API gateways from the previous decade were never designed to handle.

"The proxy is roughly 5% of the actual scope. The rest is what makes it usable, governed, and defensible to your security team."

This distinction matters for procurement. Organizations that evaluate gateways primarily on latency benchmarks and integration counts are optimizing for the five percent. The ninety-five percent, whether the gateway can prove, in a form an auditor accepts, who did what, is what determines whether the deployment is actually enterprise-grade.

The Composio MCP Gateway is designed around this reality. Rather than selling a proxy and calling it governance, it ships the full stack: 1,000+ managed integrations across enterprise SaaS, a unified authentication layer, action-level RBAC, zero data-retention architecture (tool call payloads and credentials are never stored on Composio infrastructure), and SOC 2 and ISO certification. The quickstart takes about ten minutes; the governance layer is built in from the start, not bolted on later.

The four things that cannot be missing

Across the compliance frameworks that govern enterprise AI deployments (SOC 2, HIPAA, GDPR, ISO 27001, and now the EU AI Act), four governance capabilities appear repeatedly, either explicitly or implicitly. Absence of any one of them creates either regulatory exposure or operational failures that scale into incidents.

1. Identity federation and SSO

Without SSO integration, agents authenticate using shared service account credentials or locally-stored API keys. This creates credential sprawl, blocks user-level attribution in audit logs, and prevents IT from revoking access cleanly when an employee departs. With federated identity, every tool call carries the identity of the specific user who authorized it, flowing through the gateway from the enterprise identity provider down to the MCP server.

The technical baseline is support for OAuth 2.1, standardized in the MCP specification in June 2025, alongside SAML 2.0 for enterprise SSO and OpenID Connect for modern attribute mapping.

But the capability that separates governance-capable gateways from identity-aware proxies is On-Behalf-Of (OBO) token propagation: the pattern where a gateway passes the end-user identity downstream to the MCP server rather than substituting a service account. Without OBO, an audit log records "gateway service account called database write tool." With OBO, it records "Elena Mwangi in Finance called database write tool at 14:32 UTC." The difference is the difference between an audit log and an audit trail.

Composio's MCP Gateway handles this through SSO via SAML and OIDC, with documented integrations for Okta, Microsoft Entra ID, and Google Workspace. Every team gets a unique, scoped MCP endpoint. Developers paste it into Claude, Cursor, or ChatGPT. SSO authenticates. Only the tools their team is authorized to use appear, and there is no separate configuration step to restrict visibility.

One practical concern worth flagging: identity provider integrations that look stable can break silently. Microsoft Entra changed its attribute mapping behavior for synchronized users in late 2024 without a deprecation notice. Every such change is a potential gap in governance coverage. When evaluating any gateway, ask vendors specifically how they monitor for and respond to IdP-side breaking changes.

2. SCIM provisioning

SCIM — System for Cross-domain Identity Management — automates the user lifecycle at scale. New hires receive correct tool access on day one. Role changes propagate immediately to gateway permissions. Departing employees lose all access at the moment their directory account is disabled.

Without SCIM, MCP gateway access management becomes a manual operation at every organizational boundary event. HIPAA requires that access to systems holding protected health information be revoked immediately upon role change or separation. SOC 2 CC6.2 requires that access be provisioned based on authorized requests and revoked promptly when no longer needed. Manual processes fail both tests at scale.

The scenario that illustrates this most clearly: a developer departs on difficult terms. Legal advises IT to immediately revoke all access. IT disables the directory account. If SCIM is integrated, that change propagates to the gateway; every agent connection that developer had, from GitHub to Jira to Salesforce to internal APIs, terminates immediately. No gap exists between directory disabling and access revocation. Without SCIM, someone has to hunt and manually revoke individual credentials across every connected system. At any scale above a handful of users, some will be missed.

Composio's SCIM 2.0 implementation maps directory groups to teams directly. The mapping logic is explicit and auditable: if department = Engineering then Team: engineering. New hires get the right tools on day one without any manual gateway configuration. The group sync is active and continuous, not a nightly batch job.

For teams building toward this themselves: the build vs. buy analysis Composio published puts the engineering effort for SCIM provisioning at 4–8 weeks for a mid-sized team, before accounting for ongoing maintenance as IdP behavior changes. That estimate covers the SCIM endpoint, group sync logic, and conflict resolution. It does not cover the OAuth token lifecycle management that sits adjacent to it, which is typically another 4–8 weeks and carries higher ongoing maintenance cost.

3. Audit logging

Audit logs answer the question every regulator and every security team will eventually ask: "what did your AI agents access, and when?" Without comprehensive, immutable, structured audit logs, the honest answer is "we don't know." That answer fails every compliance framework that governs regulated data.

The minimum required fields per log entry are: timestamp in UTC at millisecond precision; user identity attributed through the IdP, not a service account; agent identity; MCP server and tool name invoked; tool input parameters; tool output or error state; authorization decision and the policy rule that produced it; and session identifier for multi-turn correlation. These fields are what make a log entry into evidence.

Beyond minimum fields, enterprise-grade logs must be immutable after writing, tamper-evident, either through cryptographic signing or append-only storage. They must be structured for reliable SIEM ingestion. They must support configurable retention aligned to the organization's most demanding applicable requirement: HIPAA access records for protected health information require six-year retention; SOC 2 typically requires twelve months.

Composio's audit trail logs every tool call as: user, team, tool, action, outcome. Critically, no payloads are stored , only metadata. This zero data-retention architecture matters for regulated industries where storing tool call contents on third-party infrastructure creates its own compliance risk. The logs support CSV export for compliance reviews, and retention is configurable from 7 days to 1 year. The audit log format generates entries compliant with SOC 2, HIPAA, and GDPR requirements.

4. Policy enforcement

The fourth pillar is where identity, provisioning, and audit turn from documentation tools into enforcement tools. Policy enforcement means the gateway doesn't just record that an agent attempted to call a destructive action. It blocks the call if the agent's role doesn't permit it.

The critical implementation detail is the granularity at which access control operates. Standard RBAC in legacy API gateways operates at the API endpoint level. MCP gateway RBAC must operate at the action level within each toolkit. A GitHub integration may expose GITHUB_CREATE_PR, GITHUB_MERGE_PR, and GITHUB_DELETE_REPO. Governance requires that a junior developer role can call the first two but not the third, without blocking access to the GitHub toolkit entirely.

Composio enforces action-level RBAC at the gateway layer, not at the model layer. Each team gets a scoped MCP endpoint exposing only the tools they are authorized to use. Destructive actions within allowed toolkits — GITHUB_DELETE_REPO, SLACK_DELETE_CHANNEL — can be blocked independently of toolkit access. This is enforced in the gateway: if a model tries to call a blocked action, the gateway refuses it regardless of what the model was instructed to do.

The access model supports both whitelist and blacklist modes. Teams can request access to blocked tools; admins approve or deny. This creates a self-service discovery path that doesn't require IT to anticipate every team's tooling needs in advance, while retaining central control over what actually gets enabled.

Attack vectors that API gateways were not built for

Traditional API gateways were built for HTTP traffic between services. MCP traffic between AI agents and tool servers introduces attack vectors that legacy infrastructure was never designed to handle.

Tool poisoning places instructions inside tool Metadata, specifically in tool descriptions and parameter documentation that AI models read to understand how tools work. If descriptions contain adversarial instructions, the model may execute them. Unlike prompt injection, tool poisoning persists across sessions: it affects every agent that interacts with the tool, not just the session in which the attack was introduced.

Rug pull attacks are tool poisoning with a delayed trigger. A server publishes clean, vetted tool definitions at the time of security review. After approval, the operator modifies descriptions to inject malicious instructions. Without tool hash pinning, hashing tool descriptions on first scan and alerting when they change, the gap between approved state and live state can persist indefinitely.

Prompt injection via tool output embeds adversarial instructions in tool outputs (document contents, database records, web page responses) that the agent ingests as legitimate input. The MCP specification only "SHOULD" require a human in the loop, which is insufficient protection in production environments handling sensitive data at agent speed.

Cross-server shadowing is an MCP-specific threat with no analog in traditional API security. A malicious MCP server impersonates a trusted server or embeds instructions in tool metadata that override the behavior of adjacent servers in the same agent context.

Credential sprawl is the most operationally common risk. Agents storing API keys, database passwords, and OAuth tokens in local configuration files create exposure through prompts, logs, or accidental repository commits. In multi-agent architectures, credentials propagate through chained tool calls in ways invisible without gateway-level telemetry.

A security leader at Medtronic described the operational concern accurately: "MCP opens a lot of opportunities to do a lot of damage very quickly." The velocity at which autonomous agents can chain tool calls makes human review an insufficient backstop without gateway-level guardrails enforcing limits in real time.

Composio's zero data-retention architecture addresses the credential sprawl risk directly: tool call payloads and credentials are never stored on Composio infrastructure. This eliminates the most common vector for credential exfiltration through the gateway layer itself.

What compliance frameworks actually require

No compliance framework names MCP gateways explicitly. All of them implicitly require what a gateway provides: a centralized layer where AI tool access is governed, logged, and restricted.

SOC 2 Trust Services Criteria CC6.1 through CC6.3 require access to be restricted to minimum necessary permissions, action-level RBAC satisfies this. CC7.2 and CC7.3 require monitoring and investigation of anomalies, real-time audit log alerting and SIEM integration satisfy this. CC8.1 requires change management controls; access approval workflows and configurable retention policies satisfy this.

For teams pursuing SOC 2 Type II certification, the observation period is at minimum six months. That means an organization that starts building its own gateway today won't have a reportable SOC 2 Type II audit for seven or eight months at the earliest, and that timeline assumes the controls were architected correctly from day one. Composio ships with SOC 2 Type II and ISO 27001 certification already in place, which removes this timeline entirely from the governance roadmap.

HIPAA adds a harder requirement: Business Associate Agreements. Any vendor that creates, receives, maintains, or transmits protected health information on an organization's behalf is a Business Associate and legally requires a signed BAA before any PHI touches their infrastructure. Composio's enterprise plan supports BAA execution. For healthcare organizations, this is a binary filter that precedes all technical evaluation: verify BAA availability before spending time on feature comparison.

The EU AI Act, whose high-risk system provisions became fully enforceable in August 2026, requires documented risk management, human oversight mechanisms, and technical evidence of controls for AI systems operating in healthcare, financial services, employment, and critical infrastructure. MCP gateway audit logs are the primary evidence artifact for conformity assessment. Organizations that have not established audit logging infrastructure before enforcement begins cannot retroactively generate evidence for the period before capture began.

The build vs. buy question, answered honestly

Internal builds of MCP gateway infrastructure are a recurring theme in enterprise AI teams. The engineering argument is usually that "a proxy is a few weeks of work." That framing is accurate for the proxy. The full enterprise stack is different.

Component	Build estimate	Ongoing cost
MCP routing proxy	2–4 weeks	Low
OAuth 2.1 implementation	3–6 weeks	High — each SaaS app handles OAuth differently and changes without notice
SAML/OIDC IdP integration	2–4 weeks	Medium — silent breaking changes require active monitoring
SCIM provisioning endpoint	4–8 weeks	Medium
Per-user OAuth token lifecycle	4–8 weeks	High
Audit log infrastructure	3–5 weeks	Medium
Action-level RBAC policy engine	6–8 weeks	High
15 SaaS integrations	~15 weeks	Ongoing per-integration maintenance
SOC 2 Type II observation period	6+ months	Continuous

The proxy is five percent of the scope. The OAuth maintenance burden is where most internal builds stall or quietly degrade over time: every SaaS application handles OAuth slightly differently, and those implementations change without notice. GitHub OAuth app permissions behave differently depending on whether the organization has SAML SSO enabled. Entra changed its attribute mapping behavior in late 2024 without a deprecation notice. Each change is a potential silent breakage.

Buying wins for most teams because they are not buying a proxy, they are buying maintained integrations, per-user OAuth lifecycle management, SSO and SCIM support, RBAC enforcement, audit logging, and compliance readiness, with the maintenance burden sitting on the vendor rather than internal engineering. Composio's MCP Gateway developer quickstart gets a working agent connected to its first toolkit in about ten minutes. That's the realistic comparison point against a multi-month internal build.

The cases where building makes sense are narrower: unique deployment constraints no vendor accommodates, classified network requirements, or organizations with the appetite to own the entire AI infrastructure stack as a long-term strategic investment.

How to evaluate a gateway honestly

Start with deployment model. For organizations in healthcare, finance, or government where regulated data must remain within specific boundaries, deployment model is often a legal requirement before any technical comparison begins. Cloud-hosted managed gateways reduce time to production but involve data transiting vendor infrastructure. Self-hosted or VPC-deployed options provide data sovereignty. Composio operates as managed SaaS with a zero data-retention architecture as the default; for organizations requiring VPC or on-premises deployment, that narrows the field significantly and should be the first filter applied.

After deployment model, evaluate in this sequence:

Identity depth. Does the gateway support OBO token propagation, or does it substitute service accounts? Ask vendors for a sample audit log entry and verify that user identity is IdP-attributed, not a service account name.

SCIM implementation. Does it support SCIM 2.0 with push provisioning? What is the documented maximum deprovisioning latency? The deprovisioning case, an employee departure or a security incident requiring immediate access revocation, is where manual processes fail most expensively.

Audit log quality. Require vendors to provide a sample log entry with all fields populated. Confirm the format is structured and suitable for SIEM ingestion. Confirm logs are immutable after writing. Confirm the retention policy can be configured to your longest applicable requirement. Ask whether PII redaction in tool parameters is configurable and, in Composio's case, whether the zero data-retention architecture means payloads aren't stored at all, which is the stronger answer.

Access control granularity. Confirm that RBAC operates at the action level, not the toolkit level. A gateway that blocks or enables whole toolkits but cannot distinguish between GITHUB_CREATE_PR and GITHUB_DELETE_REPO is not implementing least-privilege access control.

Compliance certification. Request the current SOC 2 Type II report date and auditor. Confirm whether a BAA is available. For European deployments, ask whether the vendor has documented controls relevant to EU AI Act high-risk system provisions. Composio's SOC 2 and ISO 27001 certifications are current, which shortens the security review process significantly.

MCP-specific threat coverage. Ask whether tool hash pinning is implemented and whether it generates alerts when tool definitions change post-approval. Ask whether tool metadata is scanned for hidden prompt instructions. These questions distinguish purpose-built MCP governance platforms from extended API management products.

Exit terms. Gateway choice shapes AI adoption architecture for three to five years. Confirm that gateway configuration, audit logs, and access policies can be exported in standard formats, and that contract exit terms do not create data portability barriers.

What comes next

The MCP specification continues to evolve. Client ID Metadata Documents, added in the November 2025 spec update, introduce a new mechanism for trusted client discovery. The Agent-to-Agent protocol is emerging as a complement to MCP for multi-agent orchestration, governing agent-to-agent delegation rather than agent-to-tool connectivity. Future enterprise governance will require control planes spanning both protocols.

As AI agents gain persistent memory and state across sessions, the audit and governance scope expands beyond tool calls to memory operations and state modifications. Gateways scoped only to tool call governance will require extension as these capabilities become standard.

The broader trajectory is toward federated multi-gateway architectures: separate gateway instances per business unit or geographic region with centralized policy management. This pattern addresses data residency requirements without requiring monolithic governance infrastructure. Including A2A roadmap questions in current gateway evaluations is forward-looking work that belongs in any RFP issued in 2026.

Wrapping Up,

The teams establishing MCP governance infrastructure now (building audit trails, connecting identity providers, implementing SCIM provisioning, enforcing action-level access policies) are building the foundation for AI adoption that compliance teams can accept and auditors can verify. The teams deferring governance are accumulating technical debt measured not in refactoring effort but in regulatory exposure.

The audit log for last quarter does not exist if it was never captured. The SOC 2 observation period clock does not start until you start running controls. The EU AI Act conformity evidence is not retroactively generatable. The compliance timeline is contracting, and the enforcement mechanisms are real.

For most teams moving from pilot to production, the practical starting point is a managed gateway that handles the ninety-five percent — Composio's MCP Gateway covers the integrations, the OAuth lifecycle, the SCIM provisioning, the action-level RBAC, the audit logging, and the compliance certifications in a single product. The developer quickstart takes ten minutes. The governance is not an afterthought.

Further reading:

A Definitive Comparison Between Opencode & Codex

Developer Harsh — Fri, 03 Jul 2026 10:09:29 +0000

If your daily workflow looks anything like mine, your terminal is where the actual work happens.

After the Claude Code fiasco back in April, I wanted a way out of Claude ecosystem. Codex and OpenCode were the default no-brainer choices.

So I spent the last few months stress-testing Codex and OpenCode to see which one could actually replace Claude Code as my daily driver.

So, here’s what I found out.

TL;DR: Quick Reference

If you are in a hurry, this is the simplest way to think about the comparison.

Codex is the better default. OpenCode is the better power-user tool. Codex wins when I want speed, polish, and fewer setup decisions. OpenCode wins when I want model freedom, lower cost, local execution, and more control over the agent loop.

Section	Winner	Why
Onboarding, Setup, and Daily UX	Codex	Faster to start, cleaner defaults, easier daily workflow
Models	Tie	Codex has the stronger default model stack; OpenCode has far more model freedom and with GLM 5.2 it’s on-par with GPT 5.5
Pricing / Cost	OpenCode	Cheaper for heavy usage if you use routing, caching, or lower-cost models
Features and Workflows	Tie	Codex is better for delegation; OpenCode is better for iterative local work
Ecosystem: MCP, Skills, Plugins	Codex	Simpler MCP and plugin setup; OpenCode is more transparent but more manual
Harness Engineering	Tie	Codex has the better default harness; OpenCode has the more customizable harness
Best overall for most users	Codex	Least friction, strongest defaults, smoother path from prompt to diff
Best overall for power users	OpenCode	Model choice, local execution, deeper control, and better cost optimization

My take: I would recommend Codex to most users first. But for my own high-control workflow, OpenCode becomes more compelling over time because the extra setup turns into flexibility.

1. Onboarding, Setup, and Daily UX

Onboarding and daily UX are too closely related to treat as separate sections.

The first ten minutes decide how quickly I can start. The next ten days decide whether I actually want to keep using the tool. Codex wins the first part because it removes choices. OpenCode becomes more interesting later because the choices start turning into control.

Aspect	Codex	OpenCode
Install speed	~90 seconds, one path	~3-5 minutes, more decisions
First impression	Polished, guided, low-friction	Developer-native, terminal-first, configurable
Provider choice	OpenAI only	75+ providers and 1000+ models
Configuration	Minimal setup after sign-in	API keys, model choice, working directory, config files
Learning curve	Shallow; usable in minutes	Moderate; rewards 1-2 months of use
Daily workflow	Open, assign task, review diff	Plan, inspect, steer, execute, repeat
Customization	Opinionated defaults	Deep control over models, instructions, and local setup
Best for	Users who want the agent to stay out of the way	Power users who want to tune the agent like a dev tool

Codex

I installed Codex in about 90 seconds:

npm i -g @openai/codex
codex

Then it was basically:

sign in with ChatGPT,
pick the project,
start coding.

That is the whole appeal. The model is already selected, GitHub integration feels native, and the default workflow does not ask me to make too many decisions. I can open Codex, describe the task, review the diff, and move on.

This matters because a daily coding agent should not make me think about the agent more than the code.

Codex feels strongest when I need:

a quick prototype before standup,
a PR review,
a clean diff for a narrow task,
a background refactor,
a low-friction path from prompt to patch.

The tradeoff is that Codex is opinionated. I do not get much control over the model strategy, local runtime, or workflow shape. That is fine for most tasks, but limiting when I want to tune the agent like part of my dev environment.

OpenCode

I installed OpenCode with:

curl -fsSL https://opencode.ai/install | bash
opencode

Then the decisions started:

Which provider do I want?
Do I want the Go tier?
Which model should be the default?
Which API keys do I need?
Which working directory should it use?
How much should I configure up front?

That makes OpenCode feel slower on day one. It is not the tool I would recommend to someone who hates setup decisions.

But the same friction becomes useful once I understand the system. OpenCode gives me control over the parts Codex hides:

I can switch providers and models based on task type,
use local models through Ollama or LM Studio,
inspect the plan before execution,
steer the agent step by step,
encode project preferences in instruction files,
keep the loop close to my repo and tools.

This makes OpenCode feel less like a polished single-purpose coding agent and more like a configurable development environment.

The downside is cognitive overhead. OpenCode asks me to participate more, and that is not always what I want for routine work. But for serious refactors, debugging sessions, or production changes where I want to watch the agent think before it acts, the extra control is worth the friction.

Verdict

Codex wins onboarding. OpenCode wins long-term control.

If I am recommending a tool to a teammate who wants the least friction, I would recommend Codex. It is faster to start, easier to understand, and better for users who just want the agent to stay out of the way.

If I am picking a tool for my own high-control workflow, OpenCode becomes more compelling over time. The setup is heavier, but the payoff is model flexibility, local execution, and tighter steering.

For this section, Codex wins because the first-use and default daily experience are cleaner.

OpenCode - 0, Codex - 1

2. Models: Codex vs OpenCode

Aspect	Codex	OpenCode
Model Availability	GPT-5.5 only	~75 providers, 1000+ models
Token Efficiency	Optimized for GPT-5.5	40-60% fewer tokens (MiMo)
Model Switching	Single model, all tasks	Switch between models per task
Top Performers	GPT-5.5 (58.6%)	Qwen 3.7 (60.6%), MiMo-V2.5
Cost Per Token	$30-180 per million tokens	Varies; DeepSeek $0.14-0.28
Best For	Best-in-class performance	Cost-conscious, flexible workflows

Codex

The first time I ran Codex with GPT-5.5, it felt like the whole system was purpose-built around it.

OpenAI’s headline is “better results with fewer tokens.” The more interesting story is how they got there: Codex is a tightly tuned pipeline where the prompts, context management, tool-calling, and evaluation loop are all optimized for GPT models. This is similar to Claude

OpenAI designed GPT-5.5 specifically for agentic coding, then adjusted Codex to leverage its full capabilities. GPT-5.5 uses 40% fewer output tokens than GPT-5.4 on the same Codex tasks.

Every task I run through Codex uses this same tuned pipeline. It's like having a senior engineer trained specifically for your workflow, focused on results, rather than decisions

OpenCode

OpenCode provides integration with ~75 different providers across 1000+ models, and one might be intimidated by the cost they would incur. I had the same.

But as I looked at benchmark data, I found something:

Qwen 3.7 maxes out at 60.6% on SWE-Bench Pro, beating GPT-5.5's 58.6%.
MiMo-V2.5-Pro uses 40-60% fewer tokens than GPT-5.4 for comparable output.
DeepSeek V4-Flash costs $0.14 per million tokens for input / $0.28 for output, compared to $30 per million tokens for input / $180 per million tokens for output for GPT-5.5.

The hidden insight: I don't need the same model for every task.

Architecture decisions: Qwen.
Boilerplate: DeepSeek.
Bug fixing: MiMo.

If you want automation, you can connect OpenCode with smart model routers as well; they will do the heavy lifting.

This was the learning curve I was talking about earlier: model routing.

Verdict

If you ask me:

GPT 5.5 is undeniably the better model than anything open-source can offer right now. Though Kimi 2.7 and GLM 5.2 are great models with near SOTA coding performance.
OpenCode definitely gives the freedom to select any model one wants, plus at a lower cost. For cost-conscious people, this is definitely a USP.

Codex with GPT 5.5 and OpenCode with GLM 5.2 are match made in labs. So, at this point, it’s tie.

OpenCode - 1, Codex - 2

3. Pricing / Cost: Codex vs OpenCode

Aspect	Codex	OpenCode
Entry Price	Plus at $20/month	Go tier at $10/month
Professional Cost	$100-200/month	$10-50/month (with routing)
Cost Savings	No optimization options	~70% reduction with smart routing
Token Caching	Limited caching	Built-in, reduces cost ~70%
Pricing Model	Monthly subscription fixed	Pay per token (variable)
Best For	Predictable monthly budgets	Budget-conscious developers

Codex

Codex comes bundled with ChatGPT Plus at $20/month, which sounds cheap until you start using it heavily.

Here's my actual usage pattern:

Lightweight tasks: 2-3 sessions/day (covers with Plus)
Serious refactoring: 4-7 hours/day (exhausts Plus)

When I upgraded to Pro ($100/month), things got a little smoother. I never hit limits. But I'm now paying $1,200/year for what I actually use.

That’s not a number; it's the real cost for a professional who codes 6+ hours/day, which is around $100-$200/month.

OpenCode

OpenCode Go is $10/month or less, but only if you actually need to figure out which models to use for which tasks.

Here's my actual usage pattern:

Day 1: Confused about model selection (burning tokens on wrong model choices)
Day 10: I figured out routing: Boilerplate → one model, Architecture → another, token cost starts dropping
Day 30: Smart routing is dialed in (DeepSeek for routine, Qwen for complex, local models for edge cases), making costs fixed around $10/month tier

When I finally cracked the model-routing puzzle by month 2, I realized the real hidden advantage:

Cached tokens cost a fraction of the normal price. So my $0.50/session cost was actually closer to $0.15 with caching baked in.

According to the estimate, the real cost for a professional with smart routing is around $10-$50/month.

That’s a ~70% deduction and makes switching non-negotiable.

Verdict

Clearly, Open Code wins on this one.

OpenCode - 2 , Codex - 2

3. Features and Workflows

This is where Codex and OpenCode start to feel like fundamentally different products.

Codex is built around delegation. OpenCode is built around iteration.

Aspect	Codex	OpenCode
Core workflow	Define goal → delegate → review result	Plan → review → execute → adjust
Best interaction style	High-level task assignment	Tight local feedback loop
Goal setting	`/goal` command for scoped outcomes	Plan mode + repo instructions
Iteration speed	Better for longer background tasks	Better for fast back-and-forth changes
Local capability	Cloud-first	Local-first with Ollama/LM Studio support
Real-time control	Review changes after the agent runs	Review and steer before execution
Best for	Overnight refactors, PR prep, delegated work	Interactive development, debugging, learning

Codex

Codex feels strongest when I treat it like an engineering teammate I can delegate to.

The app lets me set up multi-agent workflows for longer-running execution:

One agent reviews PRs,
another fixes bugs,
a third updates documentation.

I close my laptop and come back to the result. That makes Codex especially good for large refactors, GitHub-native workflows, team delegation, and background engineering work.

The underrated feature here is Codex’s /goal command. Instead of giving the agent a vague task like “improve this repo,” I can define the actual outcome I want:

reduce flaky tests,
migrate a module,
clean up auth logic,
prepare a PR-ready refactor.

Codex then uses that goal as the anchor for planning, execution, and review. That makes long-running delegated work feel less like prompting and more like assigning a scoped engineering objective.

OpenCode

OpenCode does not have a direct /goal equivalent, but its workflow solves the same problem differently.

Instead of asking me to assign a goal and wait for the result, OpenCode keeps me inside a tight loop:

define what I want,
inspect the proposed plan,
adjust the approach,
execute,
review the result,
repeat.

This is where Plan mode becomes important. It gives me a goal-like workflow without hiding the intermediate reasoning. I can see what OpenCode intends to do before it touches the codebase, which is useful when I am debugging, exploring unfamiliar code, or doing refactors where I want control over every step.

OpenCode also pairs well with repo-level instruction files like AGENTS.md. That makes its goal-setting less polished than Codex’s /goal, but more customizable. I can encode project conventions, testing expectations, architecture rules, and workflow preferences once, then reuse them across sessions.

The other major advantage is local execution. I can pair OpenCode with Ollama or LM Studio and run the agentic loop on my own machine with zero API calls. For security-sensitive work, regulated codebases, or local-first development, this is a real advantage.

Verdict

This one depends on how I want to work.

Codex wins for delegation: give it a scoped objective, let it run, and review the result later.
OpenCode wins for iteration: inspect the plan, steer the agent, and keep the feedback loop tight.
Codex feels more polished. OpenCode feels more controllable.

For routine background work, I prefer Codex. For interactive development and learning inside a codebase, I prefer OpenCode.

Tie.

OpenCode - 3, Codex - 3

4. Ecosystem (MCP + Skills + Plugins)

Aspect	Codex	OpenCode
MCP Setup	CLI commands (`codex mcp add`)	Manual config via `.opencode/mcp-config.json`
Skill Installation	Git clone to `~/.codex/skills/`	Clone to `~/.opencode/skills/`
Plugin Management	Marketplace CLI integration	Update `opencode.json` manually
Composio Integration	One-click via marketplace	Config file + manual setup
User Friendliness	More convenient, less transparent	More transparent, less convenient
Best For	Users who want simplicity	Developers who like transparency

You can have the best model, the best providers, and the best features and workflow, yet it means nothing if your models can’t talk to the real world and perform specified tasks in specified ways.

Codex and OpenCode both offer: MCP, Plugin & Skills, but both function differently.

Codex

Codex supports MCP integration. This is how easy it is to install:

I am going with Composio, as I usually use multiple MCP servers, and it's a pain to connect to and configure each one securely and to make agents handle multiple tool calls intelligently.

# Add Composio MCP server to Codex
codex mcp add composio

# Authenticate
codex mcp auth composio
# Opens browser for OAuth

Verify it's connected:

codex mcp list

Now, to make sure the MCP works properly, you can add skills with:

mkdir -p ~/.codex/skills
git clone https://github.com/ComposioHQ/awesome-codex-skills.git ~/.codex/skills/composio-connect
# Restart Codex

You can also add the Composio plugin using:

codex plugin marketplace add ComposioHQ/awesome-codex-plugins

And restart the app:

codex

But to do the same in OpenCode is a little tricky.

Open Code

OpenCode also supports MCP integration, but to add any MCP server, you need to update the config at .opencode/mcp-config.json .

# .opencode/mcp-config.json
{
  "mcp_servers": {
    "composio": {
      "type": "remote",
      "url": "https://connect.composio.dev/mcp"
    }
  }
}

Certainly not the most friendly interface, but good for transparency, as you can see what goes into the MCP server.

Next, add skills:

git clone https://github.com/ComposioHQ/awesome-codex-skills ~/.opencode/skills/composio

Restart OpenCode

opencode

This works because OpenCode looks for skills in project and global locations, including .opencode/skills, ~/.config/opencode/skills, .claude/skills, and .agents/skills .

You can also add the Composio plugin:

Add to opencode.json

{
  "plugin": [
    "opencode-composio",
    "opencode-context7"
  ]
}

Save and restart OpenCode:

opencode

Done!

Verdict

So Codex wins here due to process simplicity.

Open Code - 3 , Codex - 4

5. Harness Engineering

The model matters, but the harness decides how that model sees the repo, plans changes, calls tools, handles errors, and recovers when something breaks. In practice, the harness is the difference between “the model is smart” and “the agent is reliable.”

Aspect	Codex	OpenCode
Implementation	Rust-based, performance-focused CLI/app stack	TypeScript core with Tauri desktop app
Design philosophy	Tightly optimized around OpenAI models	Provider-agnostic and modular by design
Context handling	Strong default repo understanding with fewer choices	More explicit control over model, context, and instructions
Tool execution	Permission profiles, hooks, sandboxed/cloud execution	Local execution with permission gates and config-level control
Feedback loop	Optimized prompting, planning, and tool-calling pipeline	LSP diagnostics fed back into the agent loop
Strength	Speed, polish, and low-friction execution	Control, transparency, and production thoroughness
Tradeoff	Less model/harness customization	More setup and slower execution
Best for	Fast implementation and delegated engineering tasks	Complex refactors where correctness matters more than speed

Codex

Codex feels like a vertically integrated agent stack.

The model, prompt format, context strategy, tool-calling behavior, permission model, and review flow all feel designed to work together. That is the advantage of a closed, OpenAI-first harness: fewer knobs, fewer setup decisions, and fewer ways to misconfigure the system.

The strongest part is how little I have to think about the plumbing:

permission profiles decide what the agent can touch,
hooks let me run pre- and post-execution checks,
GitHub and PR workflows feel native,
tool calls are routed through a polished approval flow,
cloud execution keeps risky changes away from my local machine until review.

Everything is tuned around GPT-5.5. That matters because Codex is not just calling a model; it is shaping how the model receives the repo, plans the task, executes commands, and presents diffs back to me.

This is why Codex often feels faster than a generic agent using the same model. The harness reduces wasted motion. It does not ask me to design the workflow first; it gives me a working default and lets me move.

The downside is that this optimization comes with a ceiling. If I want to change the model strategy, deeply customize the execution loop, or route different tasks through different providers, Codex gives me much less room to experiment.

OpenCode

OpenCode takes the opposite bet.

Instead of optimizing one model inside one polished workflow, it gives you a modular harness that can work across providers, models, local runtimes, MCP servers, and repo-level instructions. It is less “batteries included,” but much more inspectable.

The most important engineering choice is the feedback loop. OpenCode can feed Language Server Protocol diagnostics back into the agent while it works. If the agent introduces a TypeScript error, the next step can include that error as context, so the model has a chance to self-correct before I even review the final diff.

That changes the feel of the tool. OpenCode may be slower, but it often behaves more like an engineer working with compiler feedback, not just a chatbot editing files.

It also gives me more control over the harness itself:

I can switch providers and models based on task type,
keep project-specific behavior in AGENTS.md,
run locally with Ollama or LM Studio,
wire in MCP tools manually,
inspect config instead of trusting a black box.

This is why OpenCode tends to feel better for production refactors. The loop is tighter, the configuration is more visible, and the agent can use local development signals instead of only relying on the initial prompt and repo context.

The tradeoff is obvious: more control means more responsibility. If the model choice is bad, the config is messy, or the repo instructions are vague, OpenCode will not hide that complexity from me.

Verdict

Codex has the better default harness. OpenCode has the better customizable harness.

Codex wins on speed and polish: it is optimized end-to-end for OpenAI models and gets me to a usable diff quickly.
OpenCode wins on control and feedback: LSP diagnostics, local execution, and provider flexibility make it stronger for careful refactors.
Codex abstracts the harness away. OpenCode exposes the harness and lets you tune it.

For a quick implementation, I would pick Codex. For a high-stakes refactor where I want visibility into every step, I would pick OpenCode.

This one is a tie, but for very different reasons.

OpenCode - 4 , Codex - 5

The Final Verdict: When To Choose What

Clearly, OpenCode is the winner with 6 points, but real engineers leverage both for their specific needs :

Codex for speed, overnight refactors, and production-critical work.
OpenCode for smart model routing, optimized costs, and offline critical workflows.

A simple table summarizes them.

	Codex	OpenCode
Best for	OpenAI ecosystem	Cost control, model flexibility
Setup	Zero friction, bundled into ChatGPT subscripton	Configure providers; slight model usage learning curve
Autonomous work	Cloud agent, good for overnight refactors	Terminal agent; depends on your model
Integrations	GitHub, PR review, Slack	MCP; varies by setup
Model choice	GPT-5 only	75+ providers; Claude via API key only
Offline	No	Yes, with Ollama/LM Studio
Transparency	Token-based credits	Full model + token visibility
Real cost	$20–$200/mo	Free BYOK, or ~$10–$50/mo routing

With a few months of usage, one thing is clear to me,

Choosing Codex or Opencode models is not about which benchmarks perform better; it's about picking the one that matches your workflow. Both are good in their own right, and best leveraged based on the needs.

Claude Code vs. OpenCode without the hype

Shrijal Acharya — Thu, 21 May 2026 13:55:18 +0000

Everyone wants a coding agent now.

Not a chatbot that explains code.

An actual agent that can read your repo, edit files, run commands, use tools, and keep moving while you supervise.

Claude Code and OpenCode are two of the most interesting takes on that idea.

Claude Code is the polished Anthropic-native route.

OpenCode is the open-source route for people who want more model choice, more control, and a setup they can tweak.

And that difference matters more than it looks.

What is OpenCode

ℹ️ Open-source coding agent with model and tool control

OpenCode is an open-source coding agent for developers who want more control over their AI coding setup.

It runs in the terminal, IDE, and desktop, and lets you bring your own model instead of locking you into one provider. Claude, GPT, Gemini, local models, and 75+ other providers are supported. That is probably the biggest reason people care about it.

It also comes with the things you expect from a serious coding agent now: LSP support, multi-session workflows, project memory through AGENTS.md, MCP tools, custom agents, plugins, and editor support, and maybe a bunch more.

So the pitch is not just “AI in your terminal.”

That undersells it.

OpenCode is closer to a coding-agent workbench. You bring the model, the provider, the editor, the agents, and the workflow. OpenCode gives you the open layer that ties it all together.

Not everyone needs that level of control.

But some developers absolutely do.

💁 OpenCode is for developers who want to tweak every single detail of their coding agent.

That is what makes it interesting next to Claude Code.

What is Claude Code

ℹ️ Anthropic’s polished coding agent for your terminal.

Claude Code is Anthropic’s coding agent that lives in your terminal.

The idea is pretty same here, it can read your codebase, edit files, run commands, handle Git stuff, and all through prompts.

The big difference is that Claude Code is built around Claude.

That sounds obvious, but it matters.

You are not coming here to mix and match ten different model providers. You are coming here because you trust Anthropic’s models, and you want the cleanest experience around them.

Claude Code also comes with a lot of serious agent features: project memory through CLAUDE.md, slash commands, permissions, hooks, MCP, plugins, custom subagents, and IDE integrations.

Claude Code is closer to a Claude-native coding environment. The model, the agent loop, the tool use, the permissions, and the workflow all come from the same Anthropic-shaped box.

Less DIY.

But there is also a small shift happening.

Some developers are starting to move from Claude Code to OpenCode or OpenAI’s Codex for one simple reason: usage limits.

Claude Code is great, but when you are deep in a coding session, hitting limits feels brutal. And for heavier users, even the $200 Claude Max plan does not always feel like enough.

That is why OpenCode and Codex are tempting. Also read: Claude Code vs. Codex: Detailed breakdown

When Claude hits the wall, people still need a way to keep shipping.

💁 If you're an Anthropic fanboy, and don't care about other models, stick to Claude Code.

High Level Architecture

ℹ️ How both the agents work

At a high level, both OpenCode and Claude Code follow the same basic agent loop.

You give it a task.

It looks at the repo.

It decides what files, commands, or tools it needs.

It takes an action.

Then it reads the result and keeps going.

ℹ️ This is the highest-level architecture of a coding agent. A few details change from tool to tool.

That loop is the boring part.

The interesting part is everything around it.

Here is a tiny example of that loop in practice.

I gave Claude Code and OpenCode the same small task in a demo word-count repo:

Add a --json flag to a word-count CLI, update the tests, and run them.

The interesting part is not the feature. It is watching both agents go through the same shape: understand the repo, plan the change, edit the files, and run the tests.

Claude Code wraps that loop in Anthropic’s own product system. You get Claude, project memory through CLAUDE.md, permissions, hooks, MCP, plugins, Claude skills, and subagents in one single setup.

OpenCode takes a more open route. It gives you the agent runtime, but lets you bring different models, providers, agents, tools, and workflows. Its docs split agents into primary agents and subagents, and let you configure specialized assistants with custom prompts, models, and tool access.

So architecturally, the difference is not that one is an agent and the other is not.

They both are.

The real difference is who controls the harness around the agent.

Claude Code gives you Anthropic’s harness.

OpenCode gives you a harness you can inspect, and configure.

Context, memory and tool use

Both Claude Code and OpenCode are doing the same basic thing: they build a giant prompt, stuff it with repo context, tool definitions, memory files, recent messages, and tool results, then ask the model what to do next.

The difference is how much of that system you control.

Claude Code is more vertically integrated here. It is built around Anthropic models, so it can take advantage of Anthropic-specific stuff like prompt caching, native tool calls, and Claude’s own long-context behavior.

That matters.

Tool definitions, system prompts, and CLAUDE.md can be cached between turns, which makes long coding sessions cheaper and faster than they would be if Claude had to re-read everything from scratch every single time.

OpenCode takes a different route.

It does not assume one model or one provider. Instead, it reads the model’s context limit from the provider metadata and builds the session around that. So the same OpenCode setup can run with Claude, GPT, Gemini, Qwen, local models, or whatever else you plug in.

That flexibility is the whole point.

But it also means OpenCode has to normalize all the weird provider differences: tool call IDs, cache support, model limits, and tool-calling parts.

Claude Code gets to optimize deeply for Claude.

OpenCode has to work with everyone.

Memory works the same way.

Claude Code uses CLAUDE.md as the main project memory file. It can also load nested CLAUDE.md files, user-level memory, and auto-memory. So it feels more like the agent has a built-in memory system.

OpenCode uses AGENTS.md.

That is more portable. You can commit it to the repo, share it with the team, and use it as a general agent instruction file instead of something tied to one vendor. OpenCode can even fall back to CLAUDE.md, which makes migration easier.

At some point, every agent runs out of context.

Claude Code handles this by compacting the conversation. Older tool outputs are cleared first, then the session gets summarized if needed. That is why Claude Code has commands like /context and /compact.

OpenCode is a bit more explicit. It checks whether the session is close to the model’s context limit, keeps a buffer for output, and then prunes old tool outputs before doing a full summary. The important bit is that OpenCode stores the raw history in SQLite, so pruning does not mean the data is gone forever.

Tool use follows the same pattern.

Claude Code gives you a polished default toolbelt: read, write, edit, grep, glob, bash, web fetch, todo tracking, MCP, hooks, skills, and subagents.

OpenCode gives you a smaller but more configurable tool system: read, write, edit, patch, bash, grep, glob, web fetch, task, todo, skills, MCP, custom tools, and experimental LSP support.

The difference is who controls the tool layer.

Subagents and task delegation

Subagents are basically how coding agents avoid stuffing everything into one giant conversation.

Instead of making the main agent do every task itself, it can delegate a smaller job to another agent with its own context window, prompt, tools, and permissions.

Claude Code and OpenCode both follow the same basic pattern here.

The parent agent calls a Task or task tool.

A child agent spins up.

It does the work in isolation.

Then it returns one final message back to the parent.

Main Agent
  |
  | calls Task / task
  v
Subagent
  - own context window
  - own prompt
  - own tools
  - own permissions
  |
  | returns final result only
  v
Main Agent continues...

That part is important. The parent usually does not see the full subagent conversation. It gets the result, not the whole reasoning.

Claude Code has the more polished version of this.

It ships with built-in agents like Explore, Plan, and general-purpose. Explore is mostly read-only and useful for repo research. Plan helps gather context during planning. general-purpose is for broader work.

You can also define custom agents in .claude/agents/ with YAML frontmatter for things like tools, model, permissionMode, maxTurns, skills.

That means you can do stuff like:

Use a fast Haiku-style agent for repo search.

Use a stronger model for code review.

OpenCode has a similar shape, but it is more transparent.

It has primary agents and subagents. Primary agents handle the main chat, while subagents are called through the task tool or @ mentions.

Custom agents can live in .opencode/agents/*.md or inside opencode.json, with fields like mode, model, temperature, steps, prompt, and permission.

The interesting part is that OpenCode stores subagents as real child sessions in SQLite. So delegation is not just a hidden prompt trick. It is represented in the session model with its own messages, permissions, and snapshots.

That fits OpenCode’s whole philosophy.

Claude Code gives you a cleaner subagent experience.

OpenCode gives you a more inspectable one.

Permissions, safety, and control

This is where the two are very different.

Claude Code is more conservative by default. It has permission modes, allow/ask/deny rules, hooks, and sandboxing around Bash.

So you can allow boring commands like tests, deny obvious footguns like .env reads or curl | sh, and ask before anything risky.

The important part is that Claude Code has multiple safety layers.

Permissions decide what Claude is allowed to do.

Something like:

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Bash(git status *)"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl *)"]
  }
}

Hooks can intercept tool calls before or after they run and sandboxing gives Bash an OS-level boundary.

OpenCode is simpler.

Most of the control lives in one permission object inside opencode.json. You can set rules for bash, edit, read, task, webfetch, and other tools from the same place.

That is clean, but OpenCode is also more permissive by default. You are expected to configure the rules yourself.

Something like:

{
  "permission": {
    "*": "ask",
    "bash": {
      "*": "ask",
      "git status *": "allow",
      "git push *": "deny",
      "rm *": "deny"
    },
    "edit": {
      "*": "deny",
      "packages/web/src/**/*.tsx": "ask"
    }
  }
}

It does have some smart checks, especially for Bash. OpenCode parses shell commands with tree-sitter (the same thing you have inside NeoVim), so it can detect risky commands like rm, mv, chmod, or paths outside the project more carefully than plain string matching.

But there is no native sandbox like Claude Code.

The bigger OpenCode power feature is plugins. Plugins can intercept tool execution, add custom tools, and change agent behavior.

That makes OpenCode way more hackable.

What the Claude Code leak tells us

The interesting part of the leak is what it showed about coding agents.

A lot of Claude magic is in the harness around the model: context management, tool descriptions, prompt caching, permissions, compaction, subagents, and the agent loop.

OpenCode does pretty much the same. It is not trying to clone some impossible model-level feature. It is trying to build a different harness around similar idea.

OpenCode’s advantage is that the harness is open, inspectable, and replaceable.

Another thing that's clear is that the future is not just about better models, but the system around them.

Better context control.

Better tool boundaries.

Better memory.

Better permissions.

That is why this comparison is even interesting. Claude Code and OpenCode are not just two CLIs. They are two different answers to the same question:

❓ How much of the agent stack should be final, and how much should developers be able to control?

So, which should you pick?

There is no clever answer here.

Pick Claude Code if you want the cleanest Claude-native coding agent experience.

Pick OpenCode if you want more control.

Personally, I still love Claude Code.

I really do.

Anthropic models are banger, especially for coding. The problem is that the limits have started to piss me off. When you are deep in a coding session and the limit hits, it completely breaks the flow.

But there is some relief now.

On May 6, Anthropic announced a new compute partnership with SpaceX and doubled Claude Code’s 5-hour limits for Pro, Max, Team, and seat-based Enterprise users. They also removed peak-time limits for Pro and Max users.

That makes Claude Code a lot easier to recommend again.

I am personally still mostly stuck with Claude Code because the experience is just that good.

But I use OpenCode when I want to try newer models like Kimi, OpenAI models, or local models. That is where OpenCode makes more sense to me. And by no means, it is to say that you can't use Anthropic models in OpenCode, you can, and that makes it even better.

Final thoughts

Claude Code and OpenCode are both useful, but for different reasons.

Claude Code is the one I’d pick if I just want the agent to work without thinking too much about setup. It feels cleaner, and better for getting into a repo quickly.

OpenCode is more for when you want control. Different models, different providers, more ways to shape the workflow around how you actually code.

I wouldn’t overthink it.

If you hate setup and love Anthropic, use Claude Code.

If you want more flexibility and less vendor lock-in, use OpenCode.

That’s really the whole comparison.

Shrijal AcharyaFollow

SDE • GOLD @Microsoft Student Ambassador • Prev Lead Collab and Dev-Team Lead @oppiaorg • Mail for collaboration

Per-User OAuth for AI Agents: Why It Matters and What to Look For

Dumebi Okolo — Wed, 20 May 2026 14:21:08 +0000

AI agents are crossing a line that traditional software never had to. They read your Slack, draft your emails, push code, update your CRM, and pay your invoices. To do that, they need keys to systems that belong to specific people. Not the application. Not the company. The person.

That is the entire reason per-user OAuth exists in the agent context, and it is the difference between a side project and something a customer will trust with their Gmail account.

This article breaks down what per-user OAuth means for AI agents, why shared credentials fall apart at scale, what the emerging standards look like, and the exact checklist to use when picking a platform to handle it. We will also show how Composio approaches each of these problems so you do not have to assemble the stack yourself.

The problem with the way most teams start

Most agent prototypes start with a single API key in an environment variable. It works for one developer, on one machine, for one demo. The moment a real user shows up, the model breaks.

API keys identify the calling application, not the user behind the action. Every request from the agent looks the same to the downstream service. There is no concept of consent, no scoping per user, no way to revoke one person's access without invalidating everyone, and no audit trail that says "this action happened because Sarah asked the agent to do it."

This becomes a real security problem fast. If the agent code accidentally passes the wrong user identifier, or an attacker tricks the agent into requesting data for a user who did not authorize it, the agent has no protocol-level defense. This is the classic confused deputy problem, and it scales horribly with autonomous systems that chain dozens of tool calls per task.

Composio's own guide on AI agent infrastructure calls this hitting the "Authentication Wall." It is the moment a promising prototype stops being promising.

What per-user OAuth actually solves

Per-user OAuth flips the model. Instead of the agent holding one master credential, each user grants the agent a scoped, revocable token tied to their own account. The agent acts with that user's identity, within the limits that user approved, for as long as that user allows.

Concretely, this gives you:

Explicit consent. The user sees what the agent is asking for and approves it. No assumed access.

Scoped permissions. The token can be limited to read-only access on a specific resource rather than full account control. If the agent only needs to read, that is all it gets.

Short lifetimes. Access tokens expire in minutes to an hour. Refresh tokens rotate. A leaked token is dangerous for a short window, not forever.

Selective revocation. Revoking one user's grant does not break the agent for everyone else.

Identity in the audit log. Every action traces back to a specific user, which is what SOC 2, HIPAA, and ISO 27001 actually require.

Multi-tenant isolation. Each user's tokens live in their own bucket, encrypted at rest. A bug in one tenant's workflow does not expose another tenant's data.

That last one matters more than people think. Composio's user and session model is built around exactly this idea: a user is an identifier from your app, every connection lives under that user's ID, and connections are fully isolated between users. The same agent code can serve thousands of users without any of them ever touching each other's data.

The standards that are actually shaping this

The protocol layer is moving fast. There are three things worth knowing.

OAuth 2.1 with mandatory PKCE

OAuth 2.1 is the current best-practice consolidation of OAuth 2.0. It makes PKCE (Proof Key for Code Exchange) mandatory and removes older, less secure flows. PKCE matters specifically for agents because most agents are public clients running in environments where you cannot reliably hide a client secret. PKCE prevents an attacker from intercepting an authorization code mid-flow.

If a platform you are evaluating does not enforce PKCE, that is a red flag.

The MCP Authorization spec

The Model Context Protocol authorization specification formalized OAuth as its standard in 2025. It mandates OAuth 2.1 with PKCE, requires Authorization Server Metadata discovery via RFC 8414, and supports Dynamic Client Registration via RFC 7591. The November 2025 update added step-up authorization, letting clients request additional scopes only when an operation actually requires them, rather than over-permissioning the initial token.

The spec also had a real-world security crisis to address. In late 2025, security researchers at Obsidian Security disclosed one-click account takeover vulnerabilities in remote MCP servers from several well-known organizations. The root cause: many MCP servers were implemented as OAuth proxies using a single static client_id to talk to the upstream SaaS authorization server. Once any user consented for that shared client_id, the SaaS auth server cached the decision. An attacker could then complete the MCP-layer consent themselves, send a crafted authorization link to a victim, and the upstream server would skip the consent prompt entirely because it had seen that client_id before. The authorization code would be issued to the attacker's redirect URI.

The fix is per-client identity and strict consent handling at the proxy layer. Composio's Tool Router gives each session a secure, user-scoped MCP URL rather than a shared endpoint, which sidesteps this class of attack structurally.

The IETF "On-Behalf-Of" draft for AI agents

There is an active IETF draft, draft-oauth-ai-agents-on-behalf-of-user, that extends OAuth specifically for agent delegation. It adds a requested_actor parameter so the consent screen shows the agent's identity (not just the app), and an actor_token parameter so the agent authenticates itself when exchanging the authorization code.

The result is an access token that documents the full delegation chain: the user delegated to this client application, which delegated to this specific agent. That chain is what makes after-the-fact auditing possible.

The draft is at revision 02 as of August 2025 and has not been adopted by the working group yet, but it points clearly at where the protocol layer is headed. Multi-hop delegation (agent A calling agent B on the same user's behalf) is still an open problem in the spec.

Production architecture: where teams fail

Getting an access token is the easy part. Operating at production scale is where most homegrown OAuth implementations collapse. Five things tend to go wrong.

Token storage. Tokens have to be encrypted at rest, isolated per tenant, never logged, and never placed in LLM context. The last point is non-obvious and critical: if you put a refresh token in the prompt, a prompt injection attack can exfiltrate it. The pattern to use is brokered credentials, where the LLM never sees the token at all and a separate service makes the actual API call.

Composio's secure infrastructure guide explains this pattern directly: the LLM asks Composio to perform an action, Composio calls the upstream API with the stored credential, and the token never enters the model's context window.

Refresh handling. Refresh tokens need proactive coordination. Waiting for a 401 error and then refreshing creates race conditions, cascading retries, and unstable background jobs. Composio handles refresh automatically and only marks a connection as EXPIRED after multiple refresh attempts have failed, according to its authentication docs.

Scope discipline. Composio requests sensible default scopes for each toolkit but lets you override them via custom auth configs. Tightening scopes shrinks the blast radius if something goes wrong. Most APIs still have coarse-grained scopes, which means even with discipline, agents tend to be over-permissioned. The mitigation is short token lifetimes and per-tool scoping where the API supports it.

Branding and consent screens. When users hit an OAuth consent screen that says "Composio wants to access your Gmail" instead of "YourProduct wants to access your Gmail," conversion drops and trust takes a hit. Composio's white-labeling support lets you bring your own OAuth app credentials so the consent screen shows your brand. Use managed apps for prototyping and your own credentials for production.

Multi-account per user. Some users connect a personal Gmail and a work Gmail. The platform needs to model that without forcing them to share a user ID across both. Composio handles this with the connected account ID layered under the user ID, so a single user can have multiple accounts on the same toolkit, as documented in the users and sessions guide.

What to look for in a per-user OAuth platform for agents

If you are evaluating providers, these are the non-negotiables:

Per-user token isolation with encryption at rest and no cross-tenant leakage
OAuth 2.1 with mandatory PKCE for all OAuth flows
Automatic, proactive token refresh that does not depend on the client
Short-lived access tokens with rotating refresh tokens
Granular scope configuration so each integration uses least privilege
Brokered credentials so the LLM never sees raw tokens
Selective per-user revocation without affecting other users
Audit trail on the delegation chain for compliance
White-label OAuth consent screens for production trust
Step-up authorization to request new scopes only when needed
Multi-account per user for personal and work accounts on the same app
MCP-native deployment so any MCP-compatible client can use the same auth layer
SOC 2 Type 2 and ISO 27001 compliance as table stakes for enterprise customers
SDK support across major frameworks (LangChain, CrewAI, OpenAI Agents SDK, Claude Agent SDK, Mastra, Vercel AI SDK, LlamaIndex)

Composio covers every item on that list today. It supports 500+ toolkits, handles OAuth end-to-end with user-scoped tokens, is SOC 2 Type 2 and ISO 27001 compliant, and works as both a direct SDK and an MCP server. The full feature breakdown is on the AgentAuth product page and the comparison guide.

What this looks like in code

Per-user OAuth with Composio compresses into a handful of lines. The pattern below follows the current SDK as documented in Composio's authenticating tools guide.

First, install the SDK and set your API key:

pip install composio
export COMPOSIO_API_KEY=your_api_key_here

To trigger the OAuth flow for a specific user, use the hosted Connect Link pattern. This returns a redirect URL the user opens in their browser to complete authentication:

from composio import Composio

composio = Composio(api_key="your_api_key")

# Use the "AUTH CONFIG ID" from your Composio dashboard
auth_config_id = "your_auth_config_id"

# Use a unique identifier for each user in your application
user_id = "user_1349_129_12"

connection_request = composio.connected_accounts.link(
    user_id=user_id,
    auth_config_id=auth_config_id,
    callback_url="https://your-app.com/callback"
)

redirect_url = connection_request.redirect_url
print(f"Visit: {redirect_url} to authenticate your account")

After the user completes the flow, Composio stores the tokens, links them to that user ID, and handles refresh automatically. The agent code never touches the token directly.

To fetch tools scoped to a specific user, pass that same user ID:

from composio import Composio

composio = Composio(api_key="your_api_key")

user_id = "user_1349_129_12"

# Tools are automatically scoped to this user's connected accounts
tools = composio.tools.get(user_id=user_id, toolkits=["GITHUB", "GMAIL"])

Two users running the same workflow get two different sets of credentials applied transparently:

tools_user_1 = composio.tools.get(user_id="user_1", toolkits=["GITHUB"])
tools_user_2 = composio.tools.get(user_id="user_2", toolkits=["GITHUB"])

# Each set of tools uses the respective user's credentials
# when invoked by an agent

That is the whole point of per-user OAuth: the auth layer disappears into the platform, and the agent code reads like it is talking to a single user even when it is serving thousands.

For a full working example with an LLM framework, see the framework-specific quickstart guides in Composio's documentation.

The takeaway

Per-user OAuth is not a feature you bolt onto an agent product later. It is the foundation that decides whether your agents can serve real customers at all. Shared API keys cap your ceiling at a single-user demo. Per-user OAuth opens the door to multi-tenant production deployment, enterprise compliance, and the kind of trust required to handle a customer's inbox, calendar, or revenue pipeline.

The protocol layer is still evolving. OAuth 2.1, the MCP authorization spec, and the IETF on-behalf-of draft are all converging on the same answer: explicit user consent, scoped delegation, audited token lifecycle, and isolation per user. Build for that model now and you will not need to retrofit later.

If you would rather skip the months of building it yourself, start with Composio or read the auth-to-action guide for the full architecture. The shortest path from prototype to production is using a platform that already solved this.

I Took Cursor Agents Out of the IDE and It Got Weirdly Powerful 🤯

Developer Harsh — Tue, 19 May 2026 10:05:31 +0000

Cursor recently released their cursor agents SDK to the public, and it's quietly powering many teams to:

invoke agents directly from CI/CD pipelines,
create automations for end-to-end workflows,
and embedding agents into core products.

Basically, the SDK lets developers deploy agents without overthinking building and maintaining the entire agent stack

in this blog I give a glimpse of what is possible with the cursor agents SDK and how to overcome the restrictions of limited tool access.

Let's start with a brief overview of cursor agents.

A Primer On Cursor Agents SDK

Building an agent from scratch is a massive headache. Cursor SDK skips the
plumbing.

Before the SDK, Cursor was strictly an interactive IDE, but its newly released SDK turns that
agentic power into headless infrastructure.

It uses the same harness that powers the desktop app, meaning you get IDE-grade code generation programmatically.

Harness: context engine, workspace management, and routing

In fact, the cursor harness matters more than the model. Endor Labs benched
GPT-5.5 natively at 61.5% functional correctness. Then, dropping the same model into Cursor's harness, it scored 87.2%.

Cursor spent years tuning the context management and tool dispatch; the SDK hands you that refined engine.

Here is the spec list for those who care:

Spec / Feature	Technical Detail
The Harness	Built-in codebase indexing, semantic search, & instant grep.
Execution	Cloud (sandboxed VMs with durable state), Self-Hosted, Local.
Models	Agnostic. Uses `composer-2/composer-3` (default), Claude, or OpenAI.
Integrations	Deep MCP support, auto-loaded `.cursor/skills/`, & hooks.
Subagents	Main agent can spawn subagents with distinct prompts/models.

This means we have a perfect stack to build our agent. Let’s get started with the setup.

How to Set Up Cursor Agents SDK

You can install it using npm to get started, then use Cursor's native cursor SDK skill for guidance.

So open your terminal and type:

npm install @cursor/sdk

Output

Once done, install the cursor skill for guiding the cursor / Claude Code. In the same terminal, run:

npm add skills /cursor-sdk

But there is a catch: by default, the Cursor SDK agents ship with a few default tools + MCP support.

However, this means connecting to or configuring multiple MCP servers is such a hassle for a production-grade product.

So let's automate it with Composio as the orchestrator, connect and configure it once, and you get secure access to 1000+ tools with optimized tool calls and context.

Building a Production Agent With Composio MCP + Cursor Agent SDK

Why Composio?

Composio offers a single MCP server you can plug into with the Cursor SDK to access 1000+ apps instantly.

When you’re building an agent that requires interacting with external applications, let’s say a Sales agent with Gong, HubSpot, Salesforce connectors, etc., you’d spend weeks on partnerships and integrations. Composio completely removes this friction, so you build what matters

So, let’s explore one example of a GitHub agent that pulls the repository, analyzes it, creates a dev branch, performs automatic refactoring, pushes the code, and opens a PR for review - a simple but powerful use case.

Let's begin!

Setup Workspace

Head to the terminal and run the following commands

mkdir cursor-agent
cd cursor-agent
npm init -y
npm install typescript ts-node @types/node --save-dev
npx tsc --init

The command will create a new project named cursor_agent , switch to the folder, initialize a blank npm project (ensure package.json gets created), install typescript support for development, and initialize the typescript compiler and linter.

Since our repository is set up, let’s configure environment variables.

Set up Environment Variables

Add a .env file to keep secrets secure and add the following values:

CURSOR_API_KEY=your-cursor-api-key
COMPOSIO_API_KEY=your-composio-api-key

You can get the CURSOR_API_KEY by going to the Cursor integration page and creating a new API key.

For COMPOSIO_API_KEY , visit the Composio Dashboard (Platform), log in/sign up to the account, and head to the default project (or create one) → profile→ API KEY.

Click “Create One”, it creates one, copy and then paste it into .env . Make sure it starts with ak_ .

Time to write the code.

The Code

Now, create a new index.ts file and paste the following code.

// imports
import "dotenv/config";
import * as readline from "node:readline/promises";
import { stdin as input, stdout as output } from "node:process";
import type { SDKAgent } from "@cursor/sdk";
import {
  DEFAULT_USER_ID,
  disposeAllAgents,
  getComposioApiKey,
  getOrCreateRuntime,
  requireEnv,
} from "./runtime.ts";

// log tool calls to stdout
function logToolCall(
  name: string,
  args: unknown,
  status: "running" | "completed" | "error",
): void {
  if (status === "running") {
    console.log(`\n[tool: ${name}] ${JSON.stringify(args)}`);
  } else if (status === "completed") {
    console.log(`[tool: ${name}] done`);
  }
}

// stream assistant text and tool events - act as streaming handler
async function runAgentChatStreaming(agent: SDKAgent, message: string): Promise<void> {
  const run = await agent.send(message);

  process.stdout.write("\nagent > ");
  for await (const event of run.stream()) {
    if (event.type === "assistant") {
      for (const block of event.message.content) {
        if (block.type === "text") process.stdout.write(block.text);
      }
    } else if (event.type === "tool_call") {
      logToolCall(event.name, event.args, event.status);
    }
  }

  const result = await run.wait();
  if (result.status === "error") {
    throw new Error(`Agent run failed (${result.id})`);
  }
  process.stdout.write("\n\n");
}

// runs the chat loop, adds a readline interface and disposes agents on exit
async function main(): Promise<void> {
  requireEnv("CURSOR_API_KEY");
  getComposioApiKey();

  console.log("Setting up Composio session...");
  const runtime = await getOrCreateRuntime(DEFAULT_USER_ID);
  console.log(
    `Ready (user: ${runtime.userId}, session: ${runtime.sessionId}, tools: ${runtime.toolsCount}).`,
  );
  console.log("Type a message, or 'exit' to quit.\n");

  const rl = readline.createInterface({ input, output });

  try {
    while (true) {
      const userInput = (await rl.question("you > ")).trim();
      if (!userInput) continue;
      if (userInput === "exit" || userInput === "quit") break;

      await runAgentChatStreaming(runtime.agent, userInput);
    }
  } finally {
    rl.close();
    await disposeAllAgents();
  }
}

main().catch((err) => {
  console.error(err);
  process.exit(1);
});

Let's look at the code:

We start by loading dependencies from .env, readline, and shared helpers from runtime.ts (getOrCreateRuntime, API key checks, and cleanup)
For a sanity check, we validate CURSOR_API_KEY and COMPOSIO_API_KEY before the chat loop starts (Composio is also checked when runtime.ts loads).
Next, we create a Composio session for the default user and spin up a Cursor agent on composer-2 with the Composio MCP server for tools (handled in runtime.ts).
We keep the same agent in the loop for every message, so tools and sessions stay wired throughout the CLI session.
We run a terminal chat loop with readline: read input → send to agent → stream assistant text and tool status → repeat until exit or quit.
While streaming, we log tool calls on running and completed, and throw if the agent run ends in error.
On exit, we close readline, dispose of agents via runtime.ts, and log any failure from main() before exiting with code 1.

If you encounter an issue, refer to the codebase in the project's GitHub repo. Feel free to clone it, tweak it to your liking, or use it as it is.

And that's it, all set, time to run the agent!

Run the agent

To run the agent in the terminal and at the project root, type:

npx ts-node index.ts

and an interactive chat opens up where you can prompt it step by step / direct it to do the entire task at once. Here is a demo of me using it in chat mode (step by step)

As you can see, the cursor agent acts as the brain, calling the Composio GitHub tools to clone the repo, check for changes, create a dev branch, refactor the code, commit to the dev branch, and finally open a PR.

Usually, this takes many human hours, but with a cursor-agent, it takes only 5 minutes.

Also, with the new update, you need to add a GitHub token to use GitHub with the cursor/agent. Using Composio fixes this need as well.

Note: For simplicity I have used terminal , but you can add a ui layer on top of the agent.

With this, we have reached the end of the article. Here is my closing note.

Final Thoughts

In this article, we learned how to use the Cursor SDK and Composio MCP to build a GitHub chatbot while keeping it optimized for asynchronous operations and following best practices, such as masking sensitive variables.

But this is just the tip of the iceberg with what's possible with the cursor agent SDK. Feel free to experiment and build your own assistant/chatbot. You can explore more in the cursor-cookbook.

At the end of the day, building agents / multi-agent systems is not hard; planning and orchestrating them to work efficiently, collaboratively, and securely is. In fact, it's the next valuable skill in 2026.

So what are you waiting for? Get started with Cursor Agents while Composio MCP handles the tooling layer.

Building Streamable HTTP MCP Servers from Scratch using FastMCP in 2026

Developer Harsh — Mon, 18 May 2026 14:50:04 +0000

If you've spent any time wiring up tools for an AI agent, you know the pain: every model vendor has its own function-calling format, every integration is bespoke glue code, and every model upgrade breaks something downstream.

MCP changes this by providing a shared interface for tools, data sources, and AI clients. Instead of rebuilding integrations for every model or app, you expose capabilities once through an MCP server and let compatible clients connect to them.

Anthropic released the Model Context Protocol in November 2024, and by spring 2025, OpenAI, Microsoft, and Google had adopted it. It has quickly become the de facto standard for connecting AI systems to external tools and data. That makes MCP worth learning now.

This guide teaches you how to build an MCP server from scratch, expose it over two transports: stdio and streamable HTTP, connect it to Claude Desktop and Cursor. and provide you with a production checklist for hardening the production MCP servers before shipping them. The full code is available in the companion repo at the end

tl; dr

What is MCP
MCP Components in Nutshell
Build a Local MCP server (tools, resources, and prompts)
Connect to Hosted MCP Server (HTTP Streamable)
MCP Server Advance Use Case
Deployment Notes for Production MCP Servers
Conclusion
Frequently Asked Questions

Let's Begin!

What is MCP

An MCP server is a JSON-RPC 2.0 process that exposes three primitives to any compliant MCP client over stdio or streamable HTTP. Those primitives are tools (functions the model can call), resources (data the model can read), and prompts (reusable templates). That's the whole protocol.

Everything else is an implementation detail as given in the comparison table.

Feature	Model Context Protocol (MCP)	Traditional API (REST / GraphQL / gRPC)
Primary purpose	Give LLM-based agents a single way to fetch context and invoke side-effecting tools.	General machine-to-machine data exchange & business logic.
Integration effort	Once an agent speaks MCP, it can talk to any compliant server; only one SDK/wire-spec to learn.	Each API exposes its own spec/SDK; you integrate them one by one.
Interaction model	Stateful sessions + bidirectional messaging; supports long-running tasks and mid-job progress callbacks.	Stateless request/response; usually unidirectional.
Streaming support	Standardised via “Streamable HTTP” (SSE/WebSocket).	Not part of the REST spec; developers bolt on WebSockets/SSE ad hoc.
Extensibility (adding new capabilities)	The server can add new tools/resources without breaking clients; the agent discovers them at runtime.	Breaking changes need versioning, or clients must update to use new endpoints/types.
Standardisation/wire format	One JSON-Schema-driven spec for inputs & outputs, plus defined transports.	Multiple styles (REST, GraphQL, gRPC) with differing auth headers, error shapes, and media types.
Maturity & tooling	Rapidly growing, but still early; dozens of open-source servers and early commercial support.	Decades of best-practice guides, gateways, SDKs, APM, and monitoring.
Performance path length	Extra hop (agent → MCP → underlying API) adds a bit of latency; streaming mitigates waiting for large payloads.	Direct call; generally lower overhead for high-QPS, deterministic workloads.
Typical sweet-spot use-cases	Autonomous agents chaining multiple tools, dynamic workflows, and user-in-the-loop	CRUD data services, stable integrations, high-throughput micro-services.

If you want a deeper conceptual primer, check out the Model Context Protocol explainer, which covers the architecture in detail. For primer, here is how this all works!

MCP Components in Nutshell

The Architecture

The MCP architecture consists of several key components that work together to enable seamless integration:

MCP Hosts: Applications that want to use tools or data through MCP. Examples include Claude Desktop, Cursor, or any AI app that supports MCP.
MCP Clients: Client instances created by the host. Each client maintains a dedicated one-to-one connection with a single MCP server.
MCP Servers: Lightweight programs that expose tools, resources, and prompts through the MCP protocol.
Local Data Sources: Files, databases, codebases, or local services that an MCP server can access on the user’s machine.
Remote Services: External APIs or cloud services that an MCP server can call, such as Google Sheets, GitHub, Slack, or Postgres hosted in the cloud.

At a high level, the host does not talk directly to your database, file system, or API. Instead, it talks to an MCP client, which talks to an MCP server, which then talks to the actual data source or service.

This simple diagram might help you understand the flow better:

The key point is that MCP servers serve as the integration layer. They hide the messy parts of authentication, API calls, file access, and business logic behind a clean protocol interface.

This separation of concerns makes MCP servers modular and maintainable. The AI app does not need to know how Google Sheets, GitHub, or a local database works. It only needs to know how to call the MCP server.

So how does this all connect?

How The Components Work Together

Let's understand this with a practical example:

Say you're using Claude Code (an MCP host) to manage your project's budget. You want to update a budget report in Google Sheets and send a summary of the changes to your team via Slack.

Claude Code (MCP host) initiates a request to the MCP client to update the budget report in Google Sheets and send a Slack notification.
The MCP client connects to two MCP servers: one for Google Sheets and one for Slack.
The Google Sheets MCP server calls the Google Sheets API (remote service) to update the budget report.
The Slack MCP server interacts with the Slack API (remote service) to send a notification.
MCP servers send responses back to the MCP client.
The MCP client forwards these responses to Cursor, which displays the result to the user.

This process happens seamlessly, allowing Cursor to integrate with multiple services through a standardized interface.

That's the working in a nutshell. From here on, we will focus on building.

Build Local Stremable HTTP MCP Servers

We'll build something you'd actually deploy: a GitHub issue search server that lets your AI assistant search issues, fetch issue details, and pull recent pull requests from any repository. [subject to change]

We will follow a series of steps to make sure things go smoothly. This is also industry standard, so it's best to follow along.

Prequires

Before anything else, ensure you complete the prerequisites, as they will be the foundation for any MCP implementation we do.

You'll need:

Python 3.10+
Node.js 18+ for TypeScript (if you choose to build with TypeScript)
Claude Desktop or Cursor for testing

A common question users often ask: when should you pick Python vs. TypeScript? Here is an honest review:

Python with FastMCP is faster for prototyping and works well for stdio servers.
TypeScript shines for HTTP servers deployed to Cloudflare Workers, Vercel Edge, or any Node-based stack due to its type safety.

In case you are wondering, Composio is the ultimate integration platform, empowering developers to seamlessly connect AI agents with external tools, servers, and APIs with just a single line of code.

With the fully managed MCP Servers, developers can rapidly build powerful AI applications without the hassle of managing complex integrations.

In a nutshell: Composio handles the infrastructure so developers can focus on innovation.

Next, let's set up the working environment.

Work Environment Setup

We start by creating a project directory.

Navigate to your working folder and create a folder named MCP, or u can use the terminal command:

mkdir mcp_servers
cd mcp_servers

Next, create a virtual environment using:

python3 -m venv .venv

Now activate the environment with:

# Windows:
.venv\Scripts\activate

# Linux/Mac:
source .venv/bin/activate

Ensure you see (.venv) in Front of the terminal cwd path.

Finally, install the FastMCP package

pip install FastMCP

Writing Server Code

Server code is where the entire MCP server logic lives. Create a new server.py file and inside it paste the code below:

# server.py

# imports
import base64
import os
import uuid

from typing import List
from fastmcp import FastMCP

mcp = FastMCP("Utility MCP Server")

# generate password utility
@mcp.tool()
def generate_password() -> str:

    """
    Generate a pseudo-random password for development use.

    This function creates a password by encoding a UUID4 string in base64
    and then reversing the resulting string. It's intended for use in
    development or testing environments where cryptographic security is not
    critical.

    Returns:
        str: A reversed base64-encoded UUID4 string, typically around 48 characters.
        May include alphanumeric characters, '+', '/', and '=' padding.

    Security Notes:
        - Uses the string form of UUID4 (not raw bytes), so effective entropy is lower (~190 bits of input chars)
        - Suitable for temporary or development credentials.
        - NOT recommended for production use.
        - For higher security, consider using secrets.token_urlsafe().

    Example:
        >>> generate_password()
        '==dGM0ZTcwLTI0ZTUtNDJlZC05Y2I1LTk3OGJjODAxMDAwNw=='
    """

    uuid_string = str(uuid.uuid4()).encode()
    base64_encoded = base64.b64encode(uuid_string).decode()
    return base64_encoded [::-1]

# list all the files in the directory
@mcp.tool()
def list_files(directory: str = ".") -> List[str]:
    """
    List all files and directories in a specified path.

    This tool allows the AI to explore the file system by returning a list 
    of names of the entries in the directory given by path.

    Args:
        directory (str): The path to the directory to list. Defaults to the 
        current working directory (".").

    Returns:
        List[str]: A list of filenames and directory names. If an error 
        occurs (e.g., directory not found), returns a list containing 
        the error message.
    """
    try:
        return os.listdir(directory)
    except Exception as e:
        return [f"Error: {str(e)}"]


# read the given file
@mcp.tool()
def read_file(filename: str) -> str:
    """
    Read and return the full text content of a file.

    This tool enables the AI to analyze the contents of specific text files 
    within the accessible file system.

    Args:
        filename (str): The path to the file that needs to be read.

    Returns:
        str: The complete string content of the file encoded in UTF-8. 
        If the file cannot be read, returns an error message starting 
        with "Error reading file:".
    """
    try:
        with open(filename, 'r', encoding='utf-8') as file:
            return file.read()
    except Exception as e:
        return f"Error reading file: {str(e)}"

# system info (resource)
@mcp.resource("data://sys-info")
def get_system_info() -> str:
    """
    Get a comprehensive system snapshot including time, hardware specs, 
    and real-time health metrics.
    """
    import platform
    import psutil
    import subprocess
    from datetime import datetime

    now = datetime.now()
    timestamp = now.strftime("%Y-%m-%d %H:%M:%S")
    day_name = now.strftime("%A")


    boot_time = datetime.fromtimestamp(psutil.boot_time())
    uptime = str(now - boot_time).split('.')[0]

    sys_type = platform.system()
    machine = platform.machine()
    cpu_count = psutil.cpu_count(logical=False)
    try:
        gpu_info = subprocess.check_output(
            ["nvidia-smi", "--query-gpu=gpu_name", "--format=csv,noheader"], 
            encoding="utf-8"
        ).strip()
    except Exception:
        gpu_info = "N/A (NVIDIA-SMI not found)"

    cpu_usage = psutil.cpu_percent(interval=None)
    memory = psutil.virtual_memory()
    disk = psutil.disk_usage('C:\\')

    return f"""
             --- Hardware Specs ---
            OS:        {sys_type} ({machine})
            CPU:       {cpu_count} Physical Cores
            GPU:       {gpu_info}

            --- Temporal Context ---
            Date/Time: {timestamp}
            Day:       {day_name}
            Uptime:    {uptime}

            --- Resource Utilization ---
            CPU Load:  {cpu_usage}%
            RAM Usage: {memory.percent}% ({memory.used // (1024**2)}MB / {memory.total // (1024**2)}MB)
            Disk (C:): {disk.percent}% Used ({disk.free // (1024**3)}GB Free)
            """

# general prompt
@mcp.prompt()
def helper_prompt(task: str, context: str = "") -> str:
    """General purpose prompt for any task with optional context."""
    base_prompt = f"""
Task: {task}

Please approach this systematically:
1. Break down the problem
2. Consider multiple solutions
3. Explain your reasoning
4. Provide clear, actionable steps
"""

    if context:
        base_prompt += f"\n\nAdditional context: {context}"

    return base_prompt

# api-design rules prompt
@mcp.prompt()
def api_endpoint_design_prompt(endpoint_name: str, purpose: str) -> str:
    """Specific prompt for designing RESTful API endpoints."""
    return f"""
Design a RESTful API endpoint: {endpoint_name}
Purpose: {purpose}

Please provide:
1. HTTP method and URL pattern
2. Request/response schemas with examples
3. Status codes and error handling
4. Authentication requirements
5. Rate limiting considerations
6. OpenAPI/Swagger documentation snippet

Follow REST conventions and include proper validation.
Use JSON for data exchange and meaningful HTTP status codes.
"""

# Run MCP server
# if __name__ == "__main__":
    # mcp.run()

# Run stremable http MCP Server (can be deployed / hosted)
if __name__ == "__main__":
   mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

Key points from the code:

mcp : It's the Fast MCP object named as provided. Important to initialize at the start.
@mcp.tool() : Decorator wraps the entire function underneath and exposes it as a tool to the MCP client. Docstrings are very important; a good docstring leads to fewer model failures. Includes generate_password , list_files, read_filetools.
@mcp.resource("data://sys-info") : Decorator wraps the entire function and exposes it as a resource file that the client can use to fetch data. The path to the created resource is defined in () . Includes get_system_info resource
@mcp.prompt() : Decorator wraps the entire function and exposes it to the client as a prompt builder, useful when the task requires a specific use-case prompt. Docstrings are important here. Includes helper_prompt , api_endpoint_design_prompt
mcp.run(transport="streamable-http", host="0.0.0.0", port=8000) : Runs the MCP server.in a streamable HTTP mode. For stdio MCP server, use mcp.run()

Overall, we are wrapping different functions and exposing them to the client as the MCP tool, resources, and server.

However, to use it with the client, additional config is required, so let's set that up. I am using a cursor for the demo.

Head to the Cursor and create a new folder .cursor , inside it creates a new file mcp.json (the config file) and paste the following setup.


{
    "mcpServers": {
        "utility-server": {
            "url": "http://localhost:8000/mcp"
        }
    }
}

In case you have used mcp.run() then you will see the below configuration

{
    "mcpServers": {
        "utility_server": {
            "type": "stdio",
            "command": "your-python-exe-path",
            "args": ["your file path"]
        }
    }
}

In general I use local stdio based servers and then when all test and specifications are met, I switch to Streamble HTTP approach.

Quick Tip: To verify this works is by pasting the command and args together; if they start the server, you are good to go; else, provide the full path. I usually go for path of .venv’s python.exe

Open Cursor Settings, then click Tools & MCPs. You will see your local MCP name. Click Enable,

To check, open the terminal, switch to the Output tab, select the MCP server, and check for the connected message.

Now we can test our MCP Server by opening the chat/agents window and invoking any of the defined tools via the prompt. I invoked the password-generator, as I often find myself asking Claude to "think of a 16-character password" (which is terrible).

Generate password + show mcp tool usage

Here is the output:

Saw that Ran command, it means the MCP server asked me for permission. I kept it that way, as you never want to let an agent touch your system files.

Note: If docstring is poor, the mcp client might fall back to cli approach, the easiest way to fix this is add a rule to only use mcp servers for the task. You will find a similar approach in the project github repo as well.

All this is great, but setting it up for testing a local MCP server is a hassle. Let's look at an easier approach, MCP Inspector.

Test with MCP Inspector

To test the MCP server's functionality, we will use the Fast MCP Inspector, a browser-based tool that connects to the server and lets us call tools directly, without an LLM layer.

Run MCP Inspector, with:

npx @modelcontextprotocol/inspector python server.py

You'll see a localhost URL. Open it in your browser, click Connect, and you should see your server respond.

Now you can run and test your tools, resources, prompts, and more right from the browser, quite handy for developers testing MCP servers' performance and understanding response schemas. Check out the MCP Inspector Guide to learn more.

Personally, I find it best for testing prompts’ responses. Here is the response it generated:

Local servers are great for simple use cases, but for most industry use cases, they don't provide the required infrastructure. Let's explore better use cases.

Connect to Hosted Streamable HTTP MCP Server

Having a local server is good, but not as great as the one used in production. Usually, these are hosted, secured by design, and optimized for multiple tool calls.

Usually, these are servers written by expert developers, integrated with the app's internal mechanisms, and intended to serve as connectors.

But here lies the issue: connecting to 30+ MCP servers for a single project is a pain. Composio solves this.

Let's look at how you can connect to the hosted Composio MCP server. You connect it once and use 1K+ tools directly, all secure, optimized tool calls.

Connect to Composio MCP Servers (Streamable HTTP )

Integrating with Composio MCP is incredibly simple and takes just 5 steps.

Visit the Composio MCP page. Ensure you are logged in, or else sign up

In the dashboard, head to the Install Section

Select Cursor from the list, and click on Install.

In the redirected page, click on "Install in Cursor".

You will be redirected to Cursor, and in the MCP server Page, click Install

Once installed, click on Needs Authentication, then Authorize at redirect, and done!

You can connect to apps in advance in the Connect Apps section; most of them use OAuth. (optional). If you don't, the agent will prompt you to connect at runtime.

To test the integration, open the Composer, establish a connection to the app, and ask it to perform actions.

But how did all this happen?

It turns out that if you go to your cursor MCP & Tools Page, select the ✏️ icon, and see the configuration as:

{
  "mcpServers": {
    "composio": {
        "type":"http",
      "url": "https://connect.composio.dev/mcp",
      "headers": {}
    }
  }
}

The http here means a streamable HTTP server. This allows the MCP server to operate as a normal web server (accessible via a URL) rather than as a local subprocess on your machine (for local MCP servers)

And interestingly, for any MCP to run in HTTP streamable mode, you have to replace:

if __name__ == "__main__":
    mcp.run()

if __name__ == "__main__":
    mcp.run(transport="streamable-http", host="0.0.0.0", port=8000)

And you are done, pretty handy, isn’t it?

Now, let's look at an advanced use case to see where Composio MCP helps.

Using HTTP Streamable MCP Servers for Advanced Use Case (Financial Agent)

Current financial institutions struggle with manual, time-intensive investment research that keeps analysts buried in data entry for weeks, delays critical decisions by days, lacks real-time risk visibility, creates compliance blind spots, and demands hiring more analysts just to manage portfolio volume - all while losing talent and clients

Let's see how the analyst can build financial agents and leverage Composio MCP to connect to 10-15 financial data sources (Yahoo Finance, SEC filings, Google Sheets, Bloomberg, etc.) and enrich their analysis by aggregating structured APIs, unstructured web scraping, and internal data warehouses.

The financial analyst agent will:

Aggregate financial data (Yahoo Finance, Google Sheets with company data, SEC filings via web scraping),
Run Claude analysis to generate investment thesis.
Create formatted reports in Google Docs,
Track portfolio changes (pull from Excel sheet),
and send Executive Summaries to stakeholders via email with embedded tables. (HTML format)

All done in parallel!

Web Scraping (composio & search api) + Google Sheets (composio) → Claude Analysis → Google Docs (composio) → Gmail (composio)

Prerequisites

Claude Code / Cursor / VS Code. I am going with Claude
Composio Account, login/signup

Assuming you have pre-requisites met, let's set up Composio on Claude.

Set up Composio MCP in Claude

To get started:

Visit the Composio MCP page. Ensure you are logged in, or else sign up
In the dashboard, head to the Install Section
Select Claude from the list, and click on Install.

On the next page, select the MCP tab, then copy the command & paste it into the shell/terminal.

claude mcp add --scope user --transport http composio https://connect.composio.dev/mcp

Ensure /mcp shows composio as an option. It might require authentication, so authenticate once

(Optional ) Once done, head to the Connect Apps page and click on Connect to connect Gmail, Google Drive, Google Sheets, and Google Docs. In case you ignore, agent will ask for these connections on runtime.

Perfect, we only need to configure the document in the workspace

Set up Workspace for Agent

We will use Google Drive as our workspace to make the file accessible from everywhere:

Head to drive, create a new folder named financial_data & from the URL, copy the folder ID.
Inside, add an Excel file in the format & fill the data as:
- Companies: List of all targeted companies with their analysis
- Portfolio Performance: How the portfolio is performing over time, all metrics for targeted companies
- Contact: List of all internal contacts: Portfolio Managers, Limited Partners, Investors, Board Managers, and more
- Report Archive: Past report filing (sec)
Then add a Google Doc template for an investment report.

Make sure to copy the ID / URL of both files

Easiest way is to use the template given in the GitHub Repo and let any AI Agent turn them in the above given format. Then copy paste that in newly created google sheet & google doc file.

Now is the time to run the agent.

Run Financial Analyst Agent

To run the agent, open Claude Code and paste the financial_agent_prompt. You will be prompted to fill in the details with the copied values from earlier, and add your email address:

GOOGLE_SHEETS_ID: [your value]
GOOGLE_DOC_TEMPLATE_ID: [your value]
GOOGLE_DRIVE_FOLDER_ID: [optional]
GMAIL_SENDER_ADDRESS: [your gmail]

Once done, the agent handles the rest. Here is a demo of what it looks like, in production.

The agent also works on multiple portfolio reports. I am testing it with six different portfolios; you can adjust the count as needed.

Same setup, but with multiple portfolio data. Make sure to copy each one's ID, and use the financial_agent_prompt_for_multiple portfolio for the job.

Note that, despite explicitly stating that Claude never created a subagent, this is because composio already has parallel execution enabled and, behind the scenes, uses subagents.

Hope this gave you an idea of how hosted MCP servers work, and tools like Composio MCP provide a universal tooling layer.

However, deploying a hosted MCP server for production is a different game. Let's look at a few rules to help ensure the servers don't break in real-world use.

Deployment Notes for Production MCP Servers

Though we didn't cover a hosted MCP server build, if you want to build your hosted MCP server (local + later deployed), follow the production checklist before you deploy & put an MCP server in front of real users:

Logging to stderr or files only, never stdout for stdio servers
Errors caught on every tool: return a clean error message, don't let exceptions kill the connection
Inputs validated: type hints (Python) or Zod (TypeScript) catch most issues; add explicit checks for things like SQL injection or path traversal if you're doing database/file operations
External API calls are rate-limited / Use Composio MCP: your tool runs whenever the LLM decides to call it, which can be a lot. Let Composio MCP handle it.
Secrets in environment variables, never hardcode in servers, never commit in production.
Tool descriptions for the LLM: Write specific, one-purpose per tool. Five small tools beat one giant tool. The approach we followed.
Schema versioning: when you change a tool's signature, bump your server's version so clients can adapt. Think API versioning.
Health check endpoint: for HTTP servers, expose /health for your load balancer. Provides transparency to users.
Auth on production HTTP servers: Use Bearer for internal, OAuth for public. But never both for the same for public/internal (private)

With this, we have come to the end of this comprehensive guide. Here is what matters the most.

Conclusion

As AI transforms software development, MCP will play an increasingly important role in creating seamless, integrated experiences.

Whether you're building custom MCP servers or leveraging pre-built solutions like stremable http servers like Composio MCP, the protocol enables powerful enhancements to AI capabilities through external tools and data sources.

In case you need a few ideas, check out how to build an MCP client that talks to your server, or move up the stack and build an MCP-powered agent that orchestrates multiple servers at once. Happy building.

I hope you had a great learning experience - happy building with Composio! 🚀

What Is an MCP Gateway — and Why Do Enterprise AI Teams Need One in 2026?

Dumebi Okolo — Thu, 07 May 2026 14:29:51 +0000

The Model Context Protocol (MCP) was released by Anthropic in November 2024. Eighteen months later, it had 97 million monthly SDK downloads as of December 2025, backing from every major AI lab, and is now governed as a founding project of the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation.

That adoption happened fast, even faster than most protocols manage. But it created an immediate problem: connecting AI agents directly to dozens of MCP servers at scale is operationally unsustainable, and the protocol itself does not solve governance.

This article explains what an MCP Gateway is, what it does at the infrastructure level, and how to evaluate one for a production enterprise environment.

What Is MCP, and What Problem Does It Solve?

Before understanding the gateway, you need to understand what MCP standardizes.

Enterprise AI teams historically faced what is called the N×M integration problem: connecting N agents to M tools requires N×M custom integrations, each with its own authentication flow, error-handling logic, and credential store. Without MCP, integration complexity rises quadratically as AI agents spread through an organization; with MCP, it scales linearly.

MCP defines a standardized way for AI models to discover and invoke external tools using JSON-RPC 2.0 over HTTP. An agent sends a tools/list request to understand what a server exposes, then uses call_tool to invoke those tools. That handshake is consistent regardless of whether the backend is GitHub, Salesforce, Postgres, or an internal API.

What MCP does not define is who can call what, under whose identity, with what constraints, and at what cost. Those are governance problems, and they fall outside the protocol specification by design.

What Is an MCP Gateway?

An MCP Gateway is a centralized infrastructure layer that sits between AI agents and one or more MCP servers. It acts as a specialized reverse proxy purpose-built for MCP traffic: handling authentication, routing, policy enforcement, credential management, and observability in one place.

From the agent's perspective, nothing changes. It still performs a tools/list handshake and issues call_tool requests. The difference is that those requests are now intercepted, evaluated against policies, and routed by the gateway before any backend system executes them.

Architecturally, the shift looks like this:

Without a gateway:

Agent A → GitHub MCP Server
Agent A → Slack MCP Server
Agent B → GitHub MCP Server
Agent B → Postgres MCP Server
Agent C → Salesforce MCP Server
... (N×M connections, each managing its own auth and credentials)

With a gateway:

Agent A ──┐
Agent B ──┤──→ [MCP Gateway] ──→ GitHub MCP Server
Agent C ──┘                  ──→ Slack MCP Server
                             ──→ Postgres MCP Server
                             ──→ Salesforce MCP Server

The gateway becomes the single chokepoint where security policy, access control, and observability can be enforced consistently. As one Hacker News discussion on MCP gateways noted, practitioners want features like central MCP registries, OAuth integration, and curated toolset scoping; all things that make MCP viable at organizational scale, not just in a prototype.

Why Does MCP Alone Fall Short in Enterprise Environments?

Credential Sprawl

Without a gateway, each agent carries its own API keys, OAuth tokens, and service account credentials for every tool it accesses. Those credentials end up in environment variables, config files, and secret stores scattered across services. This is not a theoretical risk: GitGuardian's research found 24,008 unique secrets exposed in MCP configuration files in 2025 alone, with Google API keys and PostgreSQL connection strings among the most common leaked types. Rotating credentials becomes a manual exercise across multiple codebases. Revoking access for a compromised agent requires hunting down every integration it touches. There is no single point of revocation.

No Centralized Access Control

MCP does not define native role-based access control. If an agent can connect to a server, it can discover every tool that server exposes. A finance agent can see development tools. A support agent can see database administration endpoints. Principle of least privilege has to be implemented outside the protocol, in every agent individually, or not at all. As engineers in the MCP-Scanner Hacker News thread observed, people are over-provisioning MCPs the way they install apps on a phone, without applying least-privilege access.

Least-privilege access is the principle that an agent should only be able to see and invoke the specific tools it needs for its defined task, and nothing beyond that. In an MCP context, this means a support agent should have no visibility into deployment tools, and a read-only analytics agent should have no access to write operations, regardless of what the underlying server exposes..

Observability Black Holes

When agents connect directly to tools, there is no aggregated view of what any agent is actually doing. Debugging a multi-step workflow requires stitching together logs from N different servers. There is no unified execution timeline, no trace correlation, no cost attribution. Anomalies go undetected because there is no baseline.

No Cost Governance

MCP does not track token consumption or enforce usage limits. An agent can invoke tools repeatedly, triggering LLM calls and paid API operations, with no budget ceiling. At enterprise scale, this becomes a financial control problem, not just a technical one.

Security Attack Surface

In April 2025, security researchers published an analysis identifying multiple outstanding MCP security issues, including prompt injection, tool permissions that allow combining tools to exfiltrate data, and lookalike tools that can silently replace trusted ones. A centralized gateway is the practical enforcement point for mitigating all three.

What Does an MCP Gateway Actually Do?

Centralized Authentication and Identity Propagation

A production gateway validates incoming identity (typically via JWT, OAuth 2.0 with PKCE, or OIDC) and propagates that identity downstream to MCP servers. Instead of agents running under shared service accounts, requests execute on behalf of specific authenticated users.

This closes a real vulnerability. If a user cannot delete a repository, neither can the agent acting for them. Authorization is enforced at the protocol layer, not assumed in prompts. The MCP specification introduced OAuth 2.1 support in the March 2025 revision, with significant refinements in June 2025, but implementation quality varies between gateways. Some handle enterprise SSO automatically; others require manual configuration per server.

Tool-Level RBAC

The gateway intercepts tools/list responses and filters them based on the requesting agent's role and permissions. Sensitive tools simply do not appear in the agent's context. A configuration like:

virtual_server:
  name: support-scope
  allow_tools:
    - github.list_issues
    - github.get_comments
    - crm.update_ticket

...means the agent calling this endpoint never sees database administration tools, deployment controls, or any capability it has no business using. This directly improves model performance, agents reason more accurately when the action space is deliberately constrained, and reduces blast radius when something goes wrong.

Intelligent Routing

The gateway examines each request and routes it to the appropriate upstream MCP server based on the tool being called. Session affinity keeps stateful, multi-step agent conversations on the same backend server. Load balancing distributes traffic. Circuit breakers prevent cascading failures when an upstream tool degrades.

Unified Observability

Every tools/list and call_tool invocation is logged with metadata: agent identity, user context, tool arguments, response status, and latency. This creates a coherent audit trail across all connected systems. Metrics export in Prometheus format. Traces follow the OpenTelemetry standard for distributed tracing, which matters when debugging multi-step agent tasks that touch six different tools.

Cost Management

The gateway can implement caching for repeated tool calls, enforce per-agent or per-user rate limits, and surface usage analytics. Caching strategies for repeated tool calls can meaningfully reduce LLM costs, and the gateway is the practical place to implement this at scale.

Credential Vaulting

API keys, OAuth tokens, and service credentials are stored centrally in the gateway. Agents never handle raw credentials directly. Rotation policies apply once at the gateway level rather than across every agent codebase.

How Does an MCP Gateway Differ from an API Gateway?

A traditional API gateway is designed for stateless, client-server request-response cycles, standard in web and mobile applications. It handles HTTP routing, authentication, rate limiting, and transformation for REST or GraphQL traffic.

An MCP gateway is designed for stateful, session-aware, and often bidirectional communication patterns specific to AI agents. It understands the context of a long-running agent task. It can propagate user identity across multiple sequential tool calls. It maintains session state so that a multi-step agent workflow does not lose context mid-execution. It understands the tools/list → call_tool protocol cycle and can enforce policies at that semantic level, not just at the HTTP layer.

In modern enterprise architectures, both typically coexist. APIs serve application services. API gateways govern traditional HTTP traffic. MCP servers expose selected capabilities to agents. An MCP gateway governs agent-to-tool communication. The relationship is complementary.

How Does an MCP Gateway Differ from an AI Gateway?

This is worth separating out because it's a more common source of confusion in practice. Buyers evaluating AI gateways frequently find themselves looking at MCP gateways instead.

An AI gateway sits in front of LLM inference. It manages which model gets called, routes traffic between providers (OpenAI, Anthropic, Mistral), enforces token budgets, handles prompt/response logging, and abstracts model provider APIs behind a single interface. Its job is governing model calls.

An MCP gateway sits between agents and the tools those agents invoke. It governs tool calls: what an agent can do after the model has already decided to act. The two layers are complementary: an AI gateway controls which brain your agent uses; an MCP gateway controls which hands it has.

In a mature enterprise architecture, both are present. The AI gateway handles model-level traffic. The MCP gateway handles the downstream tool execution that the model's output triggers.

What Are the Categories of MCP Gateway Available?

Understanding the gateway landscape requires understanding the primary design philosophies, not just the feature checklist.

Managed Integration Platforms

These prioritize developer velocity by abstracting integration complexity behind a large library of pre-built, maintained connectors. Authentication lifecycle management (including complex OAuth 2.1 flows) is handled for you.

Composio's MCP Gateway is the primary example. It offers 1000+ tools and actions across major enterprise SaaS applications, a unified authentication layer, SOC2 and ISO certification, action-level RBAC, and zero data-retention architecture. The architecture is designed for teams that need to connect agents to many different tools quickly without owning the integration layer: instead of juggling 22 different MCP servers for 22 different tools, you install one gateway and access a broad library of pre-built integrations with a single authentication flow and audit surface.

For most enterprise teams moving from pilot to production, this is the most practical starting point. Refer to the Composio guide to MCP gateways for a deeper walkthrough of the architecture.

Security-First Proxies

These treat security as the primary constraint and performance as secondary. Lasso Security inspects all MCP traffic in real time to detect prompt injection, mask PII, and calculate reputation scores for MCP servers before they are loaded. The tradeoff is latency — deep security scanning adds 100–250ms overhead — which makes this category unsuitable for latency-sensitive workflows but appropriate for regulated environments where compliance is non-negotiable.

Infrastructure-Native Open Source

These integrate into existing container-native DevOps workflows. Docker MCP Gateway runs MCP servers as isolated Docker containers with familiar docker mcp CLI tooling and container-based security. Obot is Kubernetes-native and designed for organizations that require full data sovereignty.

Both require your team to own the integration layer. Your team brings the MCP servers, and the gateway governs them. The operational overhead is higher than a managed platform, but so is the control.

What Should Enterprise Teams Evaluate When Choosing a Gateway?

Deployment Model

Cloud-hosted managed gateways reduce time-to-production but involve data transiting external infrastructure. Self-hosted or VPC-deployed gateways give you data sovereignty. For teams in healthcare, finance, or government where regulated data must stay in your cloud, deployment model is often the first filter, not an afterthought.

Authentication Standards

Verify support for OAuth 2.1 with PKCE, OIDC, and SAML. Check whether the gateway integrates with your existing identity provider (Okta, Microsoft Entra ID, Auth0) and whether it supports on-behalf-of token propagation: the pattern where agents act under the authenticated user's identity rather than a shared service account.

RBAC Granularity

Gateway-level RBAC (which tools each role can see) is the baseline. Tool-level RBAC, allowing read but not write within a single server, is more sophisticated and significantly reduces blast radius. Verify what the enforcement model looks like in practice, not just in the marketing copy.

Observability Depth

Prometheus-compatible metrics and OpenTelemetry traces are the minimum. Look for whether the gateway can attribute tool calls to specific users and agents (not just service accounts), whether audit logs meet your compliance format requirements, and whether the dashboard supports anomaly detection or cost attribution, and whether the gateway offers a zero data retention architecture — meaning tool call payloads and credentials are never stored on the gateway provider's infrastructure, which matters for regulated industries and data sovereignty requirements.

Integration Breadth vs. Governance Depth

Managed platforms offer wide integration libraries but less control over the underlying infrastructure. Governance-first platforms offer deep control but require you to bring your own servers. For teams that need both, a large library of managed integrations and enterprise-grade governance, Composio's MCP Gateway is the only option currently combining 500+ tools and actions with SOC2 compliance, RBAC, and zero data retention in a single product.

See the full comparison in Composio's breakdown of the best MCP gateways for developers.

Performance Overhead

Every proxy adds latency. Managed platforms typically run under 10ms overhead. TrueFoundry publishes under 5ms p95. Lunar.dev MCPX publishes approximately 4ms p99. Docker MCP Gateway adds overhead due to container management; warm-path performance is significantly better than cold-start, which can add 50–200ms. Lasso Security adds 100–250ms. For conversational agents where response time is visible to users, this matters. For background automation workflows, it typically does not.

Building Your Own MCP Gateway

Building a custom gateway is possible but requires solving non-trivial distributed systems problems: credential rotation, distributed rate limiting, OAuth 2.1 state management, PII redaction, and circuit breakers. The ongoing maintenance burden as the MCP spec grows as tool APIs change and security requirements mature is the real cost, not the initial build. For most teams, a managed gateway has a significantly lower total cost of ownership than a DIY solution, even when accounting for licensing costs.

A Note on the MCP Security Threat Landscape

Security threats against MCP deployments are not theoretical. A representative risk: an agent running with privileged service-role access that processes user-supplied input could inadvertently execute those instructions, exfiltrating sensitive data through legitimate output channels. Principle of least privilege at the gateway level is the primary defense.

The OWASP guidance on LLM security identifies prompt injection as among the highest-risk attack vectors for AI systems. An MCP gateway is the practical enforcement layer for mitigating it through input validation against JSON-RPC schemas, allowlisted actions, PII redaction, and real-time tool reputation scoring.

Without a gateway, the security posture of your MCP deployment is only as strong as the weakest link among N independently managed agents.

How much latency does a gateway add?

Managed platforms: typically under 10ms overhead. High-performance purpose-built gateways (TrueFoundry, Lunar.dev MCPX): under 5ms p99. Security-scanning gateways (Lasso Security): 100–250ms depending on inspection depth. Docker MCP Gateway warm-path latency is low; cold-start overhead can add 50–200ms.

What Comes Next for MCP Gateways

Based on MCP's published direction and community discussions from early 2026, four priority areas have emerged: transport evolution (stateless Streamable HTTP for load balancer compatibility), agent communication primitives (retry semantics and expiry policies for the Tasks primitive), governance maturation (formal contributor processes), and enterprise readiness (audit trails, SSO-integrated auth, and gateway patterns).

Gateway patterns are now explicitly on the protocol roadmap. The gateway layer is no longer an addon but is becoming formalized infrastructure for enterprise MCP deployments.

Start with your primary constraint. If it is integration velocity, a managed platform is the right answer. If it is compliance in a regulated industry, prioritize SOC 2 certification, audit log format, and IdP integration. If it is data sovereignty, evaluate VPC-deployable options. If it is raw performance for a latency-sensitive conversational product, benchmark the p95 numbers against your SLA.

The Composio MCP Gateway covers the first and most common case: an enterprise team that needs to move from prototype to production with a broad integration library, unified auth, and compliance controls without owning the infrastructure. For teams with narrower requirements or existing MCP server infrastructure, the list of specialized options covered above gives you the tradeoffs needed to make that call.

For a deeper look at gateway architecture patterns, see Composio's developer guide to MCP gateways. For a full comparison of gateway options by use case, see the best MCP gateways for developers in 2026.

Frequently Asked Questions

What is an MCP Gateway, in one sentence?

A centralized infrastructure layer between AI agents and MCP servers that enforces authentication, routes requests, applies access controls, and provides observability across all agent-tool interactions.

Is an MCP Gateway required for production deployments?

Not required by the protocol specification. Required in practice for any deployment with more than two or three MCP servers, multiple teams, regulated data, or compliance obligations.

What is the difference between an MCP server and an MCP gateway?

An MCP server executes tools. It connects to GitHub, Postgres, Slack, or an internal API and performs operations. An MCP gateway governs access to those servers. It handles identity, visibility filtering, policy enforcement, and routing before any tool executes.

How do MCP gateways handle prompt injection?

Security-first gateways like Lasso Security scan all traffic in real time and block payloads that trigger injection detection. Governance platforms like MintMCP apply input schema validation and allowlisted actions. Managed platforms like Composio run tool implementations in sandboxed environments. Using multiple layers of defense is the current best practice.

What authentication standards should my gateway support?

OAuth 2.1 with PKCE, OIDC, SAML, and support for enterprise IdPs. The MCP specification introduced OAuth 2.1 in the March 2025 revision with refinements in June 2025, but implementation quality varies significantly. Test the on-behalf-of identity propagation flow specifically. This is where implementations most commonly diverge.