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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false). The description goes beyond them by disclosing the metric families returned and an authorization behavior — cross-principal requests return 403 — which the agent would otherwise only discover at call time. It does not cover aggregation semantics or timestamping.

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 short sentences, both front-loaded with the most important information (whose metrics, which counters) and then the permission boundary. No filler, no repetition 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?

With an output schema present, return-shape explanation is unnecessary, and safety is covered by annotations. The description adds permissions and metric taxonomy, leaving only minor gaps such as window default behavior and aggregation granularity.

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 must carry the load. It partially does: 'over a window' gives the window parameter meaning and the 403 note touches on principal scoping. However the principal parameter remains genuinely confusing — its purpose and permitted values are undocumented, and the 403 note hints it is largely unusable for other principals without explaining why it exists.

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?

Specifies a concrete resource (the caller's own request metrics) and enumerates the exact counters returned — writes, no-op writes, 409s, 429s, 5xx, reads, embedding tokens. That is far more specific than the bare name. It stops short of naming how it differs from adjacent analytics siblings such as get_usage, get_budget or get_audit_view.

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 phrase 'over a window' implies the window selector, and 'Other principals' metrics are 403' tells the agent it can only fetch its own data. There is no explicit when-to-use guidance and no routing to or away from the sibling metric/usage tools, so selection still requires inference.

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