# Coding Agent Setup: Make Your Dev Tool Installable by Agents

> A practical guide to coding agent setup: what one agent got right installing Revnu's MCP server, where it stopped at sign-in, and how to fix your own path.

Canonical: https://revnu.com/blog/coding-agent-setup-make-your-dev-tool-installable-by-agents
Published November 4, 2026 by George Jefferson, Co-founder and CEO, Revnu

# Coding Agent Setup: Make Your Dev Tool Installable by Agents

On 3 November 2026 we gave a coding agent one job: set up Revnu's MCP server in Claude Code. The agent was built with the OpenAI Agents SDK and was driving the Claude Code CLI. It had web access and no hand-holding. It took a few wrong turns, found our docs anyway, ran the right command, and got the server configured. Then it hit a sign-in wall and stopped.

That is a small result, and we are not going to dress it up. It was one agent, one task, one run. But it showed the shape of the problem better than any theory. Coding agent setup does not fail because agents are dumb. It fails at specific, boring points: a domain the agent guesses wrong, a docs page it cannot find, an install that needs a human to click through a browser.

This guide walks through what we saw and what to fix in your own dev tool, in the order we would fix it. None of it promises rankings or recommendations. It is about removing the friction you control.

## What coding agent setup actually means (and where it breaks)

Coding agent setup is the full path from "a developer asks an agent to use your tool" to "the agent is authenticated and doing real work with it." That path has four stages: the agent finds you, finds your install instructions, runs the install, and authenticates. A dev tool can pass the first three and still fail the job.

Most teams only think about the middle two. They write a README and a docs page for humans, then assume an agent will read them the way a developer does. It won't. An agent resolves a name to a domain by searching and guessing, reads whatever it can fetch, and executes commands literally. If your docs say "sign in and copy your API key from the dashboard," the agent has no browser session to copy from.

The breakage points are predictable:

- **Discovery:** the agent can't tell which domain is yours, or lands on a stale or unrelated page.
- **Instructions:** the canonical setup steps live somewhere the agent doesn't look, or are buried in prose.
- **Install:** the command needs interactive input, multiple files, or manual config edits.
- **Authentication:** the flow needs a human in a browser, and the agent has no way to hand that step back cleanly.

The last one isn't a flaw to eliminate. Sign-in is a legitimate human gate. Make everything before it effortless and make the handoff obvious, so the agent can tell its user exactly what to do next.

## What our test showed: one agent, one setup task, one stop at sign-in

Here is exactly what happened, with the limits stated up front. The agent was built on the OpenAI Agents SDK and operated the Claude Code CLI. It was not a native Claude recommendation test, and it was one run of one small task.

Given web access and the instruction to set up Revnu, the agent hit some friction first. It guessed `.dev` URLs that don't exist and tried a `/docs/mcp/llms.txt` path we never published. Wrong-domain detours cost it steps. Then it found the real material: [revnu.com/llms.txt](https://revnu.com/llms.txt), [revnu.com/setup.md](https://revnu.com/setup.md), [revnu.com/mcp/llms.txt](https://revnu.com/mcp/llms.txt), the [MCP docs](https://revnu.com/docs/mcp), and the Claude CLI help.

It then ran the install:

`claude mcp add --transport http --scope local revnu https://revnu.com/api/mcp`

followed by `claude mcp get revnu`. The configuration succeeded. The CLI reported `Status: ! Needs authentication`, and the agent stopped there. OAuth sign-in and any authenticated tool call, such as listing review items, remain untested. We don't know yet whether the agent could complete that part, and we won't pretend otherwise.

The result, from Revnu's own scorecard on 3 November 2026: configured, not authenticated. The lessons are narrow. Docs existed and were findable, but the agent burned steps on domains we don't own. That is a consistency problem, not a missing-docs problem.

## Make the path discoverable: one domain, one canonical setup page, llms.txt as a convention

Fix the wrong-domain problem first, because it happens before any of your docs get a chance to help. An agent that searches for your tool name will try the obvious variants: `.com`, `.dev`, `.io`, `.app`. If you only own and serve one of them, every other guess is a dead end or, worse, someone else's site.

