Skip to main content
Glama
shuji-bonji

S1000D Writer MCP

by shuji-bonji
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

apply_fixes

Applies selected fix candidates to an existing S1000D data module, revalidates them, rejects mismatches, and returns verified XML plus remaining fixes.

Instructions

Apply fixes to an existing data module. Each selection copies the location and ONE candidate of a fix that s1000d-verify-mcp suggest_fixes (or this server) returned: { location, action, target?, value? }. The server computes the fix candidates again and applies a selection only if it matches one of them; a value outside the candidates (or outside a range / pattern candidate) is not applied and comes back in rejected[] with the reason. "provide" candidates change the product, not the document: pass them as "product". The result is verified again. Returns xml, applied[], rejected[], verification, the fixes that remain. Writes only when write is true (a path is overwritten in place; xml is written under its own file name in the first CSDB folder).

Input Schema

NameRequiredDescriptionDefault
xmlNoAn existing document as an XML string (alternative to path; max 5 MB). Not for XML you wrote yourself: build new data modules with build_data_module.
pathNoFile path of the document.
writeNoWrite the result into the CSDB (the first folder of csdbDirs / S1000D_CSDB_DIR). Default false: the XML is only returned. Nothing is written when the XML is not valid against the XSD unless allowInvalid is true.
productNoThe product to evaluate applicability for. attributes: ACT productAttribute id → value; conditions: CCT cond id → value. Omit to skip the applicability check.
csdbDirsNoCSDB folders (in addition to S1000D_CSDB_DIR) used to resolve references, find BREX and number new objects. The FIRST folder is also where write: true writes.
maxFixesNoCap on the remaining fixes listed in the response (default 50).
overwriteNoWith write: true, replace a file of the same name. Default false: an existing file is left alone and reported as write-conflict.
selectionsYes
allowInvalidNoWith write: true, write even when verification.schema.state is "invalid". Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full load and does well: it discloses that candidates are recomputed and selections validated against them, that failures come back in rejected[] with a reason, that provide changes the product rather than the document, that output is re-verified, and that nothing is written unless write is true. It omits permission/auth requirements and any note on partial-apply atomicity.

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?

Purpose is front-loaded and nearly every sentence adds operational information. The middle sentences are dense and parenthetical-heavy, which slows parsing, but there is little outright waste.

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

Completeness4/5

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

For a 9-parameter tool with nested objects and no output schema, the description compensates by enumerating the return payload (xml, applied[], rejected[], verification, remaining fixes) and the write/overwrite conditions. A short note on failure modes when selections partially match or on the CSDB folder resolution would close the remaining gap.

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

Parameters3/5

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

Schema coverage is already 89%, so the schema documents most parameters on its own. The description adds meaningful semantics for selections (location + one candidate, action/target/value) and the provide→product mapping, but does not touch path, csdbDirs, or maxFixes beyond what the schema says.

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?

States a specific verb and resource ("Apply fixes to an existing data module") and ties it to the upstream suggest_fixes output shape, so an agent knows this is the selection/commit step. It does not differentiate from the listed sibling apply_segments, which is a plausible source of confusion.

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?

Implicitly and explicitly establishes the workflow: take a location plus ONE candidate returned by suggest_fixes and pass it back, with "provide" candidates routed through the product parameter. It gives a clear condition for rejection but no explicit statement of when to prefer this over alternatives or when not to use it.

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