Merovingian MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| merovingian_registerA | Register a repository for contract scanning. Args: name: Unique name for the repository path: Filesystem path to the repository root contract_type: Contract type: 'openapi' or 'pydantic' (optional, auto-detect if omitted) |
| merovingian_scanA | Scan a registered repository and ingest its API contracts. Must be called after merovingian_register before contracts are visible. Safe to re-run — updates endpoints without deleting contract history. Args: name: Repository name (as registered with merovingian_register) |
| merovingian_add_consumerA | Register a consumer relationship between two repositories. Call this to tell Merovingian that consumer_repo calls an endpoint on producer_repo. Once registered, merovingian_impact will include this relationship in its blast radius analysis. Args: consumer_repo: Name of the repo that calls the endpoint (e.g. 'web-client') producer_repo: Name of the repo that owns the endpoint (e.g. 'api-server') endpoint_method: HTTP method (e.g. 'GET', 'POST') endpoint_path: Endpoint path (e.g. '/api/v1/transactions') |
| merovingian_consumersC | List consumers of endpoints. Args: producer_repo: Filter by producer repository name (optional) endpoint_method: Filter by HTTP method (optional) endpoint_path: Filter by endpoint path (optional) |
| merovingian_breakingC | Check for breaking changes in a repository's contracts. Args: repo_name: Name of the repository to check |
| merovingian_impactC | Full impact assessment with consumer mapping for a repository. Args: repo_name: Name of the repository to assess |
| merovingian_contractsC | List contract versions for a repository. Args: repo_name: Name of the repository limit: Maximum number of versions to return (optional, default 50) |
| merovingian_graphC | Query the dependency graph. Args: repo_name: Filter to a specific repository's dependencies (optional) |
| merovingian_feedbackB | Submit feedback on an assessment or change. Args: target_id: ID of the report or change to give feedback on outcome: One of: accepted, rejected, modified target_type: Type of target (e.g., 'report', 'change') (optional) context: Explanation of why (optional) |
| merovingian_auditC | Query the audit log of tool invocations. Args: tool_name: Filter by tool name (optional) since: Look back N minutes (optional) limit: Max entries to return (optional, default 50) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
The tools are largely distinct, each covering lifecycle stages (register, scan, add_consumer, breaking, impact). The only slight overlap is between `merovingian_consumers` and `merovingian_impact`, as both deal with consumers, but their focus differs (listing consumers vs. full impact assessment).
All tools follow a consistent `merovingian_<verb>` pattern with clear, descriptive verb choices (e.g., register, scan, add_consumer, breaking, impact). The naming is uniform and predictable.
With 10 tools, the count is well-scoped for a contract scanning and dependency analysis server. Each tool covers a distinct step in the workflow without being excessive or sparse.
The tool surface covers registration, scanning, dependency management, contract listing, breaking change detection, impact analysis, feedback, and audit. Minor gap: no tool to unregister a repository or delete consumer relationships, which could cause dead ends in cleanup scenarios.