MCP vs CLI, Skills, RAG and A2A: 5 tools mapped

MCP vs CLI is the comparison people reach for first, but it's only one line on a wider map: MCP, Skills, CLI, RAG, and A2A are five ways to make an AI assistant genuinely useful, each built for a different job. MCP servers extend an assistant much the way apps extend a phone; the other four take different architectural routes to the same goal. This article maps all five in plain English and shows how to pick - by naming the job, not the technology.

• MCP connects one assistant to live tools and data through a standardized, discoverable interface - best when the model must act on external systems or a non-developer runs the workflow.
• CLI lets an agent generate and run shell commands - leaner on tokens and ideal for a developer's fast local loop where the command is already known.
• Skills package a repeatable procedure (instructions plus optional scripts) so a task is done the same way every time.
• RAG retrieves passages from your documents to ground answers - about knowing, not doing.
• A2A connects autonomous agents to each other; it sits above MCP, not against it.
• Most real setups combine several. The right choice follows the job to be done, and every option needs least-privilege security.

The five approaches at a glance: MCP, Skills, CLI, RAG and A2A

Think of an AI assistant like a phone straight out of the box. It can do a lot on its own, but the useful part is what you add: apps that let it book travel, read your calendar, or query a database. MCP servers are the closest analogue to those apps; Skills, CLIs, RAG and A2A also extend what an assistant can do, but through architecturally different mechanisms. They overlap, they compete in places, and plenty of real setups use several at once. This section is a map, not a manual: one or two sentences each, so you can tell them apart before the later sections dig into trade-offs.

A quick note on vocabulary, because these terms come up throughout. A protocol is an agreed set of rules for how two programs talk to each other. A tool is a single action a model can call (for example, "create an invoice"). A resource is a piece of data a model can read (for example, a document or a database record). A server is the program that exposes those tools and resources over a protocol.

• MCP (Model Context Protocol) - an open protocol released by Anthropic in November 2024 that lets an assistant connect to external tools, data and servers through one standardized interface, so any compatible AI agent can discover and call them.
• Skills - packaged, reusable instructions (and sometimes small scripts) that teach an assistant how to carry out a specific procedure the same way every time, without wiring up a live external system.
• CLI (command-line interface) - a text-based program run from the terminal; the model invokes it as a command, passes arguments, and reads the text it prints back, with no schema layer in between.
• RAG (retrieval-augmented generation) - a technique that searches your own documents for relevant passages and feeds them into the prompt, so the model answers from your knowledge rather than only its training data.
• A2A (agent-to-agent) - a protocol for agents to talk to each other and delegate work, rather than for a single agent to reach a tool.

The sections that follow compare them head-to-head, starting with the one people argue about most - MCP versus CLI.

MCP vs CLI: schema selection vs generated commands

Both MCP and a CLI let an AI assistant take actions in the outside world, but they do it in very different ways. Understanding that difference is the heart of the MCP vs CLI question, and it explains most of the trade-offs you will read about.

MCP works by exposing a tool schema: a structured, machine-readable description of each available tool, its parameters, and their types. The model reads those schemas and selects the right tool with the right arguments. This is the same mechanism behind "function calling," where a model returns a structured call rather than free text - so in practice, MCP vs function calling is less a rivalry than MCP being a standardized transport for it.

A CLI works the other way around. The model generates shell commands as plain text, the assistant runs them as a subprocess, and reads whatever comes back on standard output. There is no schema - the model has to know, or infer, what commands exist and how to phrase them.

Side-by-side comparison

The table below summarizes the core differences. Benchmark figures come from a Scalekit report published 2026-03-11 that benchmarked GitHub operations on a single model; treat them as one vendor's test suite rather than a universal law, and re-check the primary source before quoting them.

What the comparison really tells you

One line captures it: MCP tells the model exactly what it can do, while a CLI lets the model figure out what to do and improve through feedback. Neither is universally better. The reported token gap and failure rates make CLIs attractive when a developer is driving a fast local loop and knows the exact command. MCP earns its overhead when the model needs to discover capabilities on its own, when inputs must be validated against a schema, and - importantly - when the person using it isn't at a terminal at all.

That last point is the practical dividing line for most readers of this blog. A CLI assumes a developer's machine and shell. A hosted MCP server assumes only that you have an AI assistant open. If your goal is to let a non-technical teammate connect an MCP to Claude or ChatGPT and run a workflow from inside the assistant, the schema overhead is a price worth paying for access they could not otherwise have.

