Agent-Led Growth for APIs, CLIs, and MCP Servers: What Differs by Interface

Direct answer

The customer's goal stays the same on every interface, but the agent's work changes. Through an API, it installs an SDK, reads documentation, and writes code. Through a CLI, it installs a binary, authenticates without a browser, and works through commands and their output. Through an MCP server, the connection is set up before the task starts, and the agent can only use the tools the server exposes. Test each interface separately.

---

Agent-led growth depends on an agent taking a customer from a request to a working result with your product. Our guide to agent-led growth describes that journey. Developer tools often offer several ways in: an API with SDKs, a command-line tool, and an MCP server. The places where an agent can get stuck differ between them.

The clearest way to see the difference is to give an agent the same task on each interface.

One Stripe task on three interfaces

Lightsage's Devtool Arena, which we operate, gave Claude Code with Sonnet 5 the same Stripe task through each interface: create a "Pro Plan" product with a $29/month price, create a payment link for it, and print the URL. Each prompt named Stripe, and a test-mode secret key was already set in the environment. These runs show product use after selection, not discovery.

You can inspect the API, CLI, and MCP reports. Select the Oct 2026 edition, which contains runs completed in late September. The Journey tab shows each tool call and response. The pages may show newer runs later.

Through the API: install the SDK, read the reference, write code

The agent first checked whether Stripe's Python package was installed. The import failed with ModuleNotFoundError, so it installed the package. It then fetched Stripe's API reference page for creating payment links. That page opens by telling agents they can read it in a terminal through the Stripe CLI and points to Stripe's agent skills, before the API details.

Using the parameters from that page, the agent wrote create_payment_link.py and ran it. The script printed the new product, price, and payment link IDs and the link URL. Devtool Arena checks API runs by executing the generated script again in a fresh sandbox.

Through the CLI: install the tool, then work in commands

The prompt supplied installation commands and said the key was in STRIPE_SECRET_KEY. Our installation commands lacked sudo, so the first attempt failed with "Permission denied", a setup error on our side. The agent checked that passwordless sudo was available and reran them.

It confirmed the CLI could reach the account by listing products, passing the key with --api-key, as it did on every later command. Then it ran stripe products create, stripe prices create with -d "recurring[interval]=month", and stripe payment_links create. Each command returned JSON, and the agent extracted the URL from the last response.

Through MCP: find the operation, then call it

Before the session started, the test harness configured Claude Code to launch Stripe's MCP server with npx -y @stripe/mcp. The agent loaded five Stripe tool definitions, then spent 7 of its 10 MCP calls finding its way: one account lookup, three stripe_api_search calls, and three stripe_api_details calls to read parameters. A search with the intent create and the resource payment link, for example, returned the PostPaymentLinks operation.

Three stripe_api_write calls then created the product, price, and payment link. No MCP call returned an error.

What the comparison shows

Each run's trace ends with a newly created payment link. The API result was checked by re-running the script; for the CLI and MCP runs, a model-based grader reviewed the trace. The effort went to different places: getting the SDK and the right reference page, installing the tool, or locating operations within a few general-purpose tools.

Stripe's MCP server exposes search, details, and write tools rather than one tool per endpoint. That keeps the tool list small, at the cost of lookup calls before each action. The runs took 6, 11, and 12 tool calls, but the counts are not comparable: the CLI run includes a retry caused by our installation commands, and the MCP run includes loading its tools and writing a summary file its prompt required. Devtool Arena also grades each interface with different checks, so compare the steps rather than the scores.

Setup and authentication happen at different times

With an API, setup happens during the task. The agent can install a package, read the key from the environment, and retry. Documentation carries much of the load: an install command and the credential variable name on the first page an agent fetches remove guesswork.

With a CLI, setup also happens during the task, but login flows designed for people can stop the agent. In other Devtool Arena runs, one CLI's login command printed "Waiting for browser authentication..." and waited for a sign-in that never came. Another CLI's login refused to continue: "Cannot prompt for input in non-interactive terminals." We name vendors where a behavior clearly belongs to the product; where our test setup may have contributed, as with these two, we describe the behavior without naming it. The Command Line Interface Guidelines state the rule directly: "Never require a prompt." If standard input is not an interactive terminal, skip prompting and require flags or arguments instead.

Resend's CLI shows the alternative. In its run, resend whoami --json reported that the CLI was authenticated and that the key came from the environment, so the agent confirmed its credentials in one call.

With an MCP server, setup happens before the agent starts. The client launches or connects to the server when the session begins, using the configuration and credentials it was given. Claude Code's MCP documentation notes that it does not reconnect local stdio servers automatically and directs users to its /mcp command to sign in to remote servers that require OAuth. An unattended agent cannot complete a browser sign-in partway through a task. Devtool Arena could not run four servers on its public MCP board for this reason.

