Get agent details

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful non-obvious context: the required read scope, the field shape including live status rollup and usage_24h, and especially the semantics of `untrusted_fields` explaining provenance. That last detail is behavioral context an agent couldn't infer from the schema.

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?

Three sentences, front-loaded with the permission requirement, then the return shape, then the untrusted_fields caveat. Efficient and each sentence carries distinct information, though the untrusted_fields sentence is denser than needed.

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 single-entity read with full schema coverage and full annotations, the description adds the return-shape summary and the provenance caveat, which is more than most tools at this level. Without an output schema the untrusted_fields note is particularly valuable. Missing only explicit guidance on when to prefer get_agent_usage/get_agent_dependencies.

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 single param is documented ('Agent UUID, from register_agent or list_agents'). The description repeats the UUID-source hint but adds no format or validation details. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Gets one agent by UUID') and names the field set it returns, which ties it to list_agents. It distinguishes itself from get_agent_usage and get_agent_dependencies by mentioning those fields inline, but doesn't explicitly rule out those siblings as alternatives.

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?

The description implies usage ('gets ONE agent by UUID' vs list_agents' plural) and notes the UUID comes from register_agent or list_agents. But it doesn't explicitly state when to use this vs get_agent_usage or get_agent_dependencies, which likely return overlapping subsets of the same data.

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