Compute edit distance between two strings and get a full backtrace of insert, delete, and replace operations to transform the source into the target.
Compute edit distance with full backtrace of insert/delete/replace operations.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source string (max 5,000 chars) | |
| target | Yes | Target string (max 5,000 chars) |
Changes observed during successful MCP inspections.
v0.1.11Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, but it is a pure deterministic computation with no auth, rate limits, or side effects to disclose. It adds useful context that the result includes an operation backtrace, yet says nothing about return structure or complexity limits (the char caps live only in the schema).
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 that names the operation and its output scope with no wasted words.
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 low-complexity two-string computation with fully documented parameters and no output schema, the description adequately covers what the tool does and roughly what it returns. It stops short of describing the backtrace format, but the tool is simple enough that this is a minor gap.
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% and both parameters (source, target) are fully documented, including the 5,000-char cap. The description adds no syntax or semantics beyond the schema, so the 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 ('compute'), resource ('edit distance'), and the output scope ('full backtrace of insert/delete/replace operations'). It is clear but does not differentiate itself from close siblings such as damerau_distance, hamming_distance, or string_distance, so an agent still needs outside knowledge to pick among 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?
Usage is only implied by the tool's name and the operation set. There is no explicit when-to-use and no pointer to alternative distance tools, so selection among the many distance/similarity siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.