Document which credential each interface expects, especially when the API, CLI, and MCP server use different ones. Offer a non-browser option, such as a token read from the environment, for automated use.

The agent looks for operations in different places

Through an API, agents learn from documentation. As the Stripe reference showed, a page can also point the agent to a different interface; in that run, the agent stayed with the SDK.

Through a CLI, agents can learn from help output. Resend's CLI includes a command that prints its full command tree as JSON, including which flags are required in non-interactive mode.

Through MCP, agents can only use what the tool list exposes. In Claude Code, only tool names and server instructions load at session start; full definitions load when a search matches. Anthropic advises server authors to put the words Claude would search for near the start of descriptions. If an operation is missing, searching cannot find it. In one sandbox provider's MCP run, the agent searched the server's tools several times for a way to list existing sandboxes. None of the tools did that.

Errors and results need machine-readable shapes

CLIs need output an agent can parse and exit codes it can trust. The Stripe CLI's JSON output let the agent pull the URL out with a simple text search. In contrast, one CLI login command reported a 401 "Permission denied" error and then exited with status 0. A script or agent checking the exit status would treat that failure as success. The CLI Guidelines say to "Return zero exit code on success, non-zero on failure."

MCP tools return errors to the model, which makes their wording part of the interface. The MCP specification says tool execution errors "contain actionable feedback that language models can use to self-correct and retry with adjusted parameters." Pinecone's MCP server applied the same idea to a successful result. In its run, the upsert response said new records "can take a few seconds to be indexed" and that the agent should wait briefly and retry if data was missing. The agent waited six seconds, and its next search found the record. Other servers in the same batch returned raw validation output or results that failed the protocol's schema check, and their agents retried without a clear next step.

APIs follow the same principle through their error bodies. Anthropic's guide to writing effective tools for agents recommends error responses that "clearly communicate specific and actionable improvements, rather than opaque error codes or tracebacks."

Agents combine interfaces to get past a step

Cloudflare's runs show agents mixing interfaces within one task. In the API run, the task was to deploy a Next.js starter. The agent's final script created the Pages project through the REST API but called the Wrangler CLI to upload and deploy the build. The trace does not show whether the REST API alone could have handled the upload; the agent chose Wrangler for that step.

In the CLI run, wrangler deploy stopped because the account had no workers.dev subdomain. Cloudflare's API error explained that opening the Workers & Pages dashboard page for the first time would create one, a step designed for a person. The agent instead registered a subdomain through the REST API and deployed again. Both runs ended with a working deployment, reached through a combination of interfaces.

For a growth strategy, this means measuring by customer task as well as by interface. A step that exists only in a dashboard, or an operation missing from your MCP tools, can send agents to another interface. If no interface covers the step, the task stalls.

What to check on each interface

API and SDKs

• The first page an agent fetches names the package, the install command, and the credential variable.
• Error bodies say what went wrong and what the caller can do next.
• The agent can confirm the result with a follow-up read, such as retrieving the object it created.

CLI

• Authentication works from an environment variable or flag, with no browser or prompt, and a command reports which credential is in use.
• Commands can return JSON, and failures exit non-zero.
• Help output lists the flags required for non-interactive use.

MCP server

• Local servers read credentials from the environment; remote servers offer a non-browser option for automation.
• Tools cover your customers' common tasks, with the task words at the start of names and descriptions.
• Errors explain the next step, and results match the declared schema.

Run the same customer task on each interface you ship, under comparable starting conditions, and read the trace. Lightsage's Agent Usability runs tasks against APIs, CLIs, and MCP servers and shows the trace for each attempt. Our MCP compatibility guide goes deeper on testing MCP servers, and our guide to tracking agent recommendations across API, SDK, CLI, and MCP covers the discovery side of each interface. To turn findings into a repeatable process, see how to build an agent-led growth strategy.

Frequently asked questions

Which interface should a developer tool build first for agents?

The runs in this article don't support a general answer. Start with the interface your customers' agents already use for your most common task, and test that task end to end. In the Stripe runs described here, the API, CLI, and MCP server all completed the same task.

Why do CLIs that work for people fail for coding agents?

Coding agents usually run commands in a non-interactive shell. Browser logins, prompts, and commands that exit 0 after failing all make a CLI harder to drive. Accept credentials from flags or environment variables, offer JSON output, and exit non-zero when a command fails.

Can an agent fix an MCP connection problem during a task?

Usually not. The client starts or connects to the server at the beginning of the session with the configuration and credentials it was given. If the server fails to start or needs a browser sign-in, an unattended agent typically cannot recover, so test the setup path as carefully as the tools.

Does a passing run on one interface mean the others work?

No. Each interface has its own setup, authentication, discovery, and error behavior. Test the same customer task on each interface you ship.