Getting an agent to choose your tool is a new discipline, and almost nobody is practicing it yet. Call it agent-facing discovery. It is not marketing, it is not SEO, and it is not developer relations. It is won or lost at the level of the capability description and the input/output contract that an agent's planner actually reads before it decides which of a dozen available tools to invoke. The tool whose description most clearly states what it does, when to use it, and what it returns gets called. Everything else, your pricing page, your logo, your launch thread, is invisible at the moment of selection.
Understand the moment precisely, because the whole craft follows from it. An agent working a task reaches a step where it needs an external capability. Its planner has, in context, a list of connected tools. For each one it sees a name, a natural-language description, usually a when-to-use signal, and an input schema with typed parameters. It does not see your website. It does not run your onboarding. It reads those few hundred tokens, predicts which tool best fits the current step, and generates a call with arguments it infers from the schema. That prediction is the entire game. You are not persuading a human evaluator over a sales cycle; you are being pattern-matched by a language model under a token budget, in one shot, against competitors whose descriptions sit right next to yours in the same context window.
This reframes distribution. I have argued that your product needs to be an agent skill, not just a website, that the addressable surface is shifting from human eyeballs to agent planners. Agent-facing discovery is the tactical craft that follows from accepting that. Once your capability is reachable by an agent, the question is no longer whether a person finds you attractive. It is whether a planner, reading a terse contract, correctly predicts that you are the right call. That is a writing problem and a schema-design problem before it is a growth problem.
The description is the product, at selection time
Start with the single lever that does the most work: the natural-language description the planner reads. Most teams write it the way they write an API doc summary, for a human developer who will read the full reference afterward. That is the wrong reader. The planner will not read your full reference. It has the one sentence you gave it, and it will act on that sentence literally.
A precise description does three things a vague one cannot. It states exactly what the capability does, so the planner selects it for the right steps. It states what the capability does not do, so the planner does not mis-select it and then fail. And it disciplines the arguments, so the planner does not hallucinate a parameter you never meant to accept. Ambiguity anywhere in that sentence propagates directly into wrong calls, because the model fills gaps with plausible-sounding guesses. This is the failure mode I described in an agent is only as good as its tools: a badly specified tool does not merely go unused, it actively degrades the agent that trusts it, because the agent cannot tell your ambiguity apart from its own uncertainty.
Make this concrete. Here is a description written for a human, which is to say written badly for the reader who matters:
search— Powerful search for your data. Fast, flexible, and reliable. Find anything across your workspace.
Every word of that is marketing, and none of it helps a planner decide. "Powerful," "fast," "flexible," "reliable" are unfalsifiable adjectives; the model cannot condition a decision on them. "Your data" and "your workspace" are undefined referents. "Anything" is a claim the planner will take literally and then over-select the tool for tasks it cannot serve. There is no when-to-use, no when-not-to, no shape of the input, no shape of the return. A planner facing this next to three other search tools has nothing to discriminate on, so it guesses, and its guess is your conversion rate.
Now the same capability, written for the actual reader:
search_customer_orders— Full-text and structured search over a merchant's order records (order ID, customer email, product SKU, status, date range). Returns up to 50 matching orders, newest first, each with id, customer, line items, fulfillment status, and total. Use this to answer questions about specific past orders or to filter orders by attribute. Do NOT use this for aggregate analytics (revenue totals, cohort counts); useorders_reportfor those. Read-only; never modifies data.
Notice what changed. The name states the domain. The description names the searchable fields, so the planner knows when its current step is a fit. It states the return shape and cap, so the planner can reason about what it will get back. It gives an explicit when-to-use and, the underrated part, an explicit when-NOT-to-use that hands off to a sibling tool. And it states a safety property (read-only) that makes the tool safe to try. A planner reading this does not have to guess. It can match the current step against a described contract. That is the difference between being selected because you fit and being selected by luck, and luck does not compound.
Schemas are where selection turns into a correct call
Selection is half the battle. The other half is the call the planner generates once it has chosen you, and that is governed by your input schema. A clean, minimal, well-typed schema with a real description on every parameter is what stands between a correct invocation and a hallucinated one.
The mechanics are unforgiving. When the planner fills your arguments, it is generating tokens conditioned on the parameter names, types, and descriptions you provided. A parameter called q with no description invites the model to stuff the wrong thing into it. A parameter called status typed as a free string invites "shipped", "Shipped", "in transit", and "done", four ways to be wrong. The same parameter typed as an enum of your actual status values constrains the generation to valid outputs. Every constraint you encode as a type is a class of hallucinated argument you have eliminated at the source. Minimalism matters for the same reason: each optional parameter is another field the planner might fill incorrectly or spend reasoning budget deciding about. If a parameter is not load-bearing, deleting it makes you easier to call correctly.
Then the return. An agent acts on what you send back, so structured, predictable output is not a nicety; it is what determines whether the agent can continue. Return typed fields, not a prose blob the model has to re-parse. When you fail, fail informatively: an error that says date_range invalid: 'to' precedes 'from' lets the agent correct itself and retry, while a bare 400 Bad Request ends the run. The agent's recovery loop is only as good as the errors you hand it. Design your errors as instructions to a machine that wants to fix its own mistake.
Trust is what makes an agent, and its owner, willing to depend on you
A planner can select you and call you correctly and still be a bad bet if depending on you is unsafe. Here the properties an operator cares about become selection criteria in their own right: authentication that scopes access cleanly, rate limits documented rather than discovered by getting throttled mid-task, idempotency so a retried call does not double-charge or double-send, and provenance so the agent can attribute where a result came from. Idempotency deserves particular weight in an agent world, because agents retry. An agent that hits a timeout will call again, and if your write endpoint is not idempotent, its persistence becomes your data-corruption incident. Tools that are safe to retry get trusted with the actions that matter; tools that are not get quarantined to read-only, low-stakes steps, or avoided entirely by any owner paying attention.
These are also the properties that make a human comfortable connecting you in the first place, and for high-stakes capabilities a human is still in the loop approving which servers an agent may use. Trust signals do double duty: they make the agent willing to rely on you at runtime, and they make the operator willing to install you at all. Both readers evaluate the same contract from different angles.
Registry strategy, versioning, and reputation
Being well-described only helps if agents can find you, which puts registries and marketplaces of MCP servers — the Model Context Protocol connectors that expose your tools and data to an agent in a standard way — and skills on the critical path. This surface is genuinely early and shifting, so treat the next part as a forecast rather than a playbook. I expect discoverability within these registries to become a real competitive axis, ranked partly by description quality and partly by observed reliability, in something like the way search ranking blends relevance and authority. Being listed where agents look is table stakes. Being listed with a description that wins selection is the actual work, and it is the same work whether the registry is a curated catalog or an open index.
Two operational disciplines follow. Version and hold your contract stable, because every agent that learned to call you encoded assumptions about your schema and your return shape; a breaking change silently converts working integrations into failing ones, and unlike a human developer, the agent will not read your changelog. Treat your tool contract with the seriousness of a public API, because to an ecosystem of agents that is exactly what it is. Then build reputation as reliability over time. An agent ecosystem, or the humans steering it, will route around a tool that returns wrong answers or flakes under load, and it will do so faster than a human market would, because the feedback is programmatic.
The through-line is that all of this is writing for a machine reader, and it rhymes with writing for content extractors: the same premium on unambiguous statement, explicit scope, and structure a literal reader can act on without inference. The format will change under you. Schemas will get richer, planners will get better at reading intent, ranking will get more sophisticated. What will not change is that a context-limited reader choosing among options needs you to state, plainly and falsifiably, what you do and what you return. Write the contract for the reader who acts on it, not the one you wish you had.