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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description is not required to restate them. It does add genuinely non-obvious behavior: the response is deep and potentially large (complete instructions plus every skill's full procedure) and it enforces user-level isolation. It stops short of saying what happens when the id does not exist or is owned by someone else (empty vs error), which is the one behavioral gap that matters for calling it correctly.

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?

Effectively one dense sentence plus a short scoping clause, with the identifying key ('by id') and the returned payload front-loaded. The parenthetical breaking out skill sub-fields earns its space by telling the caller how deep the response goes. No filler or restatement of the title.

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 two-parameter read tool with an output schema and full annotations, the description covers the essential shape and even describes the return payload. However, it omits the undocumented 'enrich' flag and is silent on not-found/unauthorized behavior, both of which are decision-relevant for a per-user lookup. Reasonably complete, but short of what a lookup tool with a zero-coverage schema needs.

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 0%, so the description carries the full burden, and it only partially does so. 'By id' conveys the meaning of agent_id, but the second parameter, the boolean 'enrich', is never mentioned anywhere in the description or schema, leaving an agent to guess whether it expands skills, inlines procedures, or changes cost and payload size. Two undocumented parameters at 0% coverage is a material gap.

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 gives a specific verb and resource ('Get one of your Dactic agents by id') and enumerates exactly what is returned: name, platform, status, complete instructions, and every skill with its full procedure. That is far more concrete than a generic getter. It does not explicitly distinguish itself from near-name siblings such as load_agent or get_entity_context, which keeps it at 4 rather than 5.

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 only implied: 'by id' tells an agent this is the direct-lookup path as opposed to list_agents or search, but the description never states when to prefer it over load_agent or when not to call it. The ownership note ('never returns another user's agent') functions as an implicit precondition rather than stated guidance. Adequate but leaves the agent to infer routing against several plausible siblings.

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