Getting Your Dev Tool Recommended and Used by Claude Code and Other Coding Agents

Docs series (part of GEO for PLG SaaS): Structuring docs for AI retrieval · llms.txt for developer tools · API references, code samples and changelogs · Coding agents and your dev tool

Quick answer

Coding agents pick libraries from four inputs: what the model learned in training, what it can search and fetch during the task, the project’s instruction files and the tools it’s connected to, such as MCP servers. To get your SDK chosen and used correctly, make it well known and well documented on the public web, make your docs readable by a fetch tool, ship a clear install command, give users agent instructions they can paste into their projects, and consider a docs MCP server.

There’s one honest caveat: no public study shows which tools coding agents recommend by default, and the agents don’t report it. Measuring this means running tests yourself.

How Claude Code chooses which library to use

Surferstack’s comparison of coding agents describes four inputs, and the harness (the agent app around the model) controls three of them:

Project context matters more than most vendors expect: an agent working in a repo that already uses a library will usually keep using it.

Training data: be the obvious answer

When an agent doesn’t search, it falls back on what the model already knows. That favors libraries with lots of public, consistent material:

• docs and quickstarts that have been stable and public for a while
• example repos and templates on GitHub
• tutorials, comparisons and community answers that name your library for a specific job

This is slow and cumulative. It’s also where the rest of GEO helps: the pages and mentions that get you into AI answers are much the same material future models learn from. See how AI recommends developer tools.

Live search and fetch: make your docs readable

Claude Code has built-in WebSearch and WebFetch tools. WebFetch converts a fetched HTML page to Markdown and runs an extraction prompt over it, so the model gets a summary of the page, not the raw page. It also sends an Accept header that prefers Markdown.

What that means for your docs:

• Serve full text in the initial HTML. A Claude Code feature request notes that client-side-rendered docs return empty HTML shells.
• Put the answer near the top of each page, since the extraction step may not keep everything.
• Offer Markdown versions of pages for servers that support content negotiation.
• Keep one task per page. See structuring docs for AI retrieval.

CLAUDE.md and AGENTS.md

Instruction files tell an agent how to work in a specific project. They live in your users’ repos, not on your site, so you can’t add them yourself. You can make it easy for users to add the right lines.

• CLAUDE.md holds project instructions for Claude Code. See how Claude remembers your project.
• AGENTS.md is an open format read by many coding agents. Claude Code reads AGENTS.md when there’s no CLAUDE.md in the working directory or above it.

What to publish:

1. A copy-paste snippet in your quickstart for users’ instruction files: which package to use, the current version, the install command and a link to your docs or llms.txt.
2. An AGENTS.md in your own SDK repo and starter templates, with install, test and lint commands and the two or three conventions that matter.
3. Keep it short and current. Stale commands cause more failures than missing ones.

## Payments
- Use the `@acme/sdk` package (v4). Install: `npm install @acme/sdk@4`
- Docs index for agents: https://docs.acme.example/llms.txt
- Don't use the deprecated `createCharge()`; use `payments.create()`.

MCP docs servers: do they help adoption?

An MCP server lets an agent query your docs or API directly instead of searching the web. MCP is an open standard for connecting AI applications to tools and data, and Claude Code can connect to MCP servers.

A docs MCP server helps when:

• your docs are large or change often, so a search tool beats a static index
• agents need to act on your API, not just read about it
• you want answers to come from your current docs, not a third party’s stale copy

It doesn’t help with discovery: a developer has to install it first, so it improves how well your tool is used, not whether it’s chosen. Describe each tool in plain terms that match what developers ask for. Microsoft’s developer blog notes that agents match tool descriptions to intent, and may skip tools entirely when they feel confident.

Install-command clarity

An agent that can’t install your package correctly will switch to one it can.

• One canonical install command per language, at the top of the quickstart, as text.
• Name the package exactly, including the scope, and say which names are old or unofficial.
• List required environment variables and how to get keys, including whether that needs a free plan or a trial.
• Show a minimal working example right after install.
• Make CLI tools non-interactive by default or document the flags, since agents can’t answer prompts mid-install.

Measuring it: manual tests in Claude Code

There’s no dashboard for what coding agents choose. Build your own test:

1. Write 10–20 tasks a developer in your category would give an agent, such as “add payments to this Next.js app”, without naming any product.
2. Run each in a clean project in Claude Code and at least one other coding agent, several times.
3. Record which library was chosen, whether the agent fetched docs, which pages it fetched, and whether the code ran.
4. Repeat with your instruction snippet or MCP server added to see the difference.
5. Rerun monthly and after model updates.

Results vary between runs and models, so report rates, not single runs.

Related reading

• GEO agency for dev tools
• How AI recommends developer tools
• Best GEO agencies for developer tools
• What is GEO?
• What is AI share of voice, and how is it measured?

Want us to test what coding agents pick in your category? See our dev tools work or talk to AUQ.