DEV Community: Composio

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.

Top Marketing Skills For Claude Code, OpenClaw & Hermes

Developer Harsh — Fri, 24 Apr 2026 06:18:47 +0000

With tools like Claude Cowork and OpenClaw, the marketing and GTM stack is evolving fast. People are spinning up SEO pages, firing UGC videos, automating ads at an industrial scale. And GTM and marketing is going to blow up in next few months.

So, I have curated some great skills that community has built and some of them I personally use.

So I spent last week testing and collating everything. Here are the 10 marketing skills for Claude Code/ Cowork and OpenClaw that are actually worth using.

Quick Summary

GEO / AEO (AI Search Optimization) Skill - Audits and optimizes pages to get cited in AI search (ChatGPT, Perplexity, Google AI Overviews) with fixes, llms.txt, and schema.
SEO + GEO Full-Stack Skill - An end-to-end workflow that does keyword research, drafting, and optimization for both traditional SEO and AI discovery.
Paid Ads Audit Skill - Runs deep multi-platform checks to find wasted spend, diagnose performance issues, and generate new creative and copy variants.
Firecrawl Web Intelligence Skill - Gives agents live web scraping and crawling to extract clean markdown and structured data for competitive research.
Design Skill - Extracts design systems from UI references and outputs design tokens and specs to keep builds consistent and non-generic.
Remotion Video Skill - Turns a video brief into Remotion-ready React code so you can ship programmatic product videos reliably.
Marketing Page Generation (Frontend) Skill - Generates bold, conversion-focused landing pages with production-ready code instead of generic SaaS templates.
Content Ops Skill - Runs the editorial pipeline end-to-end: audit, briefs, drafting, repurposing, and distribution from one workflow.
Humanizer Skill - Removes AI-writing tells through multi-pass editing so posts sound opinionated, natural, and genuinely human.

For using all these skills effectively you’ll need access to data stored in multiple different applications.

For example, for full SEO data you’d need access to Google Search Console, Ahref, etc. And for scheduling posts for social medias you’d need to connect Claude or OpenClaw with Tiktok, Youtube, LinkedIn, Reddit, and Twitter.

For Ads and conversion pipeline monitoring yo’d need Google Ads, MetaAds, Posthog, Mixpanel, etc.

Check Out the full catalog.

Composio is the single place to get all these apps using a single MCP server and it’s super easy to set it up. Just log in to dashboard.composio.dev and click on the client app you want.

If you need some guides, here’s how you can do it in OpenClaw and Claude Cowork.

For starters, let’s schedule a week of launch posts for social media - one of the grueling pain point for any content team.

Pre-requires (authenticate):

once all done, let’s create a 7 days launch post. This uses Claude Code.

/to-be-added

Top 10 Marketing Skills

Here are the list of top 10 marketing skills, that can 10 your marketing. For each I have shared:

What each skills does,
Why use it.
Prompt templates you can follow,
The link to get you started

Let’s begin:)

1. GEO / AEO SKILL - AI SEARCH OPTIMIZATION

AEO has become quite popular now a day’s, but not many are good at handling it.

This skill optimizes the content to get cited by ChatGPT, Perplexity, Google AI Overviews, and Gemini. Furthermore, it scores citability, generates llms.txt, adds schema markup, and outputs a client-ready PDF audit report.

Usage

Run a full GEO audit on any URL → get citability score + prioritized fix list across 13 dimensions.
Generate an llms.txt file so AI crawlers understand the product site structure and index it correctly.
Optimizes existing blog posts for AI citation with E-E-A-T signals, entity clarity, and FAQ schema injection
Produce a branded PDF GEO report ready to send to a client or CMO, for contrast agencies charge $2K–$12K for this

Prompt

Run a GEO audit on [URL]. Score: citability, AI crawler access, brand mention presence, schema markup, content factual density, and E-E-A-T signals. Output a full report with prioritized fixes. Then generate an llms.txt file and FAQ schema JSON-LD for the top 3 pages.

To learn more , checkout https://github.com/zubair-trabzada/geo-seo-claude by zubair.

2. SEO + GEO FULL STACK SKILL

your entire SEO + GEO workflow packaged into 20 skills covering: keyword research, content writing, technical audits, and rank tracking for both traditional search and AI platforms using claude code, openclaw , hermes.

All scored against the CORE-EEAT benchmark (80 items) and CITE domain rating (40 items).

Usage

Runs keyword research on Ahref → content gap analysis → full draft → AEO/GEO optimization in a single chained workflow
Audit any page against 80 CORE-EEAT quality criteria and get a scored report with line-level fixes
Generate programmatic SEO pages at scale from a keyword list and a content template
Optimize for AI citations across ChatGPT Search, Perplexity, and Google AI Overviews simultaneously

