Skip to main content
Glama
1tylermitchell

Sairen

by 1tylermitchell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

apply_fuzzy_patch

Apply fuzzy code search-and-replace patches that tolerate indentation shifts, whitespace drift, and minor line mutations, ensuring edits succeed despite imperfect matches.

Instructions

    [Cost: $0.0005 USDC on Base & Solana] Resilient fuzzy code search/replace patcher.
    Heals indentation shifts, whitespace drift, and minor line mutations that break LLM edits.

    Args:
        original_code: Full original file or source string.
        search_target: Code snippet or block to locate and replace.
        replacement_code: New code content to substitute in.
        min_similarity: Fuzzy line tolerance threshold (0.5-1.0, default: 0.75).
        language: Optional language for syntax validation ('python', 'json').
        payment_signature: Optional x402 Base/Solana USDC transaction hash (defaults to developer mock key).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languageNo
original_codeYes
search_targetYes
min_similarityNo
replacement_codeNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses cost, fuzzy-healing behavior, optional syntax validation, and the payment_signature default to a mock key. Yet it omits what the function returns, whether the original string is mutated in place, and failure behavior when no sufficiently similar match is found.

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

Conciseness4/5

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

The description is compact and front-loaded: cost and core purpose come first, followed by a tight parameter list. Each sentence adds information, though the arg list could be slightly tightened without losing meaning.

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

Completeness3/5

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

For a 6-parameter tool with no output schema and no annotations, the description covers invocation essentials well: pricing, all parameters, defaults, and optional syntax validation. However, it does not state the return value, error behavior, or whether the patch is purely functional, which leaves an agent uncertain about the tool's outcome.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Every parameter is explained with its meaning, format, constraints, or default: original_code as full source, search_target as the block to locate, min_similarity with range and default, language with allowed examples, and payment_signature with chain and mock-key behavior.

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

Purpose4/5

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

The description identifies a specific action ('fuzzy code search/replace patcher') on a specific resource (code), and adds distinguishing detail about healing indentation shifts and whitespace drift. It is clear but does not name or explicitly differentiate from sibling tools like repair_malformed_json or code_sandbox_tool.

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

Usage Guidelines3/5

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

The phrase 'that break LLM edits' implies this tool is for repairing failed or imperfect LLM-generated replacements, giving some usage context. However, there is no explicit guidance on when to prefer this over alternatives or when not to use it, leaving the agent to infer the selection rule.

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