DEV Community: Composio

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.

10 Gumloop Alternatives for AI Workflow Automation in 2026

Aakash R — Thu, 07 May 2026 08:13:49 +0000

Gumloop is a solid starting point for building AI-assisted automations. It has around 100+ platform integrations and MCP servers available. For teams that want a hosted environment where non-technical employees own their automations, Gumloop is one of the more complete options available.

However, as workflows get more complex, span multiple integrations, or sit alongside agentic products you already run, it may not be the most suitable fit.

But as workflows expand, the weak spots show up fast: integrations get brittle, edge cases pile up, and it becomes harder to keep outputs consistent.

This guide covers 10 of the best Gumloop alternatives in 2026. You will see what each tool is best at, where it fits in a modern automation stack, and how to pick the right option based on the exact constraint you are trying to solve.

TL;DR

Here’s the quick way to think about it:

Composio Connect: Best when the workflow breaks at the integration layer and an AI agent needs reliable actions across many apps.
Zapier: Best for well-defined, repeatable workflows that must run the same way every time.
Make: Best when you need branching, conditions, and detailed control over the flow.
n8n or Pipedream: Best when you need custom logic, direct API calls, or code-level control.
Activepieces: Best when self-hosting and data control start to matter.
Relay.app: Best for team workflows that need to stay readable and easy to maintain.
Lindy AI: Best when you want a goal-driven agent to execute tasks across tools.
Vellum: Best when you need to test, version, and monitor AI behavior in production.
Workato: Best for enterprise workflows that require governance and scale across teams.

Comparison matrix

Tool	Best for	AI-first	Integration depth	Custom code / API control	Self-hosting	Governance / enterprise readiness
Composio Connect	Agent-to-app actions across many tools	High	Very high	Medium	No	High
Zapier	Reliable, well-defined app workflows	Low	High	Low	No	Medium
Make	Branching logic and complex flow control	Low	Medium	Low	No	Low
n8n	Backend-like workflows with custom steps	Low	Medium	High	Yes	Medium
Activepieces	Simple automations with hosting control	Low	Medium	Medium	Yes	Low
Relay.app	Readable team workflows with optional AI steps	Medium	Medium	Low	No	Low
Lindy AI	Goal-driven agents executing across tools	High	Medium	Low	No	Low
Vellum	Testing, versioning, and monitoring AI in production	High	Low	Medium	No	Medium
Pipedream	Event-driven workflows with code and APIs	Low	Medium	Very high	No	Medium
Workato	Enterprise automations across teams and systems	Low	High	Medium	No	Very high

Why Look for Gumloop Alternatives

Gumloop works well in a contained setup. You can add AI steps, connect a few tools, and get useful output quickly. It fits early use cases that stay within clear boundaries.

Growth changes the shape of the workflow. More tools come into the picture, and integrations that felt simple at first become harder to maintain. Production use raises the bar further. AI responses need to stay consistent across inputs that vary each time.

Also, on the other hand, agent harnesses like Claude Code, OpenClaw, Hermes, and Codex are getting insanely powerful. They can work reliably without you needing to wire everything. Give them access to your applications and a bash tool, they will write codes to wire API end-points to execute any complex automation tasks.

And this is almost no-code. You don’t have to intervene.

If you’re looking for some Gumloop alternatives, I have mapped all that are available in the market.

Top Gumloop Alternatives in 2026

Different tools address different breaking points. Tools in this list focus on integration depth, reliability, and AI execution across workflows.

1. Composio Connect

Composio sits between your AI and the tools your workflow depends on. It handles how the agent connects to, authenticates with, and takes actions across systems.

It provides access to 1000+ applications, so one setup can extend across Slack, Gmail, GitHub, CRMs, and other systems you already use. The vast catalog almost never let’s you long for any apps.

You can wire Claude and Codex with Composio Connect via a single MCP server and voila!

You have now access to hosted and managed integrations. The best thing about Connect MCP is

On-demand access to 1000+ application via the MCP eouter. It handles authentication and loads only relevant tools. So, your LLMs context window remains clean.
Upto 50 parallel tool calls allowing the agents to handle complex automation tasks more efficiently.
A remote bash tool which allows agents to write their own code to handle data cleaning and app interactions.
Enterprise grade security

Why does it stand out against Gumloop

Composio Connect is simple and harness agnostic. It’s a single MCP URL that you can plug into Claude, ChatGPT, Codex or your custom agents and it will work the same.
Composio has over 1000 app integrations available via MCP, API, and CLI while Gumloop has 100+ MCP servers.
With Composio you can bring your own OAuth credentials and API configurations, and configure exactly which scopes and actions an agent is allowed to use per connected account. This matters for teams that need fine-grained control over what an agent can do inside a customer's Gmail or Salesforce, rather than inheriting whatever the platform's connector exposes.
With Composio you can bring your own OAuth credentials and API configurations, and configure exactly which scopes and actions an agent is allowed to use per connected account. This matters for teams that need fine-grained control over what an agent can do inside a customer's Gmail or Salesforce, rather than inheriting whatever the platform's connector exposes.

2. Zapier

Zapier is an automation platform that connects apps and runs workflows based on triggers and actions. It focuses on reliability and coverage, with support for thousands of integrations. It sits at the app layer. You define a trigger, map the steps, and Zapier handles the execution across tools.

What changes when you use it

Fast setup across apps: Connect tools and build workflows without custom logic
Large integration ecosystem: Covers most common business tools out of the box
Stable execution model: Workflows follow defined triggers and actions
Clear structure: Each step is visible and easy to trace

Why does it stand out against Gumloop

Gumloop brings AI into workflows, adding flexibility but also introducing variation in outputs and behavior.

Zapier takes the opposite approach. It focuses on predictable execution. Each step follows a defined path, which makes it easier to maintain workflows that need to run the same way every time. This matters in workflows where consistency is critical and the task can be defined clearly upfront.

Best for: Choose Zapier when your workflow depends on reliable app-to-app automation and needs consistent, repeatable execution.

3. Make

If your workflow needs branching logic, conditions, or multiple paths based on inputs, Make gives you more control.

Make is a visual workflow builder that lets you design flows with conditional paths, iterations, and multi-step logic. You can see how data moves through each step and adjust the flow as needed.

What changes when you use it

Workflows can branch based on conditions
Complex logic can be handled inside a single flow
Data handling is more visible at each step
You can build multi-step processes across tools

Why does it work better than Gumloop in this case

Gumloop focuses on AI-driven steps, which work well for flexible tasks. When the workflow depends more on structured logic, branching paths, and precise control, that approach can feel limiting. Make is built for that kind of control. You can define exactly how the workflow should behave at each step, which makes it easier to manage complex flows across tools.

Best for: Use Make when your workflow depends on conditional logic, branching paths, and detailed control over execution.

4. n8n

n8n usually comes up after a few rounds with no-code tools. A workflow works, but only up to a point. Then you need one step that does not fit. A custom API call, a transformation, or logic that depends on your own data. That requirement changes the kind of tool you need.