Token efficiency and the context window

To use a tool, an AI model has to know it exists. With MCP - the Model Context Protocol - the client asks a server for its list of tools and reads back a schema for each: the tool name, a description, and the shape of its inputs and outputs. Depending on the client, much of that text is placed into the model's context window (the fixed budget of tokens the model can "see" at once, where a token is roughly a chunk of a word). Since the 2026-07-28 revision of the MCP specification, the protocol core is stateless - the old initialization handshake and session IDs are gone - but the schemas a client does load still occupy the window before the model does any actual work.

That up-front step is where the overhead comes from. Every tool definition the client sends loads into the context window as tokens, so the more servers and tools you connect, the more of your budget is spent describing capabilities the model may never use in that session. Connect a handful of rich servers and a noticeable slice of the window can be gone before the first user question is answered.

Why a CLI reads differently

A CLI spends tokens the other way around. The assistant doesn't preload a catalog of every command and flag. It runs a command, waits for the process to finish, and reads whatever text comes back on standard output. Output is consumed on demand: the model pays tokens for the result of the specific command it chose to run, not for a full description of everything it could have run. Discovery, when it's needed at all, is itself just another command (for example, asking a tool for its help text).

This is the core of the token efficiency argument for CLIs. Fewer definitions sitting in context up front means lower baseline usage per turn, which is why CLIs tend to look leaner in tight, local developer loops where the model already knows roughly which tool it wants.

The honest trade-offs

Lower token usage is not the same as "better." The mechanics cut both ways:

• Discovery has value. Preloaded schemas are how a model knows what's available and picks the right tool without guessing at command names. That structure is precisely what you're paying tokens for, and it helps when the model does not already know the toolset.
• CLI output can balloon too. Reading on demand keeps the baseline low, but a verbose command can dump a large amount of text into the context window in one shot. On-demand reading controls when you spend tokens, not always how many.
• You can trim MCP overhead. Connecting only the servers you need, keeping tool descriptions tight, and disabling unused tools all reduce the up-front cost - and modern clients can cache the tool list instead of re-fetching the catalog each time, an option the current spec supports explicitly.

Third-party benchmarks have tried to put figures on this gap. In its GitHub benchmark, Scalekit reported MCP consuming on the order of 4-32× more tokens than equivalent CLI calls, attributing the gap to schema overhead; the same write-up reported 18 of 25 MCP runs succeeding against 25 of 25 for the CLI, every failure a connection timeout. Treat numbers like these as one vendor's test conditions rather than a universal law - results depend heavily on which tools are loaded, how their schemas are written, and the task itself. The reliable takeaway is the mechanism, not the multiplier: MCP pays for discoverable structure up front, CLIs pay for results as they read them, and the right choice depends on whether that structure earns its place in your context window.

Inner loop vs outer loop: when to pick CLI or MCP

A CLI and an MCP server both give an AI agent a way to take action. The most useful way to choose between them is to ask where the work happens: in the tight, fast cycle of writing and testing code (the inner loop), or in the broader flow of automation that spans apps, teammates and hosted systems (the outer loop).

The inner loop favors the CLI

The inner loop is the minute-to-minute rhythm of coding: edit, run, read output, adjust. Here the agent is working on a developer's own machine, and speed and token efficiency matter more than discoverability. A CLI fits this naturally. The assistant spawns a subprocess, passes arguments, and reads the text that comes back - no schema catalog to load into the model's context first.

This is also where decades of Unix habits pay off. Command-line tools compose. You can pipe the output of one into the input of another, chain them into a pipeline, and let the coding agent iterate on that pipeline the same way a human would. When the model already knows which tool it wants - running tests, checking git status, opening a pull request - the CLI lets it just do that and learn from the feedback.

The outer loop favors MCP

The outer loop is everything that has to work reliably beyond one developer's terminal: stable cross-app workflows, non-developer teammates, customer-facing automation, and processes that need consistent auth and audit trails. MCP suits this because it exposes tools and data through a standardized, discoverable protocol. An agent - or a person using Claude, ChatGPT or Cursor - can find the available tools, see structured descriptions of what each one does, and call them without anyone installing a binary or learning command syntax.

MCP earns its overhead when:

