Search past incidents by symptom, optionally scoped to a service, to surface matching root causes and fixes for diagnosing similar production issues.
Search incident memory: full-text match on past symptoms, boosted when the past incident involved the same service. Returns root causes and what fixed them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| service | No | ||
| symptom | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, openWorldHint=false), and the description adds genuinely new behavior: the ranking is full-text with a service-affinity boost, and the response carries root causes and remediation. It does not mention pagination, empty-result behavior, or cost, but the ranking semantics are the non-obvious part and they are disclosed.
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, zero filler, purpose and mechanism front-loaded before the return-value note. Every clause earns its place.
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?
No output schema exists, and the description compensates by naming what is returned (root causes and fixes). Combined with annotations covering the read-only profile, this is nearly complete for a 3-parameter search tool; only limit/result-count behavior is left ambiguous.
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 parameter burden. It explains the semantics of 'symptom' (full-text match target) and 'service' (boost signal, not a filter), which is real value beyond the schema, but 'limit' is never mentioned and defaults (limit=3, service=null) go unaddressed.
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: 'Search incident memory' with full-text match on past symptoms and a service-based boost. The mechanism plus the stated return (root causes and fixes) makes the tool's function unmistakable, though it never explicitly names a sibling like explain_incident or rank_suspects to sharpen the boundary.
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 for triage-time recall of past incidents, but there is no statement of when to use it versus explain_incident, rank_suspects, or recent_changes, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.