Manager Api Get

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the description doesn't contradict them. It adds the requirement of 'Raw read' permission in the control panel, which is valuable prerequisite knowledge. It also implies direct access with no catalog validation, which is useful context.

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 concise, front-loaded with the core purpose and examples, and each sentence adds value: the purpose, the scope, and the permission requirement. No wasted words.

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 output schema exists, return values are covered. The description covers purpose, usage scope, and permissions, which is strong. However, with 0% schema coverage and no explanation of 'params' and 'business', an agent might not know how to construct those parameters correctly, leaving a minor gap.

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 schema has 0% description coverage, so the description carries the burden. It explains the 'path' parameter with examples, but provides no explanation for 'params' or 'business' parameters. Since the schema only gives types without semantics, the description partially compensates but is incomplete.

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 tool performs a GET on any Manager API path, with examples, and explicitly scopes it to paths the catalog does not model. This distinguishes it from other manager tools like manager_get and manager_list.

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?

It says to use only for paths the catalog does not model, which provides a clear condition. However, it doesn't explicitly say when not to use it (e.g., when the catalog does model the path) or mention alternatives like manager_get or manager_catalog.

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