n8n is a workflow tool that treats automation closer to backend logic. You still get a visual builder, but you can write code, call APIs directly, and control how data moves through each step. It also supports self-hosting, so workflows can run on your infrastructure and connect directly with internal systems.

Where it starts to matter

Once the workflow stops being a sequence of app connections and starts behaving like a system, the demands change. Data needs validation, routing, and transformation. Edge cases need handling. The workflow has to adapt based on inputs. Predefined steps start to feel restrictive at that stage.

What changes in practice

You define how each step behaves instead of fitting into available integrations. API calls, custom logic, and error handling become part of the workflow itself. This also changes how reusable the setup becomes. Logic can be carried across workflows, so new use cases build on existing structure instead of starting from scratch.

Best for: Use n8n when your workflow needs custom logic, API-level control, and the ability to behave like a system rather than a fixed sequence of steps.

5. Activepieces

Activepieces is an open-source workflow automation tool with a visual builder. It gives you a familiar way to connect apps and build flows, with the option to host everything on your own infrastructure.

What changes when you use it

You control where workflows run: Host on your own environment
Data stays within your setup: You decide how it flows across systems
Integrations can be extended: Adjust connections based on your needs
Workflows stay easy to build: Visual builder keeps the process simple

Why does it work better than Gumloop in this case

Gumloop is designed around AI-driven workflows, which work well when the focus is on logic inside the flow. Activepieces becomes a better fit when control over execution and data matters more. It’s the middle ground between fully autonomous AI workflows and programmatic workflows.

Hosting workflows yourself gives you visibility into how they run and removes dependency on a managed platform. This is useful when workflows connect to internal systems or need tighter control over data handling.

Best for: Use Activepieces when your workflow needs control over hosting, data flow, and integrations as it grows

6. Relay.app

Relay is a workflow tool built around clarity. It keeps each step visible and easy to follow, with optional AI steps that fit into the flow rather than driving it.

What changes when you use it

Workflows stay readable: Each step is clear, so you can see what is happening without tracing through layers
Faster iteration: Small changes can be made and tested quickly
AI fits into the flow: Use AI for specific steps like summarizing, drafting, or classification
Easier handoff: Workflows can be understood and managed by others on the team

Why does it work better than Gumloop in this case

Gumloop centers the workflow around AI decisions. That works well for flexible tasks, but it also means more time spent shaping prompts, checking outputs, and handling edge cases when results vary.

Relay takes a different approach. The workflow stays structured, and AI is used for defined steps inside that structure. That makes it easier to reason about what the workflow is doing and adjust it without reworking the whole flow. This becomes useful when the workflow needs to stay clear, easy to maintain, and accessible to others who did not build it.

Best for: Use Relay when your workflow needs to stay readable, easy to adjust, and manageable across a team

7. Lindy AI

Lindy is a personal AI work assistant. Users delegate inbox triage, meeting attendance and notes, calendar scheduling, follow-ups, and admin work by texting Lindy through iMessage/SMS, the web app, or connected apps like Gmail, Outlook, Slack, HubSpot, Salesforce, and Zoom.

What changes when you use it

Delegation by text: Tasks can be assigned from a phone without opening a builder
Personal context: The assistant works across the user's connected inbox, calendar, and CRM with their voice and preferences
Full meeting lifecycle: Prep before, notes during, follow-ups after
Outcome-driven, not flow-driven: Users describe results instead of mapping steps

Why does it work better than Gumloop in this case?

Gumloop is a workflow platform where teams build automations on a canvas. Lindy is an assistant that runs the recurring loop of professional work — email, meetings, calendar, follow-ups — across a single user's connected tools.

The two solve different problems: Gumloop fits when teams want to design and own automations; Lindy fits when an individual or team wants to hand off recurring admin work to an AI assistant.

Best for: Use Lindy when the work is personal admin and coordination across email, meetings, and calendar — not workflow design.

8. Vellum

Vellum is built for teams running AI in production. It focuses on testing, versioning, and monitoring how AI behaves once workflows are live.

What changes when you use it

Prompt versioning: Compare prompts, models, and parameters side by side against test cases
Evaluation framework: Run hundreds of test cases with custom metrics or LLM-as-judge before deployment
Production monitoring: Track real-time performance of deployed prompts and workflows
Workflow orchestration: Chain prompts, business logic, APIs, and tool calls with version control

Why does it work better than Gumloop in this case

Gumloop is built for shipping AI automations across a team, with the canvas as the place where workflows are designed and run. Vellum sits one layer deeper, focused on the prompts and AI logic inside those workflows. It gives engineering and product teams the tools to test prompt and model combinations, deploy with version control, and watch how AI behaves once it's live.

The two are not direct substitutes. Teams pick Gumloop when the goal is letting non-technical users build automations. Teams pick Vellum when the AI logic itself is the product and needs the same rigor as any other production system — testing, releases, monitoring, rollback.

Best for: Use Vellum when AI outputs are core to your product and need to be evaluated, deployed, and monitored with the same discipline as software releases.

9. Pipedream

Pipedream sits between a workflow tool and a backend. It lets you write code, call APIs, and connect services, all inside an event-driven workflow.

What changes when you use it

Code inside workflows: Write JavaScript or Python for each step
Direct API access: Connect to any service, not just prebuilt integrations
Event-driven execution: Trigger workflows based on real-time events
Fine control over data: Transform and route data at each step

Why does it work better than Gumloop in this case

Gumloop is designed around structured workflows with AI steps. That works well when integrations are available, and the flow can be defined clearly.

Pipedream becomes useful when the workflow depends on APIs not covered by standard integrations or requires logic that goes beyond predefined steps. You can write exactly what each step should do, which removes the need to work around tool limitations.

This makes it a better fit for workflows that behave more like backend processes than visual automations.

Best for: Use Pipedream when your workflow depends on APIs, custom code, and event-driven execution across services.

10. Workato

Workato is an enterprise automation platform designed for large-scale workflows across business systems. It focuses on reliability, governance, and deep integrations with enterprise tools.

What changes when you use it

Deep enterprise connectors: Pre-built integrations for Workday, NetSuite, SAP, ServiceNow, Salesforce, and other systems of record
Governance: Role-based access, environment promotion, audit trails, and centralized recipe management
Scale: Built to run high-volume, mission-critical workflows across business units
AI agents: Genie agents work alongside automation recipes for natural-language interfaces to enterprise data

Why does it work better than Gumloop in this case

Both Gumloop and Workato are used inside enterprises, but they enter the organization from different directions.

Gumloop is bottom-up — individual employees and teams build automations on a canvas, often without IT involvement. Workato is top-down — IT and integration teams own the platform, model the systems of record, and grant access to business units.

That changes the workflows each is suited for. Gumloop fits AI-driven, fast-moving automations owned by the people who use them. Workato fits cross-system processes that need IT oversight, formal change management, and integration with enterprise systems where downtime or bad data has real cost.

Best for: Use Workato when workflows span enterprise systems of record, need IT governance, and serve multiple business units with formal access control.

How to Choose the Right Alternative

The choice becomes clearer once you look at where your workflow starts to break.

If the issue shows up at the integration layer, where multiple tools need to work together reliably, tools like Composio or Workato make more sense.
If the workflow itself is well-defined and needs to run the same way every time, Zapier or Make are a better fit. If the logic within the workflow becomes the constraint and triggers and webhools become important, n8n or Pipedream fit better.
If the challenge is AI behavior and its performance in production, Vellum becomes relevant. If the workflow itself needs to shift toward personal execution, Lindy AI is a better direction.

The right choice depends on the constraint you are trying to solve, not just the features each tool offers.

Conclusion

Gumloop is part of a broader shift in how workflows are built. It brings AI into the process and makes it easier to handle tasks that do not fit strict rules.

That works well up to a point. The limits show up in different places depending on the workflow. Sometimes it is integrations. Sometimes it is control over AI behavior. Sometimes it is how reusable the setup is.

Tools like Composio highlight how the space is evolving. Instead of focusing only on workflows, they focus on giving AI reliable access to tools and actions across systems.

Each alternative in this list focuses on one of those areas. There is no single replacement that fits every case.

The right move is to look at your workflow and identify the exact point where it starts to strain. The tool you choose should solve that specific constraint, not try to cover everything at once.

13 Best AI Marketing Tools to Beat Your Competitors (2026 Edition)

Aakash R — Thu, 07 May 2026 08:03:56 +0000

I’ve been doing growth marketing for a while now and if I’ll be honest with you it’s a cut throat competition out there for slightest of attention and winning distribution has become more important then ever before. You have to do everything, SEO, GEO, Reddit, TikTok, YouTube, Performance marketing, Emails, Twitter, and any channel you can think of. And with all the AI tools available right now, there simply is no excuse.

So, I’ve curated all the AI tools that we use in-house for all thing marketing. It covers the entire spectrum copy writing, short video creation to scheduling tools. So, nothing is missed.

So, let’s get all the ingredients for building an effective marketing stack.

Quick Summary

Composio – Connects your entire marketing stack (ads, analytics, CRM) so AI can act on real campaign data instead of isolated inputs.
ChatGPT Deep Research – Breaks down competitors, content strategies, and market gaps with reasoning, not just surface-level summaries.
Seedance (ByteDance) – Converts ideas into full short-form videos (visuals + motion + audio) for rapid content testing.
Lovable – Generates and deploys landing pages from prompts, making campaign launches and experiments fast.
Notion – Central workspace to manage content calendars, campaign planning, and ongoing marketing workflows.
Manus – Creates presentations, documents, and visuals from simple prompts, helping turn ideas into shareable assets quickly.
Midjourney – Produces high-quality, distinctive visuals for ads, thumbnails, and creatives that stand out.
ElevenLabs – Generates realistic voiceovers with control over tone and pacing for ads and video content.
Surfer SEO – Guides blog structure, keywords, and depth based on what’s already ranking to improve search performance.
Jasper – Generates ad copy, email sequences, and variations optimized for different audiences and campaign goals.
HubSpot – Manages CRM, tracks leads, and connects campaigns to actual conversions and revenue.
Hootsuite – Schedules and manages social media content across platforms with built-in AI assistance.
Pebblely – Creates clean, ready-to-use product visuals with different backgrounds and styles from a single image.
Grammarly – Refines writing by improving clarity, tone, and correctness across all marketing content.

How to Use AI Tools for Marketing

AI works best when it fits into the main parts of your workflow and helps you make better decisions as you go.

Email marketing and lifecycle — AI can draft sequences, personalize subject lines, segment lists based on behavior, and predict the best send times. This is one of the highest-ROI uses and it's missing entirely.
Customer research and insights — Analyzing reviews, support tickets, survey responses, and social comments to surface pain points, objections, and the actual language customers use. This often feeds everything else (ads, SEO, content).
Analytics and reporting — Summarizing campaign performance, pulling insights from GA4 or ad platforms, and turning raw numbers into plain-language reports for stakeholders.
Image and visual asset creation — Product photos, ad creatives, thumbnails, social graphics. You mention video but skip static visuals, which are still a huge chunk of marketing output.
Personalization at scale — Dynamic landing pages, tailored email content, and product recommendations based on user behavior.
Brand voice and consistency — Training a custom assistant or style guide so all AI-generated content sounds like your brand instead of generic AI output. Worth flagging because it's a common failure mode of the workflow you described.

13 Best AI Marketing Tools I’ve tried and tested in 2026

There are way too many AI tools right now, and most of them sound useful until you actually try to fit them into your work. A lot of them overlap, and some just slow you down. The ones that matter are the ones you keep coming back to because they actually help you get things done.

Here are some of the tools that I used and kept using:

1. Composio: Connecting Your Marketing apps with Claude and ChatGPT

Composio is an AI integration platform that connects with 1000+ tools across marketing, analytics, and productivity. It plugs into tools like Google Analytics, Meta Ads, Google Ads, Ahrefs, and Google Workspace, and works directly with assistants like ChatGPT and Claude.

After using it across a few campaigns, the biggest shift was how everything started to feel connected. Checking performance, pulling numbers, and figuring out what to do next all happen within a single flow. There is no need to keep jumping across dashboards to piece things together.

It has been especially useful when multiple campaigns are running simultaneously. Looking at ad performance, spotting patterns, and making changes can all happen without losing context, making day-to-day work feel much smoother.

Here are a few ways it has been helping:

All data in one place: Campaign performance, analytics, and content signals come together, so it is easier to see what is working
Less switching during work: Metrics, insights, and actions stay in the same flow
AI with real context: Outputs are based on actual campaign data, which makes them more useful
Better day-to-day flow: Reviewing performance and making updates feels more continuous

Getting started is simple. Connect the tools you already use on the Composio platform, link your AI assistant, and start with something basic, like checking campaign performance. From there, it naturally becomes part of how campaigns are managed.

2. Competitor Research with ChatGPT Deep Research

ChatGPT’s Deep Research mode has been one of the tools I keep coming back to for competitor analysis. It started as a quick way to gather info, but after a few uses, it became something I rely on during early research.

The way it usually plays out is simple. I give it a competitor or a niche and ask for a full breakdown. It pulls their positioning, the type of content they post, how often they publish, how they show up in search, and how people react to them across platforms. Having all of this in one place saves a lot of back and forth and makes it easier to see the full picture.

Prompting made a big difference over time. Early prompts gave basic summaries. Once I started asking for comparisons, gaps, audience reactions, and reasons behind performance, the output became much more useful. It started to feel less like getting answers and more like having a proper research partner.

One thing I found genuinely helpful is how it explains patterns. It does not just list what competitors are doing. It shows why something works and where they are missing out. That is usually where new content ideas or campaign angles come from.

It has been especially useful when looking at a few competitors together before starting a campaign. It gives a clear sense of what is already crowded and what still has space, which makes planning a lot more focused.

3, AI Video Creation with Seedance by ByteDance

Seedance is an AI video generation model by ByteDance that can turn text, images, and clips into full videos. It handles visuals, motion, and audio together, making the output feel more complete without requiring multiple tools.

After using it for short-form content, I found it much easier to take an idea and turn it into a video. A simple prompt can turn into a clip with movement, transitions, and sound. It works well for things like Reels, Shorts, and ad creatives, especially when testing different concepts.

Over time, it became more useful for creating variations. One idea can be turned into multiple versions with different hooks or styles, which helps when testing what actually works. It also works well with references like images or clips, which makes the output feel more intentional.

Here are a few ways it has been useful:

Fast video creation: Ideas turn into videos quickly without going through heavy editing
Multiple variations: One concept can be tested in different styles, hooks, and formats
Good for short-form content: Works well for TikTok, Reels, Shorts, and ad creatives
More control over output: Prompts can guide scenes, motion, and overall look of the video
Less editing effort: Most of the work is handled in one place, so there is less need to jump across tools

4. Website Creation and Launch with Lovable

I started using Lovable recently, and it’s been surprisingly useful for turning simple ideas into clean landing pages. You can describe what you want, and it builds a proper page that actually looks good and is ready to go live. It also handles deployment, so you are not stuck figuring out how to host or publish it.

For marketing work, this makes a big difference. When there is a new campaign idea or offer, a page can be created and live pretty quickly without getting blocked on design or dev. The first version usually comes out solid, and small tweaks are enough to get it ready.

It has made testing much easier. Trying different messaging or offers no longer feels heavy, since each version can be turned into its own page. That makes it simpler to validate ideas and move forward with more confidence.

5. Keeping Everything Organized with Notion

Notion became my go to place for almost everything. It has all the information I need in one place, and it is easy to navigate and organize, which makes managing work much simpler.

It has been really useful for keeping content calendars, tracking campaigns, and writing things out properly. Ideas usually start messy, and Notion makes it easy to shape them into something usable without overthinking the structure.

What I like most is how flexible it is. Pages can be simple or detailed as needed, and everything stays connected. Campaign notes, content ideas, and tasks all sit in one place, so nothing gets lost.

Over time, it just became the place I keep going back to. Planning, writing, tracking progress, everything happens there, which makes it easier to stay focused and keep things moving.

6. Creating Presentations, Docs, and Visuals with Manus

Manus is one of those tools I started using when I needed to quickly pull together different types of content. It can generate presentations, documents, simple websites, and even basic graphics from a prompt, making it useful when ideas need to turn into something presentable quickly.

It became handy during campaign work and internal reviews. Slides for a pitch, a quick doc to explain a plan, or even visuals for content can be created without starting from scratch. A rough idea is usually enough to get a solid first version, and small edits take it the rest of the way.

What made it stick is how it handles multiple formats in one place. Instead of jumping between tools for slides, docs, and visuals, everything can be created in a single flow. That makes it easier to keep things consistent and move faster when working on different pieces of the same campaign.

It has been useful when something needs to be shared quickly, whether it is a presentation, a doc, or a visual asset. It takes away the friction of starting from a blank page and helps get to a usable version much faster.

7. Designing Scroll-Stopping Creatives with Midjourney

Midjourney is the tool I reach for when a visual needs to catch attention. The images have a distinct look that feels more styled and less generic, which helps when everything online starts to look similar.

Most of the use has been around ad creatives and thumbnails. A rough idea can turn into a strong visual in a few tries, and those visuals often shape the direction of the content itself. It is not just about filling space; it actually influences how the message is presented.

Getting better results comes down to how the prompt is written. Small changes in wording, style cues, or references can change the entire feel of the image. Over time, it becomes easier to guide it toward a specific look.

It also works well for exploring different directions. One concept can be turned into multiple styles, which makes it easier to see what fits and what stands out before using it in a campaign.

8. Voiceovers and Audio with ElevenLabs

ElevenLabs is what I’ve been using for voiceovers, especially for short videos and ads. It turns text into natural-sounding speech, and the voices actually feel real, which makes a big difference when the content is meant to hold attention.

It became useful while working on video content. Writing a script is one part, but getting a clean voiceover used to take extra effort. With ElevenLabs, a script can turn into a usable voice track in minutes, and small edits are easy to try without redoing everything.

The control over tone and pacing is what stands out. You can adjust how the voice sounds based on the content type to better match the mood of the video or ad. It also works well when testing different versions of the same script with slight variations.

It fits well into content workflows where audio matters. Videos feel more complete, and the process of getting from script to final output becomes much smoother.

9. Writing SEO Blogs That Actually Rank with Surfer SEO

Figuring out what to include in an SEO blog used to feel like guesswork. Surfer SEO changed that by providing clear direction on what the content should cover, based on what is already ranking.

Working on blog posts helped shape the structure before writing even started. It shows the kinds of headings, keywords, and depth that top pages have, making planning much easier. The content ends up feeling more complete and aligned with what people are searching for.

Another thing that helped was staying on track while writing. It is easy to drift or miss important points, and Surfer keeps things focused without forcing a rigid style. The content still feels natural, just more aligned with search intent.

10. Writing Ad Copy and Emails with Jasper

Coming up with good copy on demand is harder than it looks, especially when you need multiple versions for ads or emails. Jasper has been useful in those moments when ideas are there, but the wording needs to be sharper.

It works well for creating variations. A single idea can turn into multiple ad copies, email drafts, or landing page lines, which helps when testing different angles. The output usually feels more structured for marketing compared to general AI tools.

The part that stands out is how it handles tone and intent. You can guide it based on the audience or goal, and it adjusts the writing to match. That makes it easier to keep the message aligned with the campaign. It works well in workflows where copy needs to be tested and improved. Having multiple options ready makes it easier to pick what works and build on it.

11. Managing Marketing and CRM with HubSpot

HubSpot is something that comes in once everything starts growing. Content, leads, emails, campaigns, all of it needs a place to stay organized, and this is where HubSpot starts to help.

It has been useful for tracking leads and seeing how people move from first touch to conversion. Instead of guessing what is working, you can actually see which campaigns or channels are bringing results. That makes it easier to decide where to focus.

Email campaigns and follow-ups also become easier to manage. Setting up flows, tracking engagement, and keeping everything connected to the same contact data makes things feel more structured.

It works well when marketing starts getting serious. Everything from campaigns to customer interactions sits in one place, which makes it easier to manage and improve over time.

12. Scheduling and Social Media Management with Hootsuite

Keeping up with multiple social platforms can get messy once posting becomes a regular habit. Hootsuite made that part easier by bringing everything into one place and adding AI support for content and scheduling.

It has been useful for planning posts in advance and maintaining a consistent flow. Content for different platforms can be scheduled in one go, which helps avoid last-minute posting. It also gives a clear view of what is going out and when. The AI features help generate captions and adjust tone based on the platform.

That saves time when you need variations of the same content. It also helps when you are not sure how to phrase something.

It works well when managing multiple channels. Posting, tracking engagement, and staying consistent become easier, helping keep the social presence active without too much effort.

13. Turning Ideas into Product Shots with Pebblely

Getting good product images usually takes time or a proper setup. Pebblely made that part much easier by generating clean product shots from a simple image.

It has been useful for quick creatives, especially when testing ads or trying different visual styles. A basic product image can be turned into multiple backgrounds and setups, helping create variety without a full shoot.

A big advantage is the speed at which you can try different looks. Changing the setting, style, or feel of the image takes a few clicks, so it becomes easy to explore different directions for a campaign. It works well when visuals are needed quickly. Product images come out clean and ready to use, which helps keep ad creatives and content moving without extra effort.

Conclusion

AI tools can feel overwhelming at first because there are so many options. After trying a bunch of them, it usually comes down to a smaller set that actually fits into your day to day work. Those are the ones that end up sticking.

Each of these tools solves a different part of marketing, from research and content to ads and tracking. When they start working together, things feel a lot more clear and manageable. You spend less time figuring things out and more time improving what is already working.

At the end of the day, the tools are just support. The real difference comes from how you use them, how often you test ideas, and how you build on the results.

AI Workflow Automation Tools Are a Mess, Here’s What I Learned the Hard Way

VK — Tue, 05 May 2026 13:53:16 +0000

I spent days testing tools, trying to build a simple AI workflow automation setup, and it was way harder than it should have been.

What is AI Workflow Automation?

AI workflow automation is the process of using AI tools to connect, trigger, and execute tasks across apps without manual intervention.
In theory, it should simplify work. In reality, most tools make it fragmented.

Built a lead routing workflow last week that should've taken two hours. New form submission comes in, gets scored, lands in HubSpot, pings the right Slack channel. Done this before. Should've been an afternoon.

Took three days. Not because it was hard, because I kept convincing myself the next tool would be cleaner. Got halfway through in one platform, hit some friction, jumped to the next one. By day two I had half-finished automations in four different tools and a creeping feeling that most of the "AI automation" category is just the same three features in different packaging.

Eventually I did the only reasonable thing: scrapped everything and rebuilt the same workflow in every tool I was curious about. Back to back. Same workflow, every platform.

Here's what I actually learned from that:

n8n is the one I keep coming back to for client work. Self-hosted it on a cheap Hetzner box and had something running before lunch. The real moment was when a client needed an audit trail, pulled up the canvas, traced every branch visually, exported something readable in five minutes. Nothing else I tried lets you do that cleanly.

Make was the surprise for internal stuff. Handed it to my content team with zero hand-holding. Monday someone asked if it was broken. Wednesday I got a screenshot, they'd built an entire RSS-to-Notion briefing pipeline end to end. The economics vs Zapier at any real volume aren't close either.

Composio was the thing I didn't expect to change how I work. I'd been writing OAuth boilerplate by hand every time I added a new integration to an agent. Connected Gmail, GitHub, Notion, and Slack to a LangChain agent in under an hour with zero auth code. The three devs I've recommended it to are all still using it months later.

Zapier I've rage-quit twice and come back twice. The docs are just the best in the category, when something breaks at 11pm and a client is waiting, that genuinely matters more than features. Expensive at volume though, that part isn't a myth.

Also been playing with Claude Cowork for simpler delegation stuff, typed a natural language instruction for a recurring research task and it just ran with no workflow setup at all. Falls apart on anything with real conditional logic but for straightforward recurring tasks it's kind of wild.

Tried Lindy too. The meeting prep agent is genuinely useful, drops a research brief before every discovery call without me thinking about it. Tried using it for anything beyond that and it struggled. Feels like it has a narrow sweet spot but inside that sweet spot it's really good.

Hadn't touched Bardeen until a sales rep on my team mentioned she was spending two hours a day copying LinkedIn profiles into our CRM manually. Set her up with a playbook in 25 minutes, cut the task to four minutes. Main limitation is your browser has to stay open, not great for anything you want running in the background overnight.

Probably the most useful thing I took from the whole exercise: most people are treating these tools like they're interchangeable and they're really not. There's a difference between tools for delegation, tools for structured data routing, tools for agent infrastructure, and tools for browser work. Picking the wrong category for your problem is why people keep jumping between platforms and feeling like nothing works.

Until AI workflow automation tools become more unified, developers will keep wasting time stitching together workflows instead of building actual products.

Complete analysis: Read the full blog post: top AI Automation tools

Kimi K2.6 vs. Claude Opus 4.7 in a Weird Game Coding Test ✅

Shrijal Acharya — Tue, 05 May 2026 13:04:03 +0000

Kimi K2.6 has been getting a lot of love lately, especially from devs who want a strong coding model without paying premium model prices every time they run a big prompt.

So I wanted to see how good this model actually is. But this time, I wanted to compare it with something much heavier, the developers darling Claude Opus 4.7.

On paper, Claude Opus 4.7 and Kimi K2.6 are very different models.

One is a premium frontier model from Anthropic. The other is Moonshot AI's much cheaper open model for coding and agentic tasks.

The pricing difference is pretty wild too. Claude Opus 4.7 costs $5/M input tokens and $25/M output tokens. Kimi K2.6 is listed at $0.95/M input tokens and $4/M output tokens, with cached input going even lower at $0.16/M tokens.

That is a pretty big gap.

So in this article, we'll see how the cheaper model, Kimi K2.6, does against Claude Opus 4.7.

For the test, I gave both models the same coding task: build a small Minetest (similar to Minecraft) bounty board with a TypeScript backend, then extend it with Google Sheets logging through Composio.

TL;DR

If you want the quick take, Claude Opus 4.7 clearly won this test, but it was painfully expensive.

Opus was better at the real task. The local build was cleaner, and it was the only one that got the real Google Sheets integration working.
Kimi did pretty well in Test 1. It got the local bounty board working for way less money, but it needed more debugging.
Test 2 changed the whole comparison. Opus was expensive, but it finished. Kimi just could not put it all together.

The cost difference was wild though.

For the first local bounty board test, Opus cost around $3.59, while Kimi came in at around $0.39. That is a huge gap. For the basic version, Kimi honestly did pretty well for the price.

But once the task got a little more real, the gap became way more obvious.

Opus got it working, even though it needed a little back and forth. The Google Sheets sync worked, and the project was modular enough that I could test the whole flow with two curl requests without even opening the game.

The painful part is that the Composio run alone cost $16 and took around 28min 52sec API time.

Kimi, on the other hand, burned 135k+ tokens, took around 25 minutes, cost around $5.03, and still did not really get any closer.

👀 So yeah, Kimi K2.6 is a usable and interesting cheaper model. But in this test, it could not really come close to Opus 4.7 for real-world coding.

Evaluation

I treated this like a real project, not a benchmark chart. Both models got the same prompts, and I compared the results based on whether it actually worked, how clean the code was, how much debugging it needed, how long it took, and how much it cost. That last one matters a lot here.

Setup

Same tasks and prompts for both models (Test 1: local-only bounty board, Test 2: real Composio Google Sheets sync).
Same target architecture: Minetest/Luanti Lua mod + TypeScript backend.
Same success criteria: /bounty flow works in-game, backend APIs behave correctly, and in Test 2 the completion is appended to Google Sheets via Composio.

What I measured

