Skip to main content
Glama
Matthieu-Pesnot-Pin

mcp-feature-analyzer

by Matthieu-Pesnot-Pin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

create_analysis

Freeze a feature's git diff for human review, covering branch or working-tree changes, and return an ID with changed files.

Instructions

Create an analysis once a feature is developed: computes and freezes the git diff of the repository for human review. In branch mode the diff is base...head (head defaults to HEAD); in working_tree mode it is the uncommitted changes, index included, against HEAD. Returns the id and the changed files; then read them with get_diff.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseNoBranch mode only, required: the ref the feature branched from, e.g. "master". Not accepted in working_tree mode.
headNoBranch mode only: the ref holding the feature (default HEAD). Not accepted in working_tree mode.
modeYesbranch: diff between two refs; working_tree: uncommitted changes against HEAD.
titleYesShort title of the feature, e.g. "OAuth token refresh".
projectYesProject the analysis belongs to: the product or feature name, used as its folder in the GUI. Reuse the exact name of an existing project (see list_analyses) for another analysis of it.
repo_pathYesAbsolute path of the root of the git repository.
request_textNoInitial request the feature answers (ticket, user prompt), shown to the reviewer.
request_sourceNoWhere the initial request comes from, e.g. a ticket id or URL. Needs request_text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.13

TDQS

A4.4/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 burden and does well: it discloses that the diff is 'frozen' (a persisted snapshot, not a live read), that working_tree includes the index, and what the return contains. It omits any permission/auth requirements or idempotency notes, keeping it short of a 5.

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?

Two sentences, front-loaded with the purpose, then the mode semantics, then the return/follow-up. No filler; each clause conveys a distinct fact.

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?

Covers mode behavior and return values even though no output schema exists, and notes the get_diff follow-up. Only minor gaps remain around permissions and long-term lifecycle, which siblings like get_analysis/delete_analysis imply.

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, but the description adds value by explaining the parameter interactions: base...head semantics with head defaulting to HEAD, and mode-dependent acceptance. It reinforces the schema rather than merely repeating it.

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?

States a specific verb and resource ('Create an analysis') plus the concrete effect of the operation ('computes and freezes the git diff of the repository for human review'). It also distinguishes itself from the sibling get_diff by routing the agent there for reading the results.

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 a clear trigger ('once a feature is developed') and points to the follow-up tool ('then read them with get_diff'). It stops short of stating when NOT to use it or naming alternatives beyond get_diff.

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