Skip to main content
Glama
Matthieu-Pesnot-Pin

mcp-feature-analyzer

by Matthieu-Pesnot-Pin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_explanation

Change an explanation's title, body, or location. Provide a new location to check against the diff, making outdated explanations current; rewrite the body if code changed.

Instructions

Change one explanation: title, body or location. A new location (path and start_line, with side for removed code) is checked against the diff and makes an outdated explanation current again; rewrite the body too when the code changed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoWhat the code does (inputs, outputs, effects), then how it works, step by step in the order of the code. Describe, never judge. Plain text; line breaks are kept.
pathNoPath of a changed file of the analysis, relative to the repository root, as listed by get_diff.
sideNoSide of the diff the lines belong to (default "new"): "new" for added or kept code, with NEW-side numbers (second column of get_diff); "old" for removed code, with OLD-side numbers (first column of get_diff), all shown in the diff and at least one removed.
titleNoNew title.
end_lineNoLast described line, inclusive (default: start_line).
start_lineNoFirst described line, on the side given by side.
analysis_idYesId of the analysis, as returned by create_analysis or list_analyses.
explanation_idYesId of the explanation, as shown by get_analysis.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.13

TDQS

A3.6/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 and does disclose a genuinely non-obvious behavior: location updates are validated against the diff and can make an outdated explanation current again. However it says nothing about partial-update semantics (whether omitted fields are left unchanged), failure modes for an invalid location, or required permissions.

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?

Two tightly packed sentences, front-loaded with the core action and then the diff-validation consequence. Dense but every clause carries information; no filler.

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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the key behavioral twist (diff-checked location) but leaves partial-update semantics, error behavior, and return expectations unstated. Adequate but with clear gaps.

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 description coverage is 100%, so the schema already documents all eight parameters thoroughly. The description adds the useful framing that path/start_line/side form a single 'location' concept tied to the diff check, but does not extend the per-parameter meaning beyond what the schema provides.

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+resource ('Change one explanation') and enumerates the mutable facets (title, body, location), which cleanly separates it from the sibling update_analysis and update_finding tools. It does not explicitly name those siblings, so it stops short of a 5.

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?

Gives conditional usage guidance: a new location is diff-checked and can revive an outdated explanation, and the body should be rewritten when the code changed. This is actionable context, though it never states when-not to use the tool or names an alternative path.

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