Skip to main content
Glama
KnockOutEZ

wigolo

by KnockOutEZ
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

diff

Read-onlyIdempotent

Compare two Markdown bodies or cached URL fetches to return unified, hunk, or summary changes at line, word, or section granularity.

Instructions

Compute a diff between two markdown bodies or two URL fetches.

Key parameters:

  • old: { url?, markdown?, content_hash? } — left-hand side. URL form reads from cache; cache miss returns a structured cache_miss error (no network re-fetch).

  • new: { url?, markdown? } — right-hand side. Same cache rules as old.

  • output: 'unified' (default, git-style patch) | 'hunks' (structured array) | 'summary' (line counts only).

  • granularity: 'line' (default) | 'word' | 'section'. Section walks H1/H2/H3 boundaries and tags each hunk with section_title.

Returns { changed, summary, unified_diff?|hunks?, truncated? }. summary always present (added/removed/modified lines + total_changed_chars). Above the 5000-line cap the engine emits truncated: true plus an approximate summary — never silently degrades.

Input Schema

NameRequiredDescriptionDefault
newNoRight-hand side of the diff. Requires one of { url, markdown }.
oldNoLeft-hand side of the diff. Requires one of { url, markdown, content_hash }.
outputNoDiff output shape. unified=git-style patch, hunks=structured per-section, summary=counts only (added_lines / removed_lines / modified_lines / total_changed_chars where total_changed_chars = sum of added_line_chars + removed_line_chars across the LCS edit script). Default: unified.
granularityNoDiff granularity. line=per-line LCS (default). word=token-level LCS — hunks contain only the changed tokens, tighter than line for intra-line edits. section walks H1/H2/H3 boundaries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.1
  2. Removedv0.2.0
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses important behavior: URL inputs read from cache, cache misses return a structured `cache_miss` error with no network re-fetch, and diffs over 5000 lines are truncated with an approximate summary rather than silently degrading. These are meaningful operational details not covered by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then uses compact bullet points for parameters, output modes, and return shape. Every section carries operational value without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the nested parameters, lack of an output schema, and read-only annotations, the description is complete enough to invoke the tool correctly. It covers input forms, cache miss behavior, output modes, truncation limits, and return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema, especially that `old.url` reads from cache and can produce a structured `cache_miss` error, and that `section` granularity tags hunks with `section_title`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Compute a diff between two markdown bodies or two URL fetches.' This clearly distinguishes it from sibling tools such as fetch, crawl, and extract, and an agent can identify its operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear contextual guidance for invoking the tool, including cache behavior for URL inputs and how to choose output and granularity. It does not explicitly name alternatives or say when not to use this tool, so it falls short of the full when/when-not/alternatives standard.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools