List ingest keys (server keys are masked)

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: server keys are masked in the result, which tells the agent output will not contain usable secrets. It says nothing about ordering, pagination, or whether workspace-scoped keys are included.

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 front-loaded sentence with the key caveat in parentheses; nothing is padded. The trailing "(GET /v1/tracking/ingest-keys)" route restates implementation detail an agent cannot act on, which is the only wasted fragment.

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 zero parameters and no output schema, the description carries the burden of describing what comes back, and it only tells the agent that server keys are masked. It does not indicate what fields a key entry has (id, label, prefix, created date) or whether the list is workspace-scoped, leaving a real gap for a tool with no structured output definition.

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 baseline of 4 applies; there is nothing for the description to disambiguate. The schema is empty and fully consistent with a no-argument list call.

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?

"List ingest keys" gives a specific verb and resource, and the parenthetical clarifies the key type. It is clearly distinguishable from siblings like tracking_createIngestKey and tracking_revokeIngestKey by verb alone, though the description never names them explicitly.

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?

There is no when-to-use guidance, no mention of prerequisites or scopes, and no routing to alternatives such as tracking_getSettings or tracking_snippet. Usage is only inferable from the verb "List".

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