Compare two request executions by audit record ID to identify metric changes and structural JSON response body differences in table or unified diff format.
Compare two request executions, checking metrics and structural JSON response body differences.
| Name | Required | Description | Default |
|---|---|---|---|
| id1 | Yes | First audit record ID | |
| id2 | Yes | Second audit record ID | |
| format | No | Diff output format: table (default) or unified (compact diff style) | table |
Changes observed during successful MCP inspections.
v1.0.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description carries the full burden. It does disclose a meaningful behavioral trait — the body comparison is *structural* (schema/shape), not value-by-value, which prevents misuse. However it omits that this is a read-only operation, what happens if an ID does not exist or lacks a JSON body, and any limits on size of records compared.
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 no filler; the what and the compared facets arrive immediately.
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 three-parameter read/compare tool with full schema coverage and no output schema, the description is minimally sufficient but does not describe the shape of the diff result (e.g. table vs unified rendering, how metric deltas are presented), and no output schema exists to compensate.
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 100%: id1/id2 are labeled 'audit record IDs' and format has an enum with per-value explanation, so the schema does the heavy lifting. The description adds no extra semantics (e.g. whether IDs must belong to the same request or can be arbitrary), 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 (compare) and two specific resources (request executions), then narrows what facets are compared: metrics and structural JSON body differences. That is far more informative than the sibling history_get/history_list names imply, though it never explicitly contrasts itself with them.
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 or when-not-to-use guidance, and no mention of the obvious alternatives (history_get to inspect a single record, history_list to find IDs). The agent must infer that id1/id2 come from history_list and that this tool is the diffing path rather than a lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.