Functional correctness (most important): Did it work end-to-end with real verification?
- Local run: could a player generate, progress, and complete bounties without breaking state?
- Backend: did /health, /api/bounty/generate, /api/bounty/complete, and /api/leaderboard return the expected shapes?
- Test 2: did the Google Sheets append succeed, and could I validate it from the API without needing to be in the game?
Code quality and structure: modularity, clarity, and whether the repo was easy to reason about and test.
Debug burden: how many follow-ups were needed, how confusing the failure modes were, and whether issues were “real bugs” vs. “misconfiguration traps.”
Time: API time and wall time for each run.
Cost and token usage: input, output, cache behavior, and total run cost.
Practical ergonomics: whether I could validate quickly (for example, testing the full backend + Composio flow with curl).

How I verified outcomes

Test 1: ran the backend locally, joined a local Minetest world, used /bounty, and confirmed task tracking, rewards, and leaderboard persistence.
Test 2: verified the end-to-end sync by generating and completing a bounty via the backend API, and confirming a successful Google Sheets append through Composio.

Scoring approach

This was not a “unit test leaderboard” benchmark. It was a real build-and-ship check.

A model “wins” when the project works with minimal intervention.
A model “loses” when it cannot reach a working state in reasonable time/cost, even if parts of the code look promising.

Coding Test

For this test, I used the following CLI coding agents:

Claude Opus 4.7: Claude Code, Anthropic's terminal-based agentic coding tool

Kimi K2.6: OpenCode via OpenRouter

ℹ️ This is a practical coding test, so both models get the same prompt. I will compare time taken, code quality, token usage, cost, and all that stuff.

What are we building?

For this test, I wanted something small enough to verify properly, but still weird enough to show how each model handles an unusual idea.

So, we're building a simple Minetest/Luanti bounty board.

A player can join a local world, run /bounty, get a task like mining dirt or placing torches, and receive a reward after completing it.

After that, the backend records the completion, logs it to Google Sheets through Composio.

I get it, the concept is a little unusual on purpose.

Test Prompts

Both models received the same prompts for each test.

Test 1 Prompt: Local Bounty Board Prompt
Test 2 Prompt: Real Composio Integration Prompt

Test 1: Local Bounty Board

This first test is the basic version of the idea.

No external tools, no Composio. Just the game, the backend, and the local bounty flow working properly.

The goal was simple. A player runs /bounty, gets a task, completes it inside the game, and the backend tracks the progress without everything falling apart.

Claude Opus 4.7

Claude Opus 4.7 handled the first test really well.

The local bounty board worked end to end. It built the TypeScript backend, the Minetest/Luanti Lua mod, the command flow, progress tracking, rewards, and leaderboard persistence without needing a bunch of follow-up fixes.

The file structure also felt nice, which I had specifically asked for in the prompt:

The backend was built with Express, Zod, and Vitest. It also handled the boring stuff properly, which honestly matters a lot here:

npm test passed with 11/11 tests
npm run build passed cleanly
/health, /api/bounty/generate, /api/bounty/complete, and /api/leaderboard returned the right response shapes
incomplete bounty completions returned a clean 400

It created the Lua files cleanly, used minetest.request_http_api(), handled secure.http_mods, tracked digging and placing, stored player bounty state, and handled inventory rewards properly.

The whole run took around 12 minutes of API time, with about 23 minutes wall time. That is a bit longer than a quick web app build test, but for this kind of cross-stack project, it felt fair.

The cost came out to $3.59, which is definitely not cheap. But to be fair, the output was actually useful. It added a lot of code, but most of it was real implementation, not random filler like CONTRIBUTING.md, INSTALLATION.md, and all those extra files models sometimes create for no reason.

You can find the code it generated here: Claude Opus 4.7 Code

Here's the demo:

Cost: ~$3.59
Duration: 12min 3sec API time, 23min 53sec wall time
Code Changes: +1,688 lines, 0 lines removed
Token Usage:
- Input: 65
- Output: 54.8k
- Cache read: 2.8M
- Cache write: 129.8k

Quick Verdict

It worked end to end without much tweaking. I only had to configure ~/.minetest/minetest.conf and add this line:
secure.http_mods = bountyboard
Pretty much everything else was smooth. Great quick MVP.

I noticed one small issue: mine_node bounties can be farmed by placing and then re-mining the same blocks, because vanilla Minetest does not track who placed a node.

But that's fine. That is not really a code issue here.

Kimi K2.6

The core idea worked. Kimi created the TypeScript backend, the Minetest/Luanti mod, the bounty commands, task tracking, completion flow, rewards, and leaderboard logic.

The backend side looked solid enough. It used Express, Zod, and Vitest, and the main routes were there:

/health
/api/bounty/generate
/api/bounty/complete
/api/leaderboard

It also created the Lua mod files properly and handled the basic /bounty flow inside Minetest. The code was not bad either. I just felt like it was not as clean or modular as what Opus 4.7 wrote.

But there was one really irritating issue.

Somehow, Kimi wrote the global Minetest config in ~/.minetest/minetest.conf with this:

secure.http_mods = bountykimi

But then it also created a world config and added a different mod name there.

So when I loaded the world, Minetest used the world-level config. That basically overrode the global config behavior I was expecting. Because of that, the HTTP API was not enabled for the actual mod that was running.

This took me more than half an hour to debug.

And honestly, because I do not have much experience with Minetest config behavior, this was super annoying.

The run itself was much cheaper and faster than Opus. Kimi used around 52k context tokens, took about 9 minutes 27 seconds, and cost around $0.39.

That price difference is pretty wild. Opus cost around $3.59 for the first test, while Kimi came in under $0.40.

You can find the code it generated here: Kimi K2.6 Code

Here's the demo:

Cost: ~$0.39
Duration: ~9min 27sec
Code Changes: +4,671 lines, 0 lines removed
Context Used: 52,073 tokens
Context Window Used: 20%

Quick Verdict

The local bounty board idea worked, the code was usable, and the model clearly understood the Lua + TypeScript setup. But if you notice, Kimi wrote more than twice as much code as Opus 4.7.

The main problem was the Minetest config mess. It added secure.http_mods = bountykimi globally, but then created another world-level config with a different mod name, which made debugging way more painful.

So yeah, Kimi passed the first test, but not as smoothly as Opus.

Test 2: Real Composio Integration

Now this is where the actual test, and the fun, begins.

The custom mod is ready, so now it is time to integrate Composio and give the game a quick agentic touch.

The idea is simple. As players progress through the game, their bounty completions get logged into Google Sheets with Composio.

Claude Opus 4.7

Claude Opus 4.7 did manage to add the real Composio integration, but this one was not as smooth as Test 1.

The backend could sync bounty completions to Google Sheets. The nice thing is that I did not even need to open Minetest to test whether it was working. Because the project was structured cleanly, I could test the whole backend flow with just two curl requests.

First, generate a bounty:

curl -s -X POST http://localhost:8787/api/bounty/generate \
  -H 'Content-Type: application/json' \
  -d '{"player":"singleplayer","availableTasks":["collect_item"]}' \
  | tee /tmp/b.json | jq

