inspect_endpoint_health

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

No annotations are supplied, so the description carries the full disclosure burden. Calling it "Inspect" implies a non-mutating read, which is meaningful, and the enumeration of measured signals tells the agent what data exists; however, nothing is said about the rolling window, refresh/polling cost, whether queries are cheap, or what a circuit-breaker state transition implies operationally.

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?

A single sentence that is front-loaded with the verb and then lists the exact signals returned, with no filler, hedging, or repeated information. The tri-state enumeration in parentheses is an efficient way to convey the return vocabulary.

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?

With no output schema and no annotations, the description does the necessary work by naming the metrics returned and the scoping behavior for the one parameter. It falls slightly short on the time window for "rolling" error rates and latency averages, and on whether the result is a snapshot or aggregated history.

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 single optional endpoint_id is fully documented in the schema (100% coverage), including the "omit to inspect all" semantics, so the schema does the heavy lifting. The description adds only the phrase "registered model endpoints," which slightly clarifies the identifier domain but does not explain ID format or what happens with an unknown ID.

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?

Specific verb ("Inspect") plus a concrete enumeration of the four signals it surfaces: circuit breaker tri-state, rolling error rates, HTTP 429 counters, and EMA latency, scoped to "registered model endpoints." It is clear what the tool does, though it never distinguishes itself from siblings such as synapse_rate_limit_status or check_budget_status, whose domains partially overlap with the 429 and budget-related content.

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?

No when-to-use, when-not-to-use, or alternative-routing guidance is given; the description never mentions the sibling tools or the conditions under which an agent should prefer this inspection over rate-limit or budget status checks. The diagnostic intent is inferable from "Inspect," but the agent must guess at the decision boundary.

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