Skip to main content
Glama
Matthieu-Pesnot-Pin

mcp-feature-analyzer

by Matthieu-Pesnot-Pin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

set_diagram

Create or replace a code-review diagram from nodes and links to map impact, process flow, or concepts; the GUI lays it out and colors nodes by status.

Instructions

Create a diagram, or fully replace the one with diagram_id, when a picture helps the reviewer (impact perimeter, process flow, concept map). Give nodes and links only, with no coordinates or colours: the GUI lays the diagram out and colours nodes by status. flow = a process with steps and decisions, laid out left to right along the links, where a side branch without a join and the last node of a chain hang below the node before them; layers = the impact perimeter, one column per entry of layers (e.g. GUI, API, core, storage), each node in its layer; mindmap = a tree of concepts drawn radially around its root: exactly one root, one incoming link for every other node, no cycle (refused otherwise). Rules: one subject per diagram, 5 to 12 nodes; declare nodes in reading order, since the declaration order is the initial order of every rank or column; zero crossings expected. The result reports every link crossing and every link through a node, with advice: reorder the nodes, split the diagram or change its kind, then send it again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesflow = a process with steps and decisions, laid out left to right along the links, where a side branch without a join and the last node of a chain hang below the node before them; layers = the impact perimeter, one column per entry of `layers` (e.g. GUI, API, core, storage), each node in its layer; mindmap = a tree of concepts drawn radially around its root: exactly one root, one incoming link for every other node, no cycle (refused otherwise).
linksNoDirected links between nodes (default: none). In a mindmap, from parent to child.
nodesYesNodes in reading order (5 to 12): the declaration order is the initial order of every rank or column.
titleYesTitle of the diagram.
layersNoRequired when kind is layers, forbidden otherwise: column names from left to right.
diagram_idNoId of the diagram to replace, or of the new one; generated when omitted.
analysis_idYesId of the analysis, as returned by create_analysis or list_analyses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.13

TDQS

A4.2/5.0
Behavior5/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 so: it discloses the destructive 'fully replace' semantics of passing diagram_id, the division of labour (agent supplies nodes/links only, GUI handles layout and status colours), composition rules (one subject, 5-12 nodes, zero crossings), refusal conditions (mindmap with a cycle or multiple roots), and what the response reports back with remediation advice.

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

Conciseness3/5

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

It is front-loaded with purpose and the three kind behaviors, which is good, but it is very dense and a large share of it duplicates the `kind` and `nodes` schema descriptions word-for-word. Those sentences do not earn their place given they are already structured-field content.

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 complex 7-parameter tool with no annotations and no output schema, the description covers kinds, composition constraints, replacement semantics, and the shape of the returned crossing/advice feedback, which compensates for the missing output schema. Minor gaps remain around permissions and the mismatch between the schema's minItems and the stated 5-12 node rule.

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 baseline is 3. The description largely restates schema content -- the `kind` enum text and the nodes reading-order/5-to-12 wording appear verbatim in the schema -- and adds only marginal extras such as 'no coordinates or colours' and 'declare nodes in reading order'. It does not compensate for the schema's misleading minItems of 1 versus the stated 5-12 range.

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 first clause names a specific verb and resource ('Create a diagram, or fully replace the one with diagram_id') and adds the reviewer-facing purpose. An agent can immediately tell this is the diagram-creation/replacement tool, distinct from delete_diagram in the sibling list.

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?

It gives a clear when-to-use trigger ('when a picture helps the reviewer') with concrete examples (impact perimeter, process flow, concept map) and explains which `kind` fits which situation. It stops short of explicit when-not guidance or naming alternatives such as emitting findings or explanations instead.

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