Then complete it:

curl -s -X POST http://localhost:8787/api/bounty/complete \
  -H 'Content-Type: application/json' \
  -d "$(jq -nc \
        --argjson b "$(jq .bounty /tmp/b.json)" \
        --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
        '{player:"singleplayer", bounty:$b, progress:{current:$b.target.count, required:$b.target.count}, completedAt:$ts}')" \
  | jq

And if everything is configured correctly, the second response looks like this:

{
  "ok": true,
  "message": "Bounty completed.",
  "leaderboard": {
    "player": "singleplayer",
    "points": 8,
    "completedBounties": 1
  },
  "sync": {
    "googleSheets": {
      "ok": true,
      "message": "Google Sheets row appended."
    }
  }
}

This is one of the things I love about Opus the most. It usually creates a pretty modular setup. The game mod, backend logic, and external sync were separated well enough that I could test the Composio part directly from the API without needing to run around inside the game every time.

It did run into a dev server issue where the tsx command was parsing watch incorrectly and treating it like the entry file.

After a bit of back and forth, it fixed the error. It eventually built a small runtime env loader and adjusted the config import so the backend could read the environment properly before the rest of the app booted.

After that, the build worked and the Google Sheets sync started working.

But that cost was painful. It literally cost me around $16. Like, actually :(. If you are not watching usage, this thing can make you broke real fast.

It took 28min 52sec API time, and about 1hr 17min wall time.

Apart from that, the code did work. But it cost way more than I expected for one run.

You can find the code it generated here: Claude Opus 4.7 Code - Composio

Here's the demo:

Cost: $16.03
Duration: 28min 52sec API time, 1hr 17min 40sec wall time
Code Changes: +1,848 lines, 507 lines removed
Token Usage:
- Input: 100.2k with Claude Haiku 4.5, plus Opus usage shown in the session
- Output: 3.2k with Claude Haiku 4.5, 123.3k with Claude Opus 4.7
- Cache read: 22.3M
- Cache write: 269.3k

Quick Verdict:

Claude Opus 4.7 got the real Composio integration working, especially the Google Sheets logging.

How cool is that? You add a custom agentic feature inside a game. A literal public game.

So yes, it worked. But $16 for this one run hurt.

Kimi K2.6

Kimi K2.6 did not do well on this test. It was pretty much busted.

From the start, it ran into a bunch of errors. The dev server broke, tests were failing, and even after a little handholding, it only managed to fix part of the test situation.

It eventually got past some of those failures, but the bigger problem was the actual Composio implementation. It did not seem fully sure how to wire the integration cleanly into the existing backend.

I had to stop and help again and again, but it still could not make meaningful progress with the build.

After spending more than 25 minutes and burning over 130k tokens, there was still no real progress. At that point, I had to stop the run.

Why on earth is it reading a version.txt file?

So yeah, I am calling this one a fail for Kimi K2.6.

Cost: ~$5.03
Duration: ~25min
Token Usage: 135,109+

Quick Verdict:

Kimi K2.6 failed this test.

It got stuck around tests, build issues, and the real Composio implementation. Even with manual help, it could not get the integration into a clean working state.

For the local bounty board, Kimi was surprisingly usable. But once the task moved into real external integration, it struggled a lot more.

Final Thoughts

Both Claude Opus 4.7 and Kimi K2.6 were pretty solid in this test, at least for the local version.

The task was not that simple either. It had Lua, TypeScript, SDK docs, backend logic, game commands, and the full flow had to work end to end.

Plus, the idea itself is not that common. Building an AI agent concept inside a custom game mod is not easy, and it is definitely not a one-shot thing, so props to both models.

Opus 4.7 did better overall. The code was cleaner, and as usual, Anthropic models are pretty good at that.

The only thing I hate with Anthropic models is the session limit.

I absolutely hate how little session usage you get. Opus 4.7 especially just eats through it completely in like 3 to 5 prompts.

Kimi K2.6 is an interesting model. Open models have not always been the best in my experience with real-world projects, but with every new model, my expectations rise a little.

Let's see where Kimi K2.6 goes from here.

Shrijal AcharyaFollow

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

Top 10 Skills to Use with Antigravity 🤖

Aakash R — Tue, 28 Apr 2026 05:34:08 +0000

I use Antigravity almost every day while building things. In the beginning, I was just running agents and connecting tools, but it still felt like I was doing a lot of work outside the flow.

Then I came across agent skills. They are basically plug-and-play capabilities that let your agent connect with different tools and actually get things done. I got curious and started trying them out in my own workflow.

That is when things started to click. I was not jumping between tools or writing extra logic for every step. I could use a skill and keep everything inside one flow. It made the whole setup feel much more natural and a lot less messy.

So in this article, I am sharing 10 useful skills you can use with Antigravity, what they do, and where they can help in real workflows.

1. Tool Integration with Composio

The Composio skill is what connects your agent to external tools and services. It gives you access to 1000+ tools through a single interface, so you don't have to deal with separate APIs, auth flows, or custom integrations for each one.

Everything shows up as simple actions your agent can call when needed. It also takes care of things like sessions, tokens, and maintaining stable connections, so you do not have to worry about the setup.

In real use, your agent can find a tool, connect to it, and run actions as part of one flow. It can pull data from one place, use it, and trigger something somewhere else without extra code. You can also chain multiple steps, handle errors, and react to events, which makes it work well for real workflows.

Why it matters

No need to deal with OAuth or token handling for every tool
You can chain actions across tools in one run
Works with different frameworks, so you are not locked in
Handles sessions, errors, and execution flow for you
Supports triggers, so your agent can react to events

Who is it useful for: If your agent needs to talk to more than one tool, you will need this. It is useful for anyone building multi-step workflows or connecting to tools like GitHub, Slack, or other platforms where setup usually takes time.

How to install it

npx skills add composiohq/skills

2. Web Data Extraction with Apify

The Apify skill lets your agent pull real, structured data from the web, not just search results. It can scrape platforms like Instagram, YouTube, Google Maps, Amazon, and more, returning clean JSON that your agent can use directly.

You can also build and run custom scrapers, so you are not limited to predefined sources. In practice, your agent can collect live data, track updates, and combine multiple sources in one flow, working with fresh information that it can actually act on.

Why it matters

Gives your agent access to real-time web data
Supports many platforms out of the box
Returns structured data your agent can directly use
Let's you build and run custom scrapers
Helps avoid relying on outdated information

Who is it useful for: This is useful if your agent needs live external data. It works well for tracking prices, monitoring competitors, collecting leads, following trends, or building data pipelines.

How to install it

npx skills add apify/agent-skills

3. Real-World Communication with Twilio

Twilio lets your agent send messages, make calls, and handle communication over SMS, WhatsApp, and voice. It turns your agent from just processing data into something that can actually reach people. You can use it for notifications, alerts, OTP verification, reminders, or automated voice calls.

Your agent can trigger messages or calls as part of a workflow, like sending alerts, confirming actions, or verifying users. It supports both outbound and inbound communication, including text-to-speech, call handling, and message tracking.

Why it matters

Let your agent interact with real users
Supports SMS, WhatsApp, and voice in one place
Enables OTP and verification workflows
Works for alerts, notifications, and escalations
Helps complete workflows without human handoff

Who is it useful for: Useful for any workflow that needs human interaction. This includes DevOps alerts, customer notifications, verification flows, support systems, and any case where your agent needs to reach someone directly.

How to install and use it

npx skills add openclaw/skills-twilio

4. Multimodal AI with Replicate

The Replicate skill gives your agent access to a wide range of AI models for things beyond text. It includes models for image generation, video, audio, speech, and more, all available through a simple API without needing to manage GPUs or setup. This means your agent can generate visuals, process audio, or work with video as part of its workflow.

Your agent can pick the right model, run it, and use the output directly. It also supports fine-tuning and lets you work with production-ready models that scale automatically, so you can build real features without worrying about infrastructure.

Why it matters

Adds image, video, audio, and speech capabilities to your agent
No need to manage GPUs or ML infrastructure
Access to a large collection of ready-to-use models
Supports fine-tuning for custom use cases
Scales automatically based on usage

Who is it useful for: Anyone building agents that need more than text. This includes generating images, creating videos, processing audio, or building multimodal applications without having to handle ML infrastructure.

How to install and use it

npx skills add replicate/skills

5. Data Insights with Metabase

The Metabase skill connects your agent to your internal business data. It lets your agent query databases using natural language, generate and run SQL, create dashboards, and surface insights using the semantic layer your team has already set up.

This means your agent is not just working with external data; it is working with the data that actually matters to your business.

Your agent can explore data, detect patterns, create visualizations, and even manage dashboards. It can turn plain questions into queries, refine results, and keep everything within your existing data permissions and structure.

Why it matters

Gives access to internal business data, not just public data
Converts natural language into SQL queries
Helps generate insights and dashboards automatically
Works within your existing data governance setup
Reduces the need for manual data analysis

Who is it useful for: Useful for teams that rely on internal data, like operations, finance, product, and analytics. It is also helpful for developers building agents that need to monitor systems or generate insights from structured data.

How to install it

npx skills add metabase/agent-skills

6. Infrastructure and Edge Control with Cloudflare

The Cloudflare skill gives your agent access to Cloudflare’s full developer and infrastructure stack. It covers topics such as Workers, storage, networking, security, and AI tools, and helps your agent choose the right service for the task. Instead of relying on static docs, the agent receives up-to-date guidance and patterns for building or managing systems.

Your agent can work with deployments, manage infrastructure, apply security rules, and build or update edge services. It can also generate production-ready setups using Cloudflare tools and follow best practices without you needing to look everything up manually.

Why it matters

Covers a wide range of infrastructure and edge services
Helps choose the right tools based on use case
Uses up-to-date documentation and patterns
Supports building and deploying directly on Cloudflare
Useful for both development and security workflows

Who it is useful for: Useful for developers and teams working with deployment, infrastructure, or edge computing. It is especially helpful for platform engineers, security workflows, and anyone building or managing apps on Cloudflare.

How to install and use it

npx skills add cloudflare/skills

7. Programmatic Video Creation with Remotion

The Remotion skill lets your agent create videos using code. It is built around the Remotion framework, where videos are defined using React components, animations, and data. This means your agent can describe a video and generate it without using a traditional editor.

It covers things like animations, captions, charts, media handling, and timing, so everything needed to build a video is handled through code.

Your agent can generate videos from data, text, or events, and control every part of the output. Since everything is code, the videos are repeatable, editable, and easy to update. It also supports advanced features like animations, audio sync, and visual effects, making it useful for more than just simple clips.

Why it matters

Turns data and text into videos automatically
No need for manual editing or design tools
Supports animations, charts, captions, and effects
Videos are version-controlled and repeatable
Useful for automated and scalable content creation

Who is it useful for: Useful for teams that need to generate videos as part of workflows. This includes marketing content, data reports, product updates, or any case where a video output is more useful than text or static files.

How to install it

npx skills add remotion-dev/skills

8. API Testing and Validation with Postman

The Postman skill gives your agent a way to test and validate APIs before using them in a workflow. It acts as a pre-check layer, ensuring endpoints are working, responses are correct, and nothing breaks mid-run. It can also generate tests, update collections, and work with various APIs, including REST, GraphQL, and more.

Your agent can check APIs, catch issues early, and even automatically create or update test cases. This helps avoid failures during execution and keeps workflows stable when dealing with multiple external services.

Why it matters

Prevents workflows from failing due to broken APIs
Automatically generates and runs API tests
Supports multiple API types in one place
Helps maintain reliability across workflows
Reduces manual testing effort

Who is it useful for: Useful for any agent that depends on APIs. It is especially important for multi-step workflows, platform engineering, QA automation, and systems where reliability is critical.

How to install it

npx skills add postman/agent-skills

9. Backend and Database Workflows with Supabase

The Supabase skill provides access to backend capabilities like databases, authentication, storage, realtime updates, and edge functions. It also includes strong Postgres best practices, helping with query optimization, performance tuning, and handling common issues around auth, sessions, and permissions.

It can be used to create and manage databases, run queries, handle user authentication, and build backend logic as part of a workflow. It also guides how to write efficient SQL, avoid performance bottlenecks, and follow patterns that are suitable for production use.

Why it matters

Full backend capabilities in one place
Helps generate optimized and secure SQL
Covers auth, storage, realtime, and edge functions
Includes production-ready patterns
Reduces common database mistakes

Who it is useful for: Useful for developers building full-stack or backend-heavy workflows, especially when working with databases, authentication, or Postgres in production.

How to install and use it

npx skills add supabase/agent-skills

10. Payments and Billing with Stripe

The Stripe skill helps handle payments, subscriptions, and billing workflows with the right APIs and patterns. It guides how to use modern Stripe features like Checkout Sessions, Payment Intents, and webhooks, while avoiding outdated methods. It also supports working with events, customer data, and payment states in a structured way.

Why it matters

Helps build reliable payment and billing workflows
Uses up-to-date Stripe APIs and patterns
Supports subscriptions, checkout, and webhooks
Reduces errors in payment handling
Works for both one-time and recurring payments

Who it is useful for: Useful for developers building products that involve payments, subscriptions, or billing. This includes SaaS platforms, e-commerce systems, and any workflow that needs to handle transactions or customer billing.

How to install and use it

npx skills add stripe/ai--skill stripe-best-practices

Conclusion

Once you start using skills like these, Antigravity stops feeling like just another tool and starts feeling like a system that can actually get things done end to end. Each skill handles a specific part of the workflow, but together they cover everything from data and infrastructure to communication, content, and payments.

You do not need all of them at once. The real value comes from picking the ones that match your workflow and slowly building around them. Over time, you end up with flows that are cleaner, more reliable, and require less manual effort.

If you are already using Antigravity, trying out even a couple of these skills can change how you approach building. It is less about wiring things together and more about letting the system handle the heavy lifting.