Prompt

Run the full SEO + GEO workflow for [topic/URL]. 

Step 1: keyword research and gap analysis vs [competitor]. 
Step 2: write a 1,500-word article scored against CORE-EEAT. 
Step 3: apply AEO optimization - add FAQ schema, HowTo markup, and question-phrased headings. 
Step 4: output a GEO readiness score.

You can explore more at: https://github.com/aaron-he-zhu/seo-geo-claude-skills by arron

3. PAID ADS AUDIT SKILL

Running a successful paid campaigns and auditing is a struggle point for many growth team, this skills fixes that.

It first runs 250+ checks across Google, Meta, YouTube, LinkedIn, TikTok, and Microsoft Ads. Based on the result, invoke's parallel agents per platform that scores accounts with weighted rubrics, flags wasted spend, and generates AI-powered creative variants.

Usage

Audit a Google Ads account → get wasted spend breakdown by campaign, ad group, and keyword in one pass
Detect creative fatigue across Meta campaigns → auto-generate 5 replacement hooks per underperforming ad set
Run a CPA spike diagnosis → trace root cause to bid strategy, audience overlap, or landing page mismatch
Get a CMO-ready performance report with scores, benchmarks, and an action plan - all from the terminal

Prompt

Audit this Google Ads account data [attach export]. Run: wasted spend analysis, quality score breakdown, bid strategy assessment, and creative fatigue check. Score each area 0–100 using 2026 benchmarks. Output a prioritized fix list and generate 3 replacement ad copy variants for the lowest-scoring ad groups.

You can learn more at https://github.com/AgriciDaniel/claude-ads by Daniel.

4. FIRECRAWL WEB INTELLIGENCE SKILL

Not something new, similar to firecrawl-claude-plugin, but help’s content team hours by providing claude code / openclaw/ hermes access to live web.

This allows the agent to scrape any page as clean markdown, take full-page screenshots, extract structured data via JSON schema, and crawl entire doc sites. Handles JS rendering and anti-bot automatically.

Usage

Scrape competitor pricing pages weekly → output structured comparison to a Sheet with zero manual copying
Crawl a competitor's entire blog → extract all topics covered → identify content gaps in your own strategy
Pull product reviews from G2, Capterra, or Reddit → auto-summarize into a customer voice report
Run firecrawl x competitor-analysis [URL] in one command to get a full messaging teardown

Prompt

Use Firecrawl to scrape [competitor URL]. Extract: headline, value prop, pricing tiers, key feature claims, and CTA copy. Then scrape [second competitor URL] and output a side-by-side comparison table with a 'gap for us' column."

You can learn more at https://github.com/firecrawl/firecrawl-claude-plugin by firecrawl.

5. DESIGN SKILL

Design is essential aspect of conversion flow, it all starts there. Having a great design that tells a story of the product leads to better conversions. But ai-generated design’s are slop.

This skills fixes that. It extracts design systems from reference UI images and generates implementation-ready design tokens, component specs, and style guides.

This kills the back-and-forth between designer and agent.

Usage

Feed a screenshot of any UI → get a full design system extracted with colors, spacing, typography, and component patterns.
Generate brand-consistent design tokens for a new product from a single reference image.
Audit existing UI for design consistency issues and get a structured fix list.
Bootstrap a complete design system from scratch using decision-tree prompts before a single line of code.

Prompt

Extract the design system from this UI screenshot [attach image]. Output: color palette with hex values, typography scale, spacing system, component inventory, and border/shadow tokens. Then generate a DESIGN_SYSTEM.md I can reference in all future builds.

This one I use almost every weeks. Learn more at: https://github.com/daymade/claude-code-skills

6. REMOTION VIDEO SKILL

Product launch videos can make or break a product lead generation strategy and launch videos are in high demands so charges very high. With this skills you can build your own one, practically for 0$

This skills is official Remotion guidance baked into a SKILL.md. It gives Claude Code the knowledge to generate React-based programmatic videos without hallucinating the API.

Describe a video, get production code.

Usage

Generate a launch announcement video from your product copy - hook, feature highlights, CTA- fully coded in React
Build a weekly metrics video that pulls live data and renders as an MP4 automatically
Create social-ready short-form video assets (16:9, 9:16) from existing blog content
Render music videos from audio files and lyrics using the acestep-simplemv pattern

Prompt

Using Remotion, build a 30-second product launch video for [product name]. 

