text_diffLine diff of two texts as a unified diff with added/removed counts. Computes a minimal line-based diff (LCS) between two texts and returns unified-diff hunks with configurable context, plus counts of added and removed lines. Up to 5,000 lines per side. Price: $0.003 USDC per call via x402 (eip155:8453).
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| context | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered; the description adds real behavioral context on top: the algorithmic basis (LCS), the return contents (hunks plus added/removed counts), the 5,000-line-per-side limit, and the x402 payment requirement. It stops short of stating truncation behavior when the limit is exceeded, which is the one notable gap.
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?
Three sentences, front-loaded with the core purpose before algorithm, limits, and pricing. Slight redundancy between the title-like opening and the rest, but no sentence is wasted.
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 no output schema, the description correctly takes on the job of describing returns (unified hunks, added/removed counts) and adds cost and size limits. An agent could call this confidently; only the a/b parameter meaning and overflow behavior are left implicit.
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 burden falls on the description, and it only partially compensates: it names 'configurable context' and states the line limit per side, but never explains that 'a' and 'b' are the old/new texts or how 'context' affects hunk size. The schema itself supplies defaults, min/max, and length caps, so the description adds only marginal meaning.
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?
The first sentence names the verb ('line diff'), the resources ('two texts'), and the output form ('unified diff with added/removed counts'), which immediately separates it from the sibling json_diff. The follow-up sentence pins down the algorithm (LCS) and output shape (hunks), leaving no ambiguity about what the tool does.
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: 'line diff of two texts' suggests plain-text comparison, and the 5,000-line cap hints at expected input size. However, there is no explicit statement about when to prefer this over json_diff or text_stats, and no exclusions or prerequisites are listed beyond the pricing note.
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.