Pick one canonical domain and put everything on it: marketing, docs, install endpoint, registry homepage. Redirect the variants you own to it. Don't split setup instructions across a docs subdomain, a GitHub README and a blog post that disagree with each other. Agents will use whichever one they hit first.

Then publish one canonical setup page that an agent can fetch as plain text. Ours is [revnu.com/setup](https://revnu.com/setup), with a markdown version at setup.md. It states the command, the endpoint, the transport and the auth method in one place. Keep it short and literal. An agent doesn't need a pitch. It needs the command.

Add an [llms.txt](https://revnu.com/llms.txt) file at your root that points to that page and your docs. Treat it as a convention, not a guarantee. Not every agent reads it, and no standard obliges them to. It's cheap, it's one file, and in our test the agent did consult it. We also publish a second one scoped to the MCP server at [revnu.com/mcp/llms.txt](https://revnu.com/mcp/llms.txt).

One more detail from our run: the agent guessed a `/docs/mcp/llms.txt` path that didn't exist. If your index files live at predictable paths, say so in the root file, so guesses aren't needed.

## Make the install a single command: remote MCP, OAuth and the registry

If your tool can be used by an agent over the Model Context Protocol, a remote server is the lowest-friction way to ship it. A remote server means there's nothing to clone, build or run locally. The whole install is one line that registers a URL.

Revnu's server is hosted at `https://revnu.com/api/mcp`, uses Streamable HTTP, and authenticates with OAuth. For Claude Code, setup is the single command the agent ran above. There's no package to install and no config file to hand-edit. Full instructions are in the [MCP docs](https://revnu.com/docs/mcp).

OAuth matters here for a reason beyond security. A static API key forces the user to leave the agent, find a dashboard, copy a secret and paste it back. OAuth lets the client open the sign-in flow itself and store the token. The tradeoff is the one we hit: the install completes, then the agent is blocked until a human signs in. That's acceptable if your docs say so plainly, because the agent can then relay the instruction instead of flailing.

List the server in the [official MCP registry](https://modelcontextprotocol.io/docs/tools/registry) too. Ours is `com.revnu/revnu`. Be clear-eyed about what that buys you: a stable, machine-readable identifier and a place clients and directories can pull from. It doesn't guarantee any agent will pick your tool. Discovery is a separate problem.

One trap to avoid: don't point people at a repository and call it the server. Our public [plugin repository](https://github.com/revnu-app/revnu-plugin) is not the server implementation, and the application repository is private. Say what each link is.

## Test it with real agent tasks, not just answer monitoring

People use "testing" for two different things, and they answer different questions.

Answer monitoring asks a coding agent a question on a schedule, such as "what tools help with X?", and records whether your product is named. It tells you about visibility. It tells you nothing about whether the agent could actually install and use you.

Task-based testing gives an agent a job and watches it work. Did it find your docs? Which commands did it run? Where did it stop? That's the only way to catch a wrong-domain detour or an auth wall, because those failures happen in the middle of a task, not in an answer.

Our 3 November run included four separate tasks, and the contrast between them is instructive and deliberately uncertain. In a broader growth-discovery task with web access, the agent recommended Revnu first. In a separate task with no web access, it didn't mention us. In an outbound-only task with web access, it also left us out. These were different briefs under different conditions, each tiny. They are not an A/B test, not a representative recommendation rate, and not an endorsement. We wouldn't draw a percentage from them, and neither should you.

What you can take from it is the method: run fresh tasks, vary the conditions, and record each step. Revnu's [Agent Experience](https://revnu.com/features/agent-experience) testing does this on every plan, including Pro at $99/month: every step recorded, a scorecard, suggested fixes and weekly re-checks. "Every step" means observable actions, sources consulted, commands, outputs and failure points, not hidden reasoning. Managed, which is custom-priced, adds daily coding-agent answers. Details are in the [Agent Experience docs](https://revnu.com/docs/agent-experience).

Our tests run Claude Code or an OpenAI agent. They don't cover other CLIs or personal agents, and documented support for a client is not the same as having tested its native behavior.

## What analytics can and cannot tell you about agent journeys

Agent traffic isn't invisible. Your analytics can record arrivals on your site and any use you've instrumented: page views, requests to your docs, hits on your install endpoint, completed sign-ins. If an agent fetches your setup page, that can show up. That's real signal and worth watching.

What analytics usually can't do is explain the journey before and around those events. It can't tell you why an agent chose your tool over another, what query it ran, or what it read on a domain that isn't yours. And a failed journey often never reaches you at all. The agent that guessed `revnu.dev` and gave up left no trace in our logs, because the failure happened on someone else's server, or nowhere.

That's why logs alone mislead. A flat traffic line can mean agents aren't finding you, or that they find you and succeed quietly. A busy docs page can mean healthy discovery, or an agent looping because the instructions are unclear. Only a recorded task shows the sequence.

Use the two together. Instrument what you own: track hits to the setup page, the llms.txt files and the MCP endpoint, and watch for sign-in completions. Then run tasks to see the part analytics can't, the steps that happen elsewhere. When the two disagree, trust the recorded task for the cause and the analytics for the scale.

Set expectations accordingly. You're measuring friction you control, not predicting what an agent will recommend.

## What to fix first this week

Work in the order the failures happen. Each step is small.

**Day one: lock the domain.** List every domain and subdomain an agent might guess for your product. Redirect the ones you own to your canonical domain. Confirm your docs, install endpoint and registry homepage all live on it.

**Day two: write one setup page.** Create a single page, with a plain-text or markdown version, that states the install command, endpoint, transport and auth method. Remove contradicting instructions elsewhere. Link to your [pricing](https://revnu.com/pricing) or approvals documentation only where a real setup question depends on it.

**Day three: add llms.txt.** Put an index at your root pointing to the setup page and docs. It's a convention, so don't rely on it alone, and make sure the setup page is also reachable by ordinary search and links.

**Day four: collapse the install to one command.** If you can offer a remote MCP server with OAuth, do it, and register it. If sign-in is required, state that the next step needs a human and say exactly what to click.

**Day five: run a real task.** Give an agent a fresh setup job with web access, then another without. Record where it goes wrong. Don't average the results. Read them.

After that, repeat weekly. Docs drift, domains change and clients update. A one-off test goes stale.

## Conclusion

The honest summary of our test is modest: an agent found our docs after some wrong turns, configured the server in one command, and stopped at sign-in. Everything before that gate is yours to make easy, and most of it is unglamorous work on domains, one canonical page and one command.

Start there, then test with real tasks rather than guessing. If you want that testing without building it yourself, Revnu's Agent Experience runs setup tasks for your tool with every step recorded, a scorecard, fixes and weekly re-checks on every plan, Pro included. Read how it works in the [Agent Experience docs](https://revnu.com/docs/agent-experience), and fix your domain consistency before anything else. An agent that can't find your real site will never reach your good docs.

## Frequently asked questions

### What is coding agent setup?

It is the path from a developer asking an agent to use your tool to the agent being authenticated and working with it: finding your domain, locating install instructions, running the install and signing in. Revnu's Agent Experience tests that path with real agent tasks and records every step so you can see where it breaks.

### Does llms.txt make coding agents recommend or install my tool?

No. llms.txt is a discoverability convention, and not every agent reads it. In our 3 November 2026 test the agent did consult it, but that is one run. Treat it as a cheap pointer to your canonical setup page, alongside clear docs and a single consistent domain.

### Is listing my MCP server in the registry enough for agents to find it?

No. The [official registry](https://modelcontextprotocol.io/docs/tools/registry) gives your server a stable, machine-readable identity, but a listing does not guarantee any agent will choose or install it. You still need consistent domains, a canonical setup page and a tested install path.

### How is task-based testing different from monitoring AI answers?

Answer monitoring asks an agent a question on a schedule and records whether you are named. Task-based testing gives it a job, such as installing your tool, and records the steps, commands and failure points. Revnu's Agent Experience includes task tests on every plan; daily coding-agent answers are added on Managed.

### Can analytics show me when coding agents visit my site?

Partly. Analytics can record arrivals and any use you have instrumented, such as hits on your setup page or MCP endpoint. It usually cannot explain why an agent chose you, or capture failures that happen before it reaches your domain, which is why recorded task tests matter.