Scene 1: bold headline on dark background. 
Scene 2: 3 feature callouts with staggered animations. 
Scene 3: CTA with logo. 

Export at 1080x1920 for Instagram Reels. Follow Remotion best practices throughout."

You can learn more at: https://github.com/mxyhi/ok-skills

7. MARKETING PAGE GENERATION SKILL - FRONTEND

Here is another design skill but tailored to marketing page generations, which surprisingly Gemini 3.1 pro does the best, but lacks the color and aesthetic.

This skills instructs Claude / OpenClaw to skip safe, generic aesthetics and commit to bold design decisions. 277,000+ installs.

Best part? Automatically triggers for any frontend task - landing pages, campaign pages, dashboards.

Usage

I use it to :

Generate a full SaaS landing page with hero, features, social proof, pricing, and CTA sections in one pass.
Build campaign-specific microsites from a brief - product, ICP, and tone - without touching Webflow.
Rebuild an underperforming landing page with a distinct visual identity from a reference URL.
Scaffold a complete marketing site with dark mode, responsive layout, and conversion-optimized structure.

Its a great one and I personally use it to build landing pages for product that leads to high conversion rate. Really a must have!

Prompt

Build a landing page for [product]. Target audience: [ICP]. Tone: [direct/editorial/minimal]. Must include: hero with headline + subhead + CTA, 3-feature section, social proof strip, and pricing table. Choose a bold, distinctive aesthetic - not generic SaaS. Output production-ready HTML/CSS/JS or React + Tailwind.

Give it a try at https://github.com/anthropics/claude-code/tree/main/plugins/frontend-design

8. CONTENT OPS SKILL

Your entire content operations workflow under one skill.

It contains 8 skills that covers: production, audit, repurposing, and distribution. Works as a full editorial pipeline: from brief to published inside Claude Code or OpenClaw.

Simply put, its a swiss army knife for content and growth team as well.

Usage

Run a full content audit: feed your sitemap → agent scores each page by intent, keyword alignment, and conversion potential → outputs prioritized fix list
Repurpose one long-form piece → 5 tweet threads + 3 LinkedIn posts + 1 newsletter section in one command
Generate a 12-week content calendar from your ICP, product pillars, and keyword list
Auto-draft blog posts from raw notes or voice transcripts, following your brand voice file

Prompt

Run a content ops workflow for [topic/URL]. Step 1: audit existing content for gaps vs [keyword cluster]. Step 2: generate 4 new content briefs targeting missed keywords. Step 3: draft post #1 in full using our brand voice [attach]. Step 4: repurpose it into 3 LinkedIn posts and a tweet thread

Get your content pipeline started: https://github.com/superamped/ai-marketing-skills by superramped.

While the content pipeline works, but it may still feel ai-generated, so pair it with last skill and see the organic growth.

9. HUMANIZER SKILL - DE-SLOP YOUR CONTENT

The biggest problem right now with social media is AI generated slop. If you are someone who use ai to generate post and directly post, you need to stop!

Instead use the Humanizer Skill.

It’s a 8-pass editing system that detects and kills AI writing patterns before your content goes live. Strips banned vocabulary (delve, tapestry, foster), breaks structural tells, and forces organization & soul back into the copy.

Usage

Paste any AI-generated blog post → get a rewrite that sounds like a person with opinions wrote it, not a language model.
Run on cold email sequences before sending → eliminates the "this was clearly written by AI" reply-killing patterns.
Match a specific human voice by feeding 2-3 paragraphs of your own writing as a style reference before humanizing.
Use after every content ops skill output. This makes the pair unstoppable for publishing-ready content at scale.

Prompt

Humanize this text: [paste]. First, scan for AI vocabulary, structural tells, and rhythm patterns. Then rewrite in 3 passes: 
- kill AI words, break parallel structures, add human texture and opinion. 
- Run an audit pass 
- list everything still obviously AI then do a final rewrite. 
Match this voice sample: 

[paste 2 paragraphs of your own writing].

Link: https://github.com/jpeggdev/humanize-writing

Bonus Skills - A Toolbox for Marketing Teams

Here are some additional skills with a brief one liner of what they do. Often good to pair with other skills output.

