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

Annotations already declare readOnlyHint, idempotentHint, non-destructiveHint and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral fact — that calling it is not required before a normal design request — but says nothing about result size, stability of the reported limits, or whether values are account-specific.

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?

Two sentences, front-loaded with the purpose and followed by the caveats, with no redundant restatement of the title. The phrase "when needed" is the only filler that does not carry real information.

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?

A zero-parameter read tool with an output schema and full annotation coverage needs little prose, and the exclusions are a real contribution. Still, an agent cannot tell from the text what scope of capabilities is reported (this account, this workspace, or the product generally), which is the one thing the description should have settled.

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 tool takes zero parameters, so the schema baseline of 4 applies. The description correctly implies no input is needed by framing the call as a discovery/lookup, and adds no misleading parameter guidance.

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?

"Discover available engineering workflows and limits" gives a verb and a rough resource, but "capabilities" remains broad and the description never says what category of information is returned (e.g. supported operations, quotas, feature flags). It distinguishes the tool from troubleshooting and design requests, yet does not differentiate it from capability-adjacent siblings such as get_workflow or get_tool_schema.

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 supplies two explicit exclusions: not a prerequisite for an ordinary design request, and not for connection troubleshooting, which meaningfully narrows invocation. The positive trigger is only "when needed", which is circular, and no alternative tool is named for the troubleshooting case, so it stops short of a full when/when-not/alternative map.

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