• the same workflow needs to run from more than one client or app;
• the people running it are not developers and won't touch a terminal;
• the tool touches customer data or compliance-sensitive systems, where structured access and clear scopes matter;
• the workflow is hosted and shared rather than local and personal.

Browser automation as a concrete example

Browser control shows both patterns clearly. If you're a developer scripting a one-off scrape or debugging a page, a browser CLI or a headless-browser command runs inside your inner loop, feeds text straight back to the coding agent, and stays cheap on tokens. If instead you want "check the vendor portal every morning and file the results," that's outer-loop browser automation: a hosted MCP server can expose that as a durable tool that a non-technical teammate triggers from their assistant, with auth handled centrally rather than living in someone's shell.

The 2026 debate

This distinction became a live argument among coding-agent users through 2026. The Scalekit numbers above - the 4-32× token gap and the 25 of 25 vs 18 of 25 reliability split - became the debate's most-shared exhibit; treat them as point-in-time results and re-check against your own workflows.

The emerging consensus is not that one wins. It's that most teams use both: CLI for developer workflows where token efficiency and speed dominate, MCP for cross-app, customer-facing, and compliance-sensitive automation where discoverability and stable access matter more. If you can already name the command, reach for the CLI. If the agent needs to discover and select the right tool for the situation - or a non-developer needs to run it - reach for MCP.

MCP vs Skills: live tools vs repeatable procedure

So far we have stayed inside "taking action." Skills sit in a different place: they're about repeating a procedure, not reaching a system. MCP and Skills solve different halves of the same problem - getting an assistant to do useful work reliably. The difference between MCP and Skills comes down to live access versus packaged know-how.

MCP gives an assistant live tool access to an external system - a way to query data or take action through a defined interface at the moment it's needed. When Claude, ChatGPT or Cursor calls an MCP tool, it's hitting a running server that reads or writes to a real system (a database, a ticketing app, a payments API) and hands back a structured result.

Agent Skills, which Anthropic introduced for Claude in late 2025, are something else. A Skill is a folder of reusable instructions and supporting files - a description of a procedure, plus any scripts, templates or reference documents the assistant should load when the task matches. It teaches the assistant how to do a repeatable job the way you want it done. A Skill doesn't, by itself, open a connection to an outside system; it shapes the model's behavior and can bundle files and code the model runs.

The core difference between MCP and Skills

Put simply:

• MCP answers "what can I reach?" - live tools and data from external systems, discovered and called at runtime.
• Skills answer "how should I do this?" - a repeatable procedure, plus instructions and files, that the assistant pulls in when relevant.

A useful way to hold the Claude Skills vs MCP distinction in your head: MCP is a connection, a Skill is a playbook. They sit at different layers, which is why the "MCP vs Skills" framing is a bit misleading - they're more often complementary than competing.

When you'd combine them

The strongest pattern is a Skill that orchestrates MCP tools. The Skill supplies the procedure - the order of steps, the formatting rules, the edge cases to check - and the MCP server supplies the live access those steps depend on.

For example, imagine a monthly reporting job:

1. A Skill defines the report: which metrics to pull, how to structure sections, what tone to use, and a template document to fill in.
2. The Skill's procedure calls MCP tools to query the live numbers - one tool to fetch revenue from a billing system, another to read support-ticket counts.
3. The assistant assembles the result using the Skill's template, populated with fresh data from the MCP calls.

Neither piece does the whole job alone. Without the Skill, the assistant improvises the format each time; without MCP, it has no live data to put in it.

How to choose

• Reach for a Skill when the task is a procedure you repeat and want done consistently, and the knowledge or files can be packaged ahead of time.
• Reach for MCP when the task needs current data or must take an action in an external system that only the system itself can perform.
• Reach for both when a repeatable procedure depends on live data or actions - the common case in real workflows.

One note on scope, since Skills and MCP have different footprints: a Skill can carry scripts that run in the assistant's environment, so treat a Skill from an untrusted source with the same caution you'd give any code. An MCP server, by contrast, sees whatever the tools it exposes are scoped to reach - a point covered in more detail in the security section below.

MCP vs RAG: retrieving knowledge vs taking action

If Skills are about method, RAG is about knowledge. RAG stands for retrieval-augmented generation: before the model answers, a search step pulls the most relevant passages from your own documents - a knowledge base, a set of PDFs, a wiki - and pastes them into the prompt so the answer is grounded in your material instead of the model's memory. The comparison people frame as "mcp vs rag" is a bit of a category error, because the two solve different problems. RAG is about knowing; MCP is about doing.

