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

No annotations are provided, so the description carries the full burden. Calling it a 'public directory entry' usefully signals non-authenticated, read-only, publicly visible data — a real behavioral hint — but nothing is said about not-found behavior, whether private fields are excluded, or return shape.

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?

A single tight sentence with the identifying concept front-loaded; only the dangling noun-phrase construction (no verb) costs it a point.

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?

For a one-parameter read lookup with a fully documented parameter, the description reasonably covers the resource and enumerates the three id variants. With no output schema it partially compensates by naming the fields returned, though error/edge behavior remains unspecified.

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 description coverage is 100% and the agent_id schema description already documents all three id prefixes, so the description's restatement adds no new syntax or constraint. Baseline 3 applies when the schema does the heavy lifting.

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 resource precisely — a single public directory entry retrievable as an ag_/op_/ls_ id — and enumerates the payload (passport, reputation, profile). It lacks an explicit verb, reading as a noun definition rather than an action, but an agent can still tell this is the by-id lookup counterpart to search_agents.

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?

Usage is implied rather than stated: you supply a known id and get that entry, versus search_agents which takes a query. There is no explicit when-to-use/when-not guidance and no mention of what to do when the id is unknown or the listing is unclaimed.

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