create-viral-content
- Encodes the refinement process that separates forgettable posts from ones that generate discussion and shares.
- Runs AI-tell detection after every draft, then auto-invokes the humanizer for the final pass
awesome-openclaw-skills
- lead-gen-crm + lead-scorer-free
- Two OpenClaw skills that chain into a full outbound pipeline.
- lead-scorer-free scores any domain 0–100 by analyzing its website, DNS, sitemap, and social presence. No database subscription needed.
- lead-gen-crm handles the full CRM pipeline from that point.
cold-outreach
- Uses Alex Hormozi Frameworks for cold-outreach.
- Generates high-converting cold outreach across email, SMS, and LinkedIn DM.
- Uses battle-tested Hormozi offer frameworks baked directly into the skill.
- Not generic copy - structured around irresistible offer construction.
marketing-psychology
- Applies cognitive biases, mental models, and behavioral science frameworks directly to marketing copy, CRO, and funnel design.
- Cialdini, Kahneman, and Ariely strategy and research baked into a skill.

That marks the end of this article. Here are some hidden insights that I discovered while using these.

Final Thoughts

Use chain of skills to get the output that makes the product position unique and well framed.

Simple example:

Use content ops skill to draft the long-form piece
Pass it to psychological persuasion skill rewrites every headline and CTA against 12 cognitive bias principles
Humanizer strips every AI tell across 8 passes → what's left sounds like your sharpest human writer, not a model hitting word count
Cold Outreach pulls the strongest pain observations and proof points from that copy → lands in your ICP's inbox as a Hormozi-framed 5-email sequence and 3 LinkedIn DMs.

The hard part isn't the skills - it's orchestrating the flow between them. That's where Composio comes handy.

It handles the auth layer, manages tool calls across every integration, and keeps context intact as output moves from one skill to the next. No glue code. No dropped state. No manual handoffs.

Install it once. Let it run the pipeline while you focus on what AI still can't do - knowing your customer well enough to say something worth reading.

How to Automate Your Slack Workspace with OpenClaw and Composio 🚀

Shrijal Acharya — Thu, 16 Apr 2026 15:19:55 +0000

Your team already lives in Slack. Code reviews, project updates and what not, it all happens there.

But the moment you need to file a GitHub issue, check a Linear ticket, or send a follow-up email, you leave Slack, do the thing, and come back. That context switch adds up.

What if your Slack workspace had an assistant that could do all of that for you, right in the thread. That too an isolated OpenClaw instance per user with admin control? 🤯

In this article, you'll learn how to automate an entire Slack team workspace that connects to your tools, takes actions, without you ever leaving Slack.

What's Covered

To quickly summarize what we’ll cover in this blog post, here’s what we’ll go through:

The idea behind building a Slack bot around OpenClaw.
How Composio lets each user connect their own tools.
How OpenClaw powers replies and tool usage.

These are a few things you'll understand, but there's so many others you'll learn along the way.

So, if you want to build a Slack-first (though not limited to) AI with personal tool access for each user, this will give you a solid starting point.

What we're building

We're building a Slack bot that brings OpenClaw into Slack.

💁 Not necessarily only for Slack, you can use pretty much the same setup for something like Discord with their SDK or your custom app. The idea remains the same.

Overall the idea is to use OpenClaw and give every user in a workspace their own single instance of it which powers the AI assistant.

That way, things are isolated per user and the admin can control/limit the toolkits (GitHub, Linear, etc.) the users get access to.

Each user can connect their own tools with Composio, so the bot can chat, and take actions using the tools they’ve authorized.

Here's a quick architecture.

Why Slack and how to create a Slack App?

No big reason to choose Slack, only because it supports slash commands, and it's mostly where people already work.

For this, we first need to have a Slack app, if you don't already have one, follow the quickstart guide to create one.

Once your app is created, enable Socket Mode so the bot can receive events without exposing a public webhook URL.

Then add at least these Bot Token Scopes:

app_mentions:read
chat:write
commands
im:history
im:read
users:read

Subscribe to these Bot Events:

app_mention
message.im

And create these Slash commands:

/connect: Use it something like /connect <toolkit>
/connections: User lists active connections
/help: Shows usage summary
/assign: Admin assigns an OpenClaw instance to a user
/add-mcp-config: Admin registers an MCP Config from platform.composio.dev
/add-auth-config: Admin links a toolkit to its Composio auth config
/list-mcp-configs: Admin lists all registered MCP Configs

Finally copy these values to your .env file, which you can find in the app settings:

SLACK_BOT_TOKEN=xoxb-...
SLACK_APP_TOKEN=xapp-...
SLACK_SIGNING_SECRET=...

Your SLACK_BOT_TOKEN is the bot token itself, SLACK_APP_TOKEN is the Socket Mode app level token and SLACK_SIGNING_SECRET is used by Slack to verify requests.

How to Set Up the Project

It's fairly simple to get this project up and running. Follow these steps:

git clone https://github.com/shricodev/saas-openclaw-slackbot.git
cd saas-openclaw-slackbot