MCP lets an AI assistant call tools and read data from live systems through a consistent interface. A tool is a named action the model can invoke - create_ticket, get_order_status, refund_payment - and the server decides what actually happens when it runs. That means MCP can read from systems and change them, while a classic RAG pipeline only retrieves text to inform an answer.

Where each one fits

• Reach for RAG when the job is to answer questions from a body of text you control, and the freshness requirements are modest: "What does our refund policy say?", "Summarize the design decisions in these specs." The output is grounded prose, not an action.
• Reach for MCP when the assistant needs current state or needs to make something happen: check today's inventory, open a pull request, send an invoice. These are calls against live systems, and the result changes from one minute to the next.

They are complementary, not competing

The cleanest way to see the relationship is this: an MCP server can be the interface to a retrieval backend. Instead of wiring your vector search into one application, you expose it as an MCP tool - say search_docs(query) - and any connected assistant can call it to fetch grounded context on demand. Now retrieval becomes one more thing the agent can choose to do, alongside reading a ticket or querying a database, all through the same protocol.

MCP also has a second primitive that overlaps with RAG's territory: resources. Where tools are actions the model invokes, resources are read-only pieces of context - files, records, documents - that a server makes available for the assistant to pull in. A server might expose a knowledge base as resources the client can attach to the conversation, or wrap the same content behind a search tool so the model retrieves only the passages it needs. Either way, the retrieved text still ends up as context in the prompt, exactly as it would with a standalone RAG setup.

So the honest answer to "MCP vs RAG" is that you rarely pick one over the other. RAG decides what the model knows; MCP decides what it can touch. Put retrieval behind an MCP server and you get the best of both - grounded context and the ability to take action, without maintaining two separate integration paths.

MCP vs A2A: connecting to tools vs connecting agents to each other

MCP and A2A are often mentioned in the same breath, which makes them sound like rivals. They are not. They solve different problems and sit at different layers of an agent architecture. The simplest way to hold the two in your head: MCP connects one agent to tools and data; A2A connects agents to each other.

A2A (Agent2Agent) is a protocol for communication between autonomous agents - a standardized way for one agent to hand a task to another, share context, and receive a result back. It was announced by Google in April 2025 and has since been donated to the Linux Foundation, which puts its governance in a neutral, open home. Where MCP asks "what tools can this agent reach?", A2A asks "how do two agents that were built separately talk to each other?"

Where each one sits in the architecture

Picture a layered stack. At the bottom sit your data and systems - databases, SaaS APIs, file stores. MCP is the layer that lets a single agent call those systems safely: it defines the tools, their inputs and outputs, and the auth around them.

A2A sits one layer up. It assumes you already have capable agents and gives them a shared language to delegate work. A "planner" agent might break a request into parts and ask a "billing" agent and a "scheduling" agent to each handle a piece. Each of those agents may, in turn, use MCP servers to actually get things done. So in a multi-agent system, the two protocols usually run together rather than competing:

• A2A handles agent-to-agent coordination: task delegation, status updates, passing results between independently built agents.
• MCP handles agent-to-tool access: giving each agent the concrete actions and data it needs to do its part.

A2A vs MCP: a quick comparison

Why most teams need MCP long before A2A

The framing "MCP vs A2A" or "MCP vs agents" implies you have to choose, but for most teams the order is clear. A2A only pays off once you have several autonomous agents that genuinely need to hand work to one another - and building even one reliable agent means first giving it good, well-scoped tools. That is exactly what MCP provides.

In practice, you will connect an agent to a handful of MCP servers, watch how it uses them, and refine the tools long before a multi-agent topology is worth the added complexity. Get the tool layer solid with MCP first; reach for A2A when the problem is genuinely one of agents talking to agents, not agents talking to systems.

A decision table and three real scenarios

By now you have seen the trade-offs one comparison at a time. This section pulls them together. The question to ask is never "which technology is best?" but "what is the job to be done?" Once you name the job, the approach usually picks itself.

These are not mutually exclusive. A mature setup often combines them: RAG to ground answers, an MCP app to act on the results, and a Skill to keep the procedure consistent.

Scenario 1: a support lead wiring the helpdesk into an assistant

