Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real behavior: results are ordered best-guess-first, each carries a "how to read it further" pointer, people are matched regardless of typed form and are labeled member/Roblox/both, and supplying `context` reorders tied people ahead. It also discloses the `ask` sentinel for the two-people tie case, which an agent could not infer from the schema. Minor gap: no mention of result limits or what happens on a total miss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the primary routing rule are front-loaded, and nearly every sentence conveys distinct information about resolution behavior. Some phrasing is dense and idiosyncratic ("each with how to read it further", "`ask` means two people fit"), which costs a bit of clarity but not much length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters, full schema coverage, and no output schema, the description carries the return-shape burden and does so reasonably: ranked candidates, best guess first, with kind labels and continuation pointers, plus the `ask` outcome. What's still vague is the concrete shape of a candidate (id? canonical url? type field), which matters for a resolver whose whole job is producing something downstream tools can consume.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are self-documenting, so the baseline is 3. The description does add value on `context` by explaining its effect (people tied to the game/studio come first) rather than just its meaning, but it adds nothing about `query` beyond the schema's "name, @username, id or link, as it was written."

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the verb (resolve a name/link/id) and the full set of resources it can resolve: games, studios, Roblox groups, people, and topics. It also distinguishes itself from the direct-lookup siblings (`game`, `studio`, `person`) by framing itself as the disambiguation step that returns ranked candidates. The tool name `find` is generic on its own, but the prose removes ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use it first for any name that may not be a game" gives a clear routing rule, and the example ("kuzu" is the studio KUZU) shows when the agent should not assume a game. It also states that pasted roblox.com/roterminal.co links or ids go straight through, which is a concrete invocation condition. It stops short of naming the alternative for the known-game case (presumably `game`), so the exclusion is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.