Next, you install the dependencies:

npm install

Then set up the environment variables and run the development server:

# Slack
SLACK_BOT_TOKEN=xoxb-...
SLACK_APP_TOKEN=xapp-...
SLACK_SIGNING_SECRET=...

# Database
DATABASE_URL=...

# Composio api key (ak...) from https://platform.composio.dev
COMPOSIO_API_KEY="ak_..."

To get the Composio API key:

Log in at platform.composio.dev
Copy your API key (ak_..) from the Composio dashboard settings, then set it:

Configure Composio Dedicated MCP Server

In this section, we'll go through the process of creating a dedicated MCP server in Composio for each user.

First, head over to platform.composio.dev
Under the MCP Configs tab, create a Dedicated MCP Server. This lets you create MCP servers with specific apps and tools, which is exactly what we want.

Select all the toolkits you plan to assign for the user and create the MCP server.

For the External User ID, use the user's Slack user ID. To get someone's Slack user ID, head over to their profile, click the three dots, and select Copy Member ID.

Use that as the External User ID.

Keep note of the MCP config name and MCP config ID. You will need both when configuring the bot in Slack.

Upon successful creation, you'll find the URL:

You can copy this URL directly and add it to the OpenClaw config, which we’ll cover later in the Configure OpenClaw with Composio section. Alternatively, the bot can fetch it for you after you run the /assign slash command, which we’ll configure later.

You will also need the auth config ID tied to the tools you selected. In the MCP server, head over to the Manage Config tab and click Manage Auth Config. The auth config ID is listed on that page.

Keep note of this as well. You will need it when running /add-auth-config in Slack.

Core Components in the Application

We're not going to code everything from scratch as that'd be too long and impractical. Let's go over some of the core components in the project.

Before we start with the project core components, here's the project tech stack:

Slack Bolt - Official Slack bot framework. We use it with Socket Mode, which connects to Slack over a WebSocket without needing a public HTTP endpoint.
OpenClaw - The agent layer. Exposes an OpenAI-compatible API but acts as a full agentic gateway that plans, calls tools, and reasons over results.
Composio - The core of the project. Manages OAuth connections to external apps like GitHub, Linear, and Gmail, and exposes them to the agent via MCP.
TypeScript - Obvious choice over JavaScript as we get type safe code.
PostgreSQL + Prisma - Handles user records, connection status, and per-thread conversation history.

Bootstrapping the Bot

This is where everything starts. We initialize the Slack Bolt app with Socket Mode, register all handlers, and start the server.

// 👇 app.ts

const app = new App({
  token: process.env.SLACK_BOT_TOKEN,
  appToken: process.env.SLACK_APP_TOKEN,
  signingSecret: process.env.SLACK_SIGNING_SECRET,
  socketMode: true,
});

registerMessageHandlers(app);
registerCommandHandlers(app);

(async () => {
  const port = Number(process.env.PORT) || 3000;
  await app.start(port);
  console.log(`Bot is running on port ${port} (socket mode)`);
})();

Instead of exposing a public HTTP endpoint for Slack to POST events to, Socket Mode opens a WebSocket connection. This means you can run the bot anywhere could be your local machine, a private server without a public URL.

If you've worked with bots before, this should be pretty straight-forward to understand. 👀

Handling User Messages

This is the brain of the bot. It handles both direct messages and @mentions in channels.

// 👇 message.handler.ts

async function handleUserMessage({
  message,
  client,
  text,
  channelId,
  threadTs,
}) {
  await saveMessage(
    slackUserId,
    slackTeamId,
    channelId,
    threadTs,
    "user",
    text,
  );

  const history = await getThreadHistory(
    slackUserId,
    slackTeamId,
    channelId,
    threadTs,
  );
  const priorHistory = history.slice(0, -1);

  const thinkingMsg = await client.chat.postMessage({
    channel: channelId,
    thread_ts: threadTs,
    text: "_Thinking..._",
  });

  const response = await generateResponse(
    openclawConfig.gatewayUrl,
    openclawConfig.gatewayToken,
    text,
    priorHistory,
    sessionKey,
  );

  await saveMessage(
    slackUserId,
    slackTeamId,
    channelId,
    threadTs,
    "assistant",
    response.content,
  );

  await client.chat.update({
    channel: channelId,
    ts: thinkingMsg.ts,
    text: response.content,
  });
}

There's a few things you might notice right up:

First, we store the user's message to the database before sending it to OpenClaw. But why? This way if the request fails, the history isn't broken. Similar to storing chat history in localhost when creating web chat applications.