A support lead wants agents to look up tickets, check account status, and post replies from inside Claude or ChatGPT. This is a live system with real-time state and write actions, so the job maps to an MCP app. The team either builds an MCP server against the helpdesk API or connects a hosted one from the B77 catalog, so support staff can find and enable it without touching credentials by hand. If ticket triage follows a fixed checklist, wrap that checklist in a Skill so every agent runs it the same way. RAG can sit alongside to pull answers from the knowledge base, but retrieval alone cannot close a ticket - that still needs the MCP tool.

Scenario 2: an engineer scripting refactors

A developer wants to rename symbols, rewrite imports, and run tests across a repository on their own laptop. The work is local, fast, and iterative - the classic inner loop. A CLI is the practical choice: it has direct filesystem access, no auth to configure, and it slots straight into scripts and CI. There is no user to onboard and no data leaving the machine, so the overhead of a hosted MCP app would buy nothing here. If the engineer later wants teammates to trigger the same refactor from a shared assistant, that is when promoting it to an MCP app starts to make sense.

Scenario 3: an ops team asking questions over internal policies

An operations team needs to ask questions like "what is our escalation policy for a Sev-1 incident?" and get answers cited from internal documents. Nothing is being changed - the job is retrieval - so this is RAG territory: index the policy documents and let the assistant quote from them. If the team also wants the assistant to open an incident or page an on-call engineer based on those answers, add an MCP app for those actions. The split is clean: RAG answers "what does the policy say?", MCP handles "now do it."

What a semi-technical lead should actually ask their team for

You do not need to specify the implementation. You need to describe the job clearly enough that your team can map it. Ask for:

• The verb. Does the assistant need to read, act, or both? "Act on a live system" points to MCP; "answer from documents" points to RAG.
• Who runs it. One developer on their machine (CLI) or many non-technical users through an assistant (an MCP app they can find and enable).
• Whether the steps are fixed. If there is a repeatable procedure people keep getting wrong, ask for a Skill on top of the tools.
• Where the data lives and who can see it. This decides how much you need to manage auth, scopes and hosting - covered in the next section.

Frame the request that way and your team can choose the approach without a long architecture debate. The technology is downstream of the job.

Security and privacy across the options

Each of these approaches gives an AI model a different level of reach into your systems and data. Before you wire any of them into an agent, it helps to know exactly what the thing can see and what it can do. The short version: MCP and A2A can be scoped tightly with proper authentication, CLI runs with whatever access the person or process invoking it already has, and RAG can surface anything you put in its index. Here's the detail.

Hosted MCP: scoped tokens and OAuth 2.1

A remote MCP server sits between the agent and the underlying API, which makes authentication and access control the whole game. Authorization is optional in the MCP specification, but when a server implements it, the spec builds it on OAuth 2.1 - an updated consolidation of the OAuth authorization framework that standardizes how an app gets permission to access an API on your behalf without ever handling your password. Part of that update is PKCE (Proof Key for Code Exchange), a mechanism that stops an intercepted authorization code from being exchanged for a token by anyone but the app that started the flow.

What this buys you in practice:

• Scopes - the permissions a token carries - let you grant an agent read-only access, or access to one project, rather than everything the account can touch. A calendar MCP might request "read free/busy" without "delete events." Review the scopes at the consent screen; they are the ceiling on what the server can do.
• Tokens, not credentials, are what the client stores. A short-lived access token can expire and be refreshed, so a leaked token has a smaller blast radius than a leaked password or a long-lived API key.
• The MCP server still sees whatever passes through it - your requests, the arguments your agent sends, and the responses. A hosted server operator is in the data path. Treat that the same way you'd treat any SaaS vendor: check what they log, where data is stored, and their retention policy before connecting anything sensitive.

Hygiene that doesn't weaken anything: prefer servers that request the narrowest scopes for the job, revoke tokens for MCPs you no longer use (from the provider's connected-apps settings, not just by removing the client config), and keep secrets out of prompts - an OAuth flow exists precisely so you never paste an API key into a chat window.

CLI: full local access, no scopes

A command-line tool driven by an agent runs as a process on your machine or server, with the same permissions as the user who launched it. There is no scope layer. If the agent can run git, it can also run anything else that user can run - read files, delete them, make network calls, install packages. That reach is exactly why CLI is powerful in the inner loop, and exactly why it's the riskiest option to point at untrusted input.

