Merovingian MCP Server

by evo-hydra

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation4/5
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).
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 10 of 10 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action without indicating whether the tool has side effects, requires authentication, or is read-only. The simple action 'check' suggests non-destructive behavior, but this is not explicitly stated.
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?
The description is concise with two sentences, front-loading the purpose. Every sentence adds value, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so return values are covered. However, the description lacks usage guidelines, behavioral transparency, and context about what 'breaking changes' or 'contracts' refer to, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a brief explanation for repo_name: 'Name of the repository to check.' This adds only slight clarification beyond the schema title 'Repo Name' and does not provide richer semantics like format, examples, or constraints.
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?
The description clearly states the tool's purpose: 'Check for breaking changes in a repository's contracts.' The verb 'check' and the specific resource 'breaking changes in contracts' make it distinct from sibling tools like merovingian_scan or merovingian_impact, though it does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the nine sibling tools. It does not mention prerequisites, context, or situations where alternatives like merovingian_scan would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions filtering by repo_name but does not state whether the tool mutates state, requires authentication, or returns only direct vs transitive dependencies. With no annotations, this is insufficient.
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?
The description is very short, with a one-sentence core purpose and an Args section that directly addresses the parameter. It is front-loaded and efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional parameter) and presence of an output schema, the description could be more complete. It fails to specify the output format, pagination, or error conditions, and lacks context about the graph's structure. An output schema exists but the description doesn't hint at the response structure.
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 description coverage is 0%, meaning the schema provides no docstrings for the parameter. The description partially compensates by stating that repo_name is optional and filters the query to a specific repository's dependencies. This adds meaningful semantic value beyond the bare schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it queries the dependency graph, which is a clear verb+resource pair. However, the description is minimal and doesn't elaborate on what querying entails or how it distinguishes from sibling tools like merovingian_impact or merovingian_breaking. The purpose is adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Siblings like merovingian_breaking, merovingian_impact, and merovingian_consumers suggest different query contexts, but the description gives no clues about differentiation or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states 'Query', implying a read-only operation, but does not explicitly declare that it is non-destructive or what permissions are required. For a tool with zero annotation coverage, this omission leaves an agent uncertain about side effects.
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?
The description is extremely concise: one line for the purpose, then a clean parameter list. No extra words or redundancy. All text serves its purpose, making it efficient for an agent to parse.
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?
The tool is simple with 3 optional parameters and an output schema covering return values. The description covers purpose and parameter semantics adequately. However, the lack of behavioral guarantees and usage guidelines leaves gaps, especially given the absence of annotations. It is minimally viable but not fully complete.
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?
The input schema has 0% description coverage (only titles), so the description is essential. It briefly explains each parameter: 'Filter by tool name (optional)', 'Look back N minutes (optional)', 'Max entries to return (optional, default 50)'. This adds meaning beyond the bare schema titles, but the explanations are minimal (e.g., 'N minutes' lacks precision). Adequate but not rich.
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?
The description uses a specific verb 'Query' and resource 'the audit log of tool invocations', clearly stating the tool's function. While it does not explicitly differentiate from sibling tools like merovingian_register or merovingian_scan, the name and description are sufficiently distinct for an agent to understand its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contains no information about when to use this tool, prerequisites, typical use cases, or alternatives. It only lists parameters. For an audit query tool, one would expect guidance on its role (e.g., 'to review past invocations'), but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool lists consumers and offers optional filters. It does not disclose whether the operation is read-only, what the output format is (despite the presence of an output schema), whether pagination or authentication is required, or any side effects. The minimal description leaves significant behavioral gaps.
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?
The description is concise (two sentences plus a parameter list) and front-loaded with the purpose. Every sentence adds value. However, it could be slightly more structured by separating the parameter list more clearly or using bullet points, but it is still efficient and readable.
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?
Given the tool has 3 optional parameters and an output schema, the description is minimally complete: it states the purpose and the filter parameters. However, it does not describe the return values (the output schema is not detailed), any prerequisites, or the broader context of how consumers relate to endpoints. For a straightforward listing tool, this may be adequate but leaves room for improvement.
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?
The input schema has 0% description coverage, so the schema itself provides no parameter explanations beyond type and title. The description adds brief textual explanations for each parameter (e.g., 'Filter by producer repository name (optional)'), which clarifies their purpose. However, the explanations are minimal and do not specify valid values, formats, or constraints, leaving room for ambiguity.
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?
The description clearly states the tool's purpose: 'List consumers of endpoints.' This is a specific verb+resource combination that distinguishes it from sibling tools like merovingian_add_consumer (which adds consumers) and merovingian_scan (which likely scans for something else). However, the description does not explain what 'consumers' are in this context, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings. It does not mention when it is appropriate to list consumers, nor does it indicate when one should use alternatives like merovingian_add_consumer or merovingian_impact. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'List' implying a read-only operation, but does not explicitly confirm idempotency or absence of side effects. It fails to mention authentication requirements, rate limits, or any constraints on repository access. The presence of an output schema is not leveraged to explain return behavior.
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?
The description is concise: a clear one-line purpose followed by a structured Args list. It is front-loaded with the main action and avoids unnecessary elaboration. Every sentence serves a purpose, though the Args section could be integrated more elegantly. Overall, it is well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description does not mention what data the tool returns (e.g., fields, structure). For a listing tool, understanding the return value is critical for agent planning. The description also omits context on pagination, sorting, or whether the list is exhaustive. Given the tool's simplicity, the description is incomplete for fully informed invocation.
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 0%, so the description must compensate. It provides basic explanations for both parameters: repo_name is 'Name of the repository' and limit is 'Maximum number of versions to return (optional, default 50).' This adds value over the schema, particularly clarifying the default behavior for limit (though the schema has default null). However, it does not explain what 'versions' are or provide context on expected input format for repo_name, leaving some ambiguity.
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?
The description uses the verb 'List' and the resource 'contract versions' with scope 'for a repository,' which clearly indicates the tool's purpose. It distinguishes from sibling tools like 'merovingian_register' and 'merovingian_scan' by focusing on listing versions rather than registration or scanning. However, it could be more specific about what constitutes a 'version' to fully differentiate from other listing tools like 'merovingian_consumers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for use, or scenarios where this tool is preferred over siblings like 'merovingian_audit' or 'merovingian_impact.' This lack of usage context forces the agent to infer applicability solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does not disclose if the tool is read-only, modifies state, requires permissions, or has side effects. 'Impact assessment' suggests analysis but lacks specifics on cost, rate limits, or dependencies.
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 with an Args line, front-loaded purpose, no redundancy. Every sentence serves a purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 'full impact assessment' tool, the description is too sparse. It does not explain what 'impact' entails, what the output contains (despite an output schema), or any operational context (e.g., whether the repo must be registered first). The agent would need more to use it effectively.
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 0%, but the description adds meaning by stating 'repo_name: Name of the repository to assess' beyond the type-only schema. The addition is clear but minimal, providing basic clarification.
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?
The description states 'Full impact assessment with consumer mapping for a repository,' providing a specific verb and resource. It implies differentiation from siblings like merovingian_scan or merovingian_breaking, but does not explicitly distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or when-not conditions. The description relies on the tool name for context, which is insufficient for an agent to choose correctly among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavioral traits. It only says 'submit feedback' without disclosing side effects (e.g., whether feedback is stored, immutable, triggers notifications) or required permissions. The minimal description leaves significant behavioral ambiguity.
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?
The description is concise: one sentence for purpose followed by a compact parameter list. Every sentence is informative. The structure could be improved with a markdown table or bulleted list, but it remains clear and efficient, earning a high score.
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?
The description covers the basic action and parameters, but leaves gaps: no mention of the output schema (which exists), no constraints on target_id validity, and no behavioral effects of submitting feedback. Given the lack of annotations and a moderate number of parameters, the description is adequate but not fully self-contained.
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?
With 0% schema description coverage, the description compensates by explaining all four parameters: target_id ('ID of the report or change'), outcome ('One of: accepted, rejected, modified'), target_type ('Type of target (e.g., report, change)'), and context ('Explanation of why'). This adds crucial meaning beyond the bare schema types. However, it could explicitly list outcome as an enum and mention format constraints for target_id.
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 description 'Submit feedback on an assessment or change' uses a specific verb + resource, clearly indicating the tool's action and domain. It distinguishes itself from sibling tools (register, scan, add_consumer, etc.) by being the only feedback-related operation. The mention of target types ('report' or 'change') further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., must a report or change exist first?), or scenarios where feedback is inappropriate. The description simply states the action without contextualizing its role in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description indicates 'register' (write side effect) but does not detail what happens on success, whether existing registrations are rejected or overwritten, or what authorization is needed (e.g., filesystem write access to the given path). Since the tool performs a write operation, such information is important. The score is 3 because there is no contradiction with annotations (none exist), but the description is still somewhat incomplete about behavioral implications.
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?
The description is concise and structured well. The tool purpose is stated in a single sentence, followed by a clearly delineated parameter list. No extraneous text. However, it could be even more concise by avoiding the 'Args:' heading and using inline formatting, but this is a minor point. The overall readability is high.
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?
Given 3 parameters (only 2 required), no annotations, but a present output schema (which could provide return value details), the description does a reasonable job covering the inputs. However, it fails to mention what the tool returns (the output schema might cover that, but the description doesn't hint at it), and it doesn't clarify the link to other tools like merovingian_scan. For a registration tool, context like 'this is a prerequisite for scanning' is important completeness.
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 description coverage is 0%, so the description must compensate. It does a good job by listing all three parameters with explicit explanations: 'name: Unique name for the repository', 'path: Filesystem path to the repository root', 'contract_type: Contract type (optional, auto-detect if omitted)'. This adds significant value beyond the bare schema (which only has titles). The score is 4 (not 5) because the 'contract_type' values could be spelled out more clearly as an enum, but the current text is already helpful.
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 description starts with a clear and specific verb+resource phrase: 'Register a repository for contract scanning.' This immediately distinguishes it from tool names like 'merovingian_scan' (which suggests scanning, not registration) and other siblings. The purpose is unmistakable and well-stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The tool is likely a prerequisite for 'merovingian_scan', but the description does not explain that. It also does not mention when you might want to skip registration (e.g., if the repo is already registered) or what happens if you re-register a repo (error vs. update). Context like 'only required once per repo' would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is safe to re-run and updates endpoints without deleting contract history, indicating idempotency and non-destructiveness. However, it does not mention authorization needs, rate limits, or error behavior when the prerequisite is not met, leaving some gaps.
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?
The description is concise (three sentences plus an Args block) and front-loaded with the purpose. Every sentence adds value: purpose, prerequisite, idempotency, parameter explanation. No wasted words.
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 tool with one required parameter and an output schema, the description covers the essential points: purpose, prerequisite, safety, and parameter semantics. It does not detail the output format (unnecessary due to output schema) or error conditions, but the overall completeness is high for a simple tool.
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?
The input schema has 0% description coverage, so the description must compensate. It explains the 'name' parameter as 'Repository name (as registered with merovingian_register)', adding crucial context that the name must match a previously registered repository. This is sufficient for a single parameter.
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 description clearly states the action ('Scan a registered repository') and the outcome ('ingest its API contracts'). It distinguishes itself from sibling tools by mentioning the prerequisite (after merovingian_register), which implies a unique step in the workflow.
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?
The description explicitly states when to use the tool: 'Must be called after merovingian_register before contracts are visible.' It also notes that it is safe to re-run, providing idempotency guidance. However, it does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool registers a relationship and that this registration feeds into blast radius analysis, confirming it is a mutation. However, it does not mention idempotency, error behavior on duplicates, authentication requirements, or whether the operation is destructive. The description adds some context but misses important behavioral traits for a tool with no annotation safety net.
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?
The description is concise: a one-sentence purpose, a one-sentence usage context, and a clean Args list. No unnecessary words or repetition. The critical information is front-loaded. Every sentence adds value.
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?
The description covers the tool's purpose, when to call it, and all parameter meanings. An output schema exists (mentioned in context signals), so the lack of return details is acceptable per guidelines. However, it omits information on error scenarios (e.g., duplicate relationships) and any prerequisites. For a registration tool with no annotations and four required params, it is largely complete but could be slightly more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a detailed Args section with explanations and example values for each of the four parameters ('consumer_repo', 'producer_repo', 'endpoint_method', 'endpoint_path'). Each parameter is clearly defined (e.g., 'Name of the repo that calls the endpoint (e.g. 'web-client')'). This fully compensates for the bare schema.
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 description clearly states the tool's purpose: 'Register a consumer relationship between two repositories.' It uses specific verbs and resources, and the subsequent sentence ('Call this to tell Merovingian that consumer_repo calls an endpoint on producer_repo') provides concrete detail. The sibling tools include 'merovingian_consumers' (likely list) and 'merovingian_impact' (analysis), so this tool's distinct role is well-defined.
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?
The description provides explicit context for when to call this tool: before impact analysis, to register a dependency. It also explains the consequence ('merovingian_impact will include this relationship'). However, it does not mention when not to use it or suggest alternative tools among the siblings (e.g., maybe 'merovingian_register' for other registrations). The guidance is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![merovingian MCP server](https://glama.ai/mcp/servers/evo-hydra/merovingian/badges/card.svg)](https://glama.ai/mcp/servers/evo-hydra/merovingian)

Score Badge

Copy to your README.md:

[![merovingian MCP server](https://glama.ai/mcp/servers/evo-hydra/merovingian/badges/score.svg)](https://glama.ai/mcp/servers/evo-hydra/merovingian)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/evo-hydra/merovingian'

If you have feedback or need assistance with the MCP directory API, please join our Discord server