I do not know if there’s a better way to handle this, but right now we just show a Thinking... message while the AI is generating the full response, and then replace it once the final output is ready.

A little hacky, maybe, but it gets the job done. There are probably better ways to handle this, like streaming the response, but for now the old-school approach works. 😋

Slash Commands

The bot exposes seven slash commands split into two groups: user-facing (/connect, /connections, /help) and admin-only (/assign, /add-mcp-config, /add-auth-config, /list-mcp-configs).

/connect

/connect <toolkit> starts an OAuth flow for a tool like GitHub or Gmail. But unlike the previous version where any user could connect any toolkit, now the bot checks three things before starting a connection:

Does this user have an MCP Config assigned?
Is the requested toolkit in that config?
Is there an auth config registered for this toolkit?

// 👇 command.handler.ts

app.command("/connect", async ({ command, ack, respond }) => {
  await ack();
  const toolkitSlug = command.text.trim().toLowerCase();
  const apiKey = getComposioApiKey();

  const assignment = await db.mcpConfigAssignment.findUnique({
    where: {
      slackUserId_slackTeamId: {
        slackUserId: command.user_id,
        slackTeamId: command.team_id,
      },
    },
    include: { mcpConfig: true },
  });

  if (!assignment) {
    await respond({
      response_type: "ephemeral",
      text: "You have not been assigned an MCP Config. Ask your admin to run `/assign`.",
    });
    return;
  }

  if (!assignment.mcpConfig.toolkitSlugs.includes(toolkitSlug)) {
    await respond({
      response_type: "ephemeral",
      text:
        "This toolkit is not available in your assigned config. " +
        "Your admin controls which toolkits you can access.",
    });
    return;
  }

  const toolkitAuth = await db.mcpToolkitAuth.findUnique({
    where: {
      slackTeamId_toolkitSlug: {
        slackTeamId: command.team_id,
        toolkitSlug,
      },
    },
  });

  // check if already connected
  const connectedToolkits = await getConnectedToolkits(apiKey, command.user_id);
  if (connectedToolkits.includes(toolkitSlug)) {
    await respond({
      response_type: "ephemeral",
      text: `You're already connected to *${toolkitSlug}*.`,
    });
    return;
  }

  const redirectUrl = await initiateConnection(
    apiKey,
    toolkitAuth.authConfigId,
    command.user_id,
  );

  await respond({
    response_type: "ephemeral",
    text: `Click here to connect *${toolkitSlug}*: ${redirectUrl}`,
  });
});

The response is only visible to the user who ran the command. That's intentional as OAuth URLs are personal and shouldn't be visible to the whole channel.

/assign

/assign is admin-only and lets admins assign a specific OpenClaw gateway to a user. It opens a Slack modal to collect the gateway URL, token and MCP config server ID.

// 👇 command.service.ts

app.command("/assign", async ({ command, ack, respond, client }) => {
  await ack();

  const userInfo = await client.users.info({ user: command.user_id });
  const isAdmin = userInfo.user?.is_admin || userInfo.user?.is_owner;

  if (!isAdmin) {
    await respond({
      response_type: "ephemeral",
      text: "Only workspace admins can assign OpenClaw instances.",
    });
    return;
  }

  await client.views.open({
    trigger_id: command.trigger_id,
    view: assignInstanceModal, // includes gateway URL, token, and MCP Config ID fields
  });
});

The user's MCP URL looks something like this: https://backend.composio.dev/v3/mcp/aaa-111/mcp?user_id=<slack_user_id>

It's the key because it's what connects the user's OpenClaw instance to the toolkits the admin selected for them.

/add-mcp-config and /add-auth-config

These two admin commands register the Composio resources in the bot's database. Both open modals.

/add-mcp-config registers an MCP Config by name and server ID:

// On modal submit:
await db.mcpConfig.create({
  data: {
    slackTeamId: teamId,
    composioServerId, // the UUID from the MCP URL
    name, // e.g. "Engineering"
    toolkitSlugs, // e.g. ["github", "linear"]
  },
});

/add-auth-config links a toolkit slug to its Composio auth config ID. This is what /connect uses to know which auth config to pass when initiating a connection:

// On modal submit:
await db.mcpToolkitAuth.upsert({
  where: {
    slackTeamId_toolkitSlug: { slackTeamId: teamId, toolkitSlug },
  },
  create: { slackTeamId: teamId, toolkitSlug, authConfigId },
  update: { authConfigId },
});

/list-mcp-configs

A simple admin command that lists all registered MCP Configs for the workspace:

"Engineering" - server: - toolkits: github, linear
"Sales" - server: - toolkits: gmail, notion

