Read an alert
fleet__get_advisoryFetch a single advisory with full lifecycle detail (resolved/dismissed timestamps included).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| advisory_id | Yes | The advisory id to fetch. |
fleet__get_advisoryFetch a single advisory with full lifecycle detail (resolved/dismissed timestamps included).
| Name | Required | Description | Default |
|---|---|---|---|
| advisory_id | Yes | The advisory id to fetch. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description earns credit for adding response-content behavior the annotations cannot express: that resolved/dismissed timestamps are included, i.e., the record is not filtered to open advisories.
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 with no filler, and the most decision-relevant content (single advisory, full lifecycle detail) is front-loaded. The parenthetical clarifies the only ambiguous phrase rather than padding it.
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?
For a one-parameter, annotated, read-only tool with no output schema, the description tells the agent what it gets back (full lifecycle detail including resolution/dismissal timestamps), which is the main open question. Minor gap: no mention of not-found error behavior.
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?
Only one parameter exists and schema description coverage is 100% ("The advisory id to fetch."), so the schema already does the work. The description adds nothing about the id format (uuid) or what happens with an unknown/foreign id, so baseline 3 applies.
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?
States a specific verb and resource ("Fetch a single advisory") plus a scope qualifier ("full lifecycle detail"), which implicitly contrasts with the list-style sibling fleet__list_advisories. It stops short of naming the sibling explicitly, so an agent must infer the list-vs-single split from the word "single".
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?
Usage is only implied: an agent can infer this is the detail lookup to run once an id is known (e.g., after fleet__list_advisories or fleet__security_triage). There is no explicit when-to-use/when-not guidance and no alternative named, even though acknowledge/dismiss/resolve siblings are the obvious follow-on actions once this is read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.