Sensible boundaries here are about the environment, not the tool: run agent-driven CLI work in a container, a scratch checkout, or an account with limited privileges rather than your primary shell; require confirmation before destructive commands; and never feed a CLI agent instructions from a source you don't trust, because a prompt that reaches the shell inherits the shell's power. The principle is least privilege - give the process only the access the task genuinely needs.

RAG: whatever is in the index can surface

Retrieval-augmented generation answers questions by pulling matching chunks from a search index and handing them to the model. Its security model is simpler and blunter than MCP's: RAG can't take actions, but anything you embed into the index is fair game to appear in an answer. If a document with salaries or customer records goes into the same index everyone queries, a well-phrased question can retrieve it.

The controls live at indexing and query time. Filter what you ingest, apply access control at the retrieval layer so a user only searches documents they're allowed to see, and remember that once text is in the index, redaction after the fact is hard. RAG exposes knowledge; it doesn't exercise permissions on your behalf.

Skills and A2A

A Skill has no independent access of its own. It runs inside whatever environment executes it and calls whatever tools that environment exposes, so its security profile is inherited: a Skill that invokes CLI commands carries CLI's risks; a Skill that calls an MCP server is bounded by that server's scopes. Review the instructions and any bundled code the way you'd review a script before running it.

A2A (agent-to-agent) connects one agent to another rather than to a tool, and each agent still authenticates to whatever it accesses downstream. The extra consideration is trust delegation: when your agent asks another agent to act, you're relying on that second agent's authentication and its own guardrails. Know what the other side can do, and keep the scopes it operates under as narrow as the task allows.

Side by side

The common thread across all five is least privilege: give each component the smallest amount of access that lets it do its job, and know who sits in the data path. MCP makes that explicit through scopes and tokens, which is a large part of why it's the usual choice when an agent needs to act against systems you care about.

Frequently asked questions

Can a CLI replace MCP?

Not entirely - they solve overlapping but different problems. A CLI works well when the human or agent already knows which command to run, and it tends to be cheaper per call: Scalekit's GitHub benchmark reports MCP consuming roughly 4-32× more tokens than equivalent CLI calls, mostly from schema overhead. But MCP shines for discovery and contextual tool selection, for remote and multi-user systems, and for auth and compliance that a raw command line doesn't standardize. Most teams end up using both: CLI in the local inner loop, and MCP servers for Claude or another assistant wherever access is external, shared, or customer-facing.

Is MCP basically an API?

MCP sits on top of APIs rather than replacing them - an MCP server usually calls one or more underlying APIs on the agent's behalf. The difference is that MCP standardizes how a model discovers and invokes those capabilities, describing tools, inputs, and auth in a way agents can read at runtime. We cover the full MCP-vs-API comparison in a separate article on this blog.

Is CLI still used today?

Yes. The command line remains a core part of everyday developer workflows, and AI coding assistants use it constantly - spawning a subprocess, passing arguments, and reading the output, with no schema layer or session state. For fast, local work where speed and token cost matter, it's often the most direct option, which is exactly why the CLI-versus-MCP question keeps coming up.

What is the difference between MCP and Skills?

MCP connects a model to live tools and data through a running server, so it can take real-time actions like querying a system or updating a record. Skills are packaged, repeatable procedures - instructions plus supporting files that tell a model how to do a task consistently. Put simply, MCP is about what the model can reach, while Skills are about how it should carry out a known process. They're complementary: a Skill can describe a workflow that calls MCP tools along the way.

Conclusion: name the job, then pick the tool

None of these five is a winner over the others, because they answer different questions: MCP for acting on live systems, CLI for fast local developer loops, Skills for repeatable procedures, RAG for grounding answers in your documents, and A2A for coordinating agents. Name the job - read or act, one developer or many users, fixed procedure or open-ended, where the data lives - and the approach usually chooses itself. In real setups you will often run several together, with least privilege as the constant.

When the job points to MCP - an assistant that needs to act on a live system, run by people who aren't at a terminal - the fastest way to get there is a hosted server your team can discover and connect in a couple of clicks. That's what B77 does: a marketplace of hosted MCP servers with OAuth 2.1 auth, billing and metering handled for you, whether you're connecting one to Claude, ChatGPT or Cursor, or publishing your own API as an MCP for agentic customers to find.