Sending Requests to OpenClaw

Up until this point we were working on the Slack side and a bit of Composio setup, but how do we actually send these messages to OpenClaw?

OpenClaw exposes an OpenAI-compatible /v1/chat/completions endpoint. Our service code wraps that with a proper system prompt, conversation history, and error handling. Nothing super unknown to most of you.

// 👇 openclaw.service.ts

export async function generateResponse(
  gatewayUrl: string,
  gatewayToken: string,
  userMessage: string,
  history: Array<{ role: string; content: string }>,
  sessionKey?: string,
): Promise<OpenClawResponse> {
  const systemPrompt: ChatMessage = {
    role: "system",
    content:
      "You are a helpful assistant in a Slack workspace. " +
      "You have access to the user's connected tools (GitHub, Linear, Gmail, etc.) through Composio. " +
      "The user's tools are already connected. Do not ask them to connect or authenticate. " +
      "Use the available Composio tools directly to answer questions. " +
      "Be concise. Format responses for Slack (use mrkdwn syntax).",
  };

  const messages: ChatMessage[] = [
    systemPrompt,
    ...history.map((m) => ({
      role: (m.role === "user" ? "user" : "assistant") as "user" | "assistant",
      content: m.content,
    })),
    { role: "user", content: userMessage },
  ];

  return sendToOpenClaw(gatewayUrl, gatewayToken, messages, sessionKey);
}

We also wrap the raw fetch in a custom OpenClawError class with error codes for timeouts, auth failures, and gateway errors. Preferred thing you do in a real-world codebase.

💡 Prefer something built-in like fetch over third-party tool like axios. Especially now after the recent compromise of axios which is used by hundreds and thousands of applications.

Connecting tools with Composio

You might be familiar working with Composio over the SDK @composio/core.

But with Composio, you can also directly talk to it's REST API. We now talk to the Composio REST API on backend.composio.dev using an API key from platform.composio.dev.

There are only three functions in the service, and each one does exactly what the name suggests 🤌

Check what a user has connected:

// 👇 composio.service.ts

export async function getConnectedToolkits(
  apiKey: string,
  slackUserId: string,
): Promise<string[]> {
  const url = `${COMPOSIO_API_BASE}/connected_accounts?user_id=${encodeURIComponent(slackUserId)}`;
  const res = await fetch(url, {
    method: "GET",
    headers: { "x-api-key": apiKey },
    signal: AbortSignal.timeout(30_000),
  });

  const data = await res.json();
  return data.items
    .filter((account) => account.status === "ACTIVE")
    .map((account) => account.toolkit.slug);
}

Initiate a new connection:

// 👇 composio.service.ts

export async function initiateConnection(
  apiKey: string,
  authConfigId: string,
  slackUserId: string,
): Promise<string> {
  const url = `${COMPOSIO_API_BASE}/connected_accounts`;
  const res = await fetch(url, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-key": apiKey,
    },
    body: JSON.stringify({
      auth_config: { id: authConfigId },
      connection: { user_id: slackUserId },
    }),
    signal: AbortSignal.timeout(30_000),
  });

  const data = await res.json();
  return data.redirect_url;
}

Build the per-user MCP URL:

// 👇 composio.service.ts

export function getMcpUrl(
  composioServerId: string,
  slackUserId: string,
): string {
  return `https://backend.composio.dev/v3/mcp/${composioServerId}/mcp?user_id=${encodeURIComponent(slackUserId)}`;
}

This last one is the most important. There's no API call, it's pure URL construction. But this URL is what ties everything together: the composioServerId controls which toolkits are available, and
the user_id scopes which credentials are used. When /assign runs, it computes this URL and shows it to the admin so they can configure it in the user's OpenClaw instance.

Persisting Users and Conversation

Every Slack user that messages the bot gets a record in our database keyed on (slackUserId, slackTeamId) pair. This is a safety net, as the same Slack user ID could theoretically exist across different workspaces.

// 👇 slack-user.service.ts

export async function resolveSlackUser(
  slackUserId: string,
  slackTeamId: string,
) {
  const existing = await db.slackUser.findUnique({
    where: { slackUserId_slackTeamId: { slackUserId, slackTeamId } },
  });

  if (existing) return existing;

  return db.slackUser.create({
    data: {
      slackUserId,
      slackTeamId,
      composioEntityId: `slack_${slackTeamId}_${slackUserId}`,
    },
  });
}

Conversation history is stored per-thread using Slack's thread_ts (the timestamp of the first message in a thread) as the thread id. When the bot receives a message, it fetches the full thread history and passes it to OpenClaw, giving it the memory for the duration of that thread.

