yaaif_agent_get

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

With no annotations provided, the description must carry the full behavioral burden. It only states the action and one feature (includes skill_ids), but does not disclose anything about error behavior, authentication, read-only nature, or response format. For a get operation, this is thin and leaves the agent to guess what exactly is returned or what happens on failure.

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 description is a single, front-loaded sentence that directly states the purpose. There is no filler or redundancy, making it optimally concise for its content.

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?

Given the absence of an output schema and the large number of sibling tools, the description is too sparse. It does not clarify the exact structure of the returned agent definition, nor does it delineate this from similar tools like yaaif_agent_spec_get or yaaif_ambient_agent_get. An agent would need more context to use it correctly.

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?

The sole parameter agent_id is left completely unexplained. Schema description coverage is 0%, so the description must compensate, but it merely says 'by id' without clarifying what the ID is, how to obtain it, or its expected format. This provides no added meaning beyond the parameter name.

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 clearly states the action (get), the resource (agent definition), and the identifier (by id). It also adds a distinguishing detail (includes skill_ids) that separates it from list-like siblings such as yaaif_agent_list. This is specific and unambiguous.

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 (to fetch a single agent by ID), but it does not explicitly mention alternatives or when not to use it. Since it is clear from the context that this is the retrieval tool versus creation or update tools, it meets the 'clear context, no exclusions' bar, but lacks explicit routing compared to tools that name sibling alternatives.

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