Configuration Setup

The bot requires per-user OpenClaw instances assigned by an admin. If a user hasn't been assigned an instance, they can't use any features. /connect, /connections and chat all require an assignment first.

Why not use shared instance?

By shared instance, I mean all the users share the same OpenClaw instance. So why not use it that way? That's how server is supposed to work?

There's a few reasons:

By default, OpenClaw is not designed to support multiple users connecting to the same gateway concurrently. In practice, which is likely to be the case for our use case.

This is already the main reason.

Also, in general, letting multiple users use the same instance with multiple connected accounts is not safe. A prompt injection by one user could access or destroy another user's data.

Even if there's safety measure (which I'm not aware of). Things could always go wrong. So better safe than sorry.

// 👇 lib/config.ts

export async function getUserOpenClawConfig(
  slackUserId: string,
  slackTeamId: string,
): Promise<OpenClawConfig> {
  const user = await db.slackUser.findUnique({
    where: { slackUserId_slackTeamId: { slackUserId, slackTeamId } },
    select: { openclawGatewayUrl: true, gatewayToken: true },
  });

  if (user?.openclawGatewayUrl && user?.gatewayToken) {
    return {
      gatewayUrl: user.openclawGatewayUrl,
      gatewayToken: user.gatewayToken,
    };
  }

  throw new Error(
    "No OpenClaw instance assigned. Ask your admin to run /assign.",
  );
}

No assignment, no access. The admin runs /assign for each user, providing their OpenClaw gateway URL, token, and MCP Config. Until that happens, the bot won't respond to that user.

Configure OpenClaw with Composio

Great, now the code part is done. There's one thing that's still left.

Now, the actual reason to build the bot i.e. to get tools access is not configured within OpenClaw which we do with Composio. It's the most easiest.

There's multiple ways to configure OpenClaw with Composio. There's standard ways you can find here.

But, we won't follow the standard way, as by default it uses consumer key, which is a way it's designed by default.

But we won't work with consumer key, we directly work with the MCP URL.

Go ahead and modify the OpenClaw config file which lives in the ~/.openclaw/openclaw.json with the following:

// rest of the config...

  "plugins": {
    "allow": [ "composio", "...rest"],
    "entries": {
      "telegram": {
        "enabled": true
      },
      "composio": {
        "enabled": true,
        "config": {
          "enabled": true,
          // put the MCP URL you receive after running /assign for a user.
          "mcpUrl": "..."
        }
      }
    },
  }

This sets up one instance for one user. But how do you about configuring multiple instances for multiple users?

How do you run it for multiple users?

This only configures one user in the entire workspace. But what about the rest?

There are a few ways:

1. Separate machine or VMs:

Each user's OpenClaw runs on a different machine. Each has its own ~/.openclaw/openclaw.json with its own MCP URL. This is the cleanest but most expensive.

2. Use named OpenClaw profiles:

OpenClaw ships with a --profile flag out of the box:

  --profile <name>     Use a named profile (isolates OPENCLAW_STATE_DIR/OPENCLAW_CONFIG_PATH under ~/.openclaw-<name>)

You can use a different profile per user. If you name each profile after the user, you get an isolated config for each one on the same machine. Most efficient.

For example:

openclaw --profile bob
openclaw --profile shrijal

3. Separate OS users on one machine:

Somewhat impractical. You'd run one OpenClaw instance per OS user, which means creating a separate system account for each person. Possible, but not a great approach.

There could be hundreds of other ways to do it. These are just the ones I could think of. Do your own research, and you’ll probably find others.

Slack Workflow

Run these commands in order as an admin before any user can start chatting.

/add-mcp-config

/add-auth-config

Assign each user their OpenClaw instance and MCP Config:

/assign

This gives you the user's scoped MCP URL. Configure it in their OpenClaw instance.

Once assigned, users run:

/connect <toolkit>

That's it. After connecting, they can DM the bot or @mention it in a channel.

Bot in Action

Here's a quick demo of the bot in action:

Conclusion

So yeah, that's the whole idea.

A Slack bot on top of OpenClaw, with Composio handling user tool connections, ends up being a really solid setup.

At this point, you’ve got a good idea of how this bot works with Slack, OpenClaw, and Composio.

We covered the main flow, how users connect their tools, how everything comes together inside Slack, and why assigning one OpenClaw instance per user helps keep things isolated.

It keeps the setup clean and gives you a bot that’s actually useful.

That's all for this one.

You can find the entire source code here: shricodev/saas-openclaw-slackbot

Shrijal AcharyaFollow

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