vunit-mcp

by ru551n

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.0
Disambiguation5/5
Each tool targets a distinct concern: configuration health, test listing, file listing, compilation, running, report retrieval, per-test logs, JSON export, and dependency resolution. There is no meaningful overlap even between get_report and get_test_log because one is the aggregate results summary and the other is the raw output for a single test.
Naming Consistency4/5
All tools share the vunit_ prefix and mostly follow a verb_noun pattern (list_tests, list_files, run_tests, get_report, get_test_log, export_json). Minor deviations like vunit_status and vunit_compile are still readable and do not create confusion.
Tool Count5/5
Nine tools is well-scoped for a VUnit test project workflow. Each tool covers a distinct step from inspection and compilation through running tests and debugging failures, and none feels redundant or extraneous.
Completeness5/5
The tool set covers the full practical VUnit workflow: diagnosing setup, discovering tests and files, compiling, running, retrieving aggregate results, inspecting per-test logs, exporting project data, and tracing test dependencies. There are no obvious dead ends that would prevent an agent from completing a typical build-and-debug cycle.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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 Mozilla Public License 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint=false, openWorldHint=false), so the description carries the transparency burden. It discloses the always-written JUnit XML, the pattern default, and the simulator requirement—useful behavioral facts. However, it omits other side effects like filesystem changes or potential long-running execution.
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?
Three sentences with no redundancy: the first states the core action and result, the second explains the default patterns, and the third notes the JUnit XML location and simulator requirement. Every sentence earns its place.
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?
Despite many parameters, the description covers the essential operation, its output, a key artifact, and a prerequisite. The output schema exists, so return-value details are handled. A minor gap is not mentioning the compile prerequisite, but the sibling vunit_compile makes that obvious.
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?
Top-level schema description coverage is 0%, so the description must compensate for parameter guidance. It mentions only the test_patterns default and leaves the other eight parameters to the nested schema. This is insufficient given the low coverage signal.
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 opens with a clear verb+resource: 'Run VUnit tests', and specifies the outputs: a pass/fail summary and the list of failing tests. It also distinguishes itself from the sibling vunit_get_report by noting the JUnit XML is written for that tool, making the purpose unmistakable.
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 provides practical context: default test patterns ('*' runs everything), a prerequisite ('Requires a simulator'), and a pointer to vunit_get_report for the report artifact. It does not explicitly state when not to use it, but the 'for vunit_get_report' hint implies the companion flow.
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?
Annotations already mark idempotentHint=true and readOnlyHint=false; the description adds the simulator requirement and the 'all sources' scope, but does not describe side effects on build artifacts or what happens if the simulator is unavailable. It aligns with idempotency rather than contradicting it.
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 short sentences carry the primary action, scope, prerequisite, and safety property with no filler. Useful information is front-loaded in the first sentence.
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 parameterless tool with an output schema and safety annotations, the description is largely sufficient. It could be stronger by placing the tool in the VUnit workflow (compile before run_tests) and by noting build-artifact side effects, but nothing essential is missing for invocation.
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 tool has zero parameters and the schema documents 100% of them (none), so the description does not need parameter-level detail. Baseline for zero params applies.
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 names the action ('Compile') and the exact scope ('all sources in the VUnit project'), and anchors it to the CLI flag --compile. This is clearly distinct from sibling tools such as list_files, run_tests, and status.
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 context and prerequisite: the command requires a simulator, and re-running is safe. It does not explicitly contrast with siblings or say when not to use it, but an agent can infer this is the build/pre-step versus run_tests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false. The description goes beyond this by revealing non-obvious behavior: the export is cached at .vunit-mcp-cache/export.json and re-run only when project sources change. It also discloses that no simulator is required. These are meaningful behavioral traits not captured in the annotations.
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?
Three short sentences, each earning its place: purpose and contents, attribute meaning, and caching/no-simulator behavior. There is no redundancy, fluff, or repetition of what the schema or annotations already convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only export tool with an output schema, the description is complete. It tells the agent what is exported, that the result is cached and when it is refreshed, and that no simulator is required. Nothing an agent needs to correctly invoke this tool is missing.
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 tool has zero parameters, so the description carries no parameter semantics burden. Schema coverage is trivially complete. The baseline for a 0-parameter tool is 4, and the description appropriately omits parameter information that would be irrelevant.
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 opens with a specific verb and resource: 'Export the project model (source files, all tests, attributes) as JSON.' It enumerates what is included, mentions the exact CLI flag (--export-json), and even notes that attributes carry requirement/traceability data. This clearly distinguishes it from siblings like vunit_list_tests or vunit_list_files, which only cover subsets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context such as 'Does not require a simulator' and the caching re-run condition, which helps an agent understand when the tool is feasible. However, it never explicitly tells the agent when to choose this tool over alternatives like vunit_list_tests or vunit_list_files, nor names them. The usage guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds non-obvious behavioral context: the listing is in compile order and needs no simulator. This goes beyond the schema and annotations, though it doesn't detail output format or failure modes; given the output schema and read-only annotation, this is sufficient.
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 short sentences with no filler. The core function is stated first, followed by a useful environment note; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema, the description covers what the tool does and a key environmental constraint (no simulator needed). Nothing required to call it correctly is missing.
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 tool has zero parameters, so the empty schema fully documents the interface. The baseline for 0 parameters is 4; there is no parameter information the description would need to compensate for.
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 uses a specific verb ('List') and identifies the resource ('all source files') plus an ordering property ('in compile order'). It clearly differentiates from the sibling vunit_list_tests, which lists tests rather than source files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Does not require a simulator' gives useful usage context, indicating the tool works without simulator setup. However, it does not explicitly contrast this tool with alternatives like vunit_list_tests or vunit_compile, so when-to-use guidance remains implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only behavior; the description adds useful non-obvious details: no compilation occurs, no simulator is needed, and VUnit built-in files are summarized as a count rather than fully enumerated. There is no contradiction with the annotations.
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 compact sentences: the first front-loads the returned data and its ordering/grouping, and the second gives the key no-side-effect constraint. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only dependency query, the description plus schema fully covers what is returned, how it is grouped/ordered, and the fact that no compile or simulator is required. The output schema also exists, so return-value documentation beyond this is not necessary.
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 description says 'one test case' but does not explain how test_name selects it or how wildcard patterns behave. The input schema's test_name description already covers full names, wildcards, and ambiguous matches, so the main description provides only marginal semantic addition.
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 states a precise verb and resource: returning the ordered source-file dependency list for one test case, grouped by library in compile order. It also clearly separates this from compile/run tools by noting it does not compile and needs no simulator.
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 frames this as a lightweight dependency/elaboration inspection tool and explicitly states no compile or simulator is required, which helps the agent choose it for static dependency questions. It does not name sibling alternatives or give explicit when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this with 'no re-run' and 're-read', making the read-only nature explicit. It adds behavioral details beyond annotations: it reads from the output dir, returns per-test status, and conditionally includes failing-check counts. This is valuable context without contradicting the annotations.
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 two sentences, with the core action front-loaded in the first sentence. The second sentence adds return semantics and a cross-reference to a sibling tool. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description fully covers what the agent needs to know: what it does, what it returns, and how to follow up on failures. The output schema explains return structure, so not describing it here is appropriate. Nothing essential is missing.
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 tool has zero parameters, so the description has no parameter meanings to add. Per the rubric, 0 params yields a baseline of 4, and the description appropriately focuses on the return value instead of inventing parameter details.
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?
Clearly states a specific verb and resource: 'Re-read the last run's JUnit report from the output dir'. The phrase 'no re-run' explicitly differentiates it from vunit_run_tests. It also specifies the return content (per-test status and failing checks), leaving no ambiguity about what the tool does.
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 clear context for when to use this tool (after a run, to inspect results without re-running) and points to the alternative vunit_get_test_log for deeper investigation of a specific failing test. While it doesn't explicitly say 'use this instead of X' for all siblings, the pointer to the log tool and the emphasis on no re-run give sufficient guidance for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already flags this as a safe read operation. The description adds value by specifying the output format (lib.entity[.proc]) and the notable behavior that a simulator is not required, which is not captured in annotations.
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 two sentences with no fluff. It front-loads the core action and resource, then adds the format and simulator requirement efficiently. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only, zero-parameter tool with an output schema present, the description provides all necessary information: what it lists, in what format, and under what conditions (no simulator). Nothing essential is missing.
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 tool has zero parameters, so the schema leaves nothing undocumented. The description's mention of the test case format adds context that complements the empty parameter list, satisfying the baseline for no-parameter tools.
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 uses a specific verb 'List' with a clear resource 'all test cases' and defines the format (lib.entity[.proc]). This unambiguously distinguishes it from sibling tools like vunit_list_files and vunit_status, which serve different purposes.
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 clarifies that this tool lists tests the project knows about and explicitly notes that it does not require a simulator. This provides clear context for when it is applicable, though it does not explicitly compare against alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations mark readOnlyHint=true, the description adds valuable behavioral details: the tool returns the last 100 lines by default, failure info appears at the end, and a structured 'Check results' section is appended when failing checks are present. It also notes the size cap ('~24 KB max') via the parameter description, but the tool description itself conveys the relevant default behavior and appended section. No contradictions with annotations exist.
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 three sentences, each earning its place: purpose, parameter source, and behavior. It is front-loaded with the core purpose and avoids any fluff. Every sentence adds actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only log retrieval tool with one required parameter and an output schema, the description provides all necessary context: why to use it, how to specify the test, what the default output is, how to get more context, and when an extra structured section appears. Nothing critical is missing for an agent to invoke it correctly.
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 schema already provides descriptions for both parameters (lines and test_name), so the tool description does not need to repeat basic definitions. But it adds contextual meaning by linking test_name to sibling tools ('full name from vunit_list_tests / vunit_get_report') and explaining the rationale for the lines default (failure info at end). The 'Check results' detail is not in the schema, so the description compensates for any gaps.
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 opens with 'Get the log output for one test', a specific verb and resource, and immediately clarifies its purpose: 'which is how you see WHY a test failed.' This clearly distinguishes it from sibling tools like vunit_list_tests (lists tests) and vunit_get_report (report-level data), making the tool's role unambiguous.
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 tells the agent that test_name comes from vunit_list_tests / vunit_get_report, implying the caller should first obtain a test name from those tools. It also gives concrete usage guidance: the default 100 lines is enough for failure info, increasing lines gives more context. However, it does not explicitly name alternatives or when-not-to-use cases, so it stops short of a fully explicit usage policy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by saying 'Report' rather than implying mutation. It adds useful context by stating what configuration items are inspected and candidly notes that simulator availability is only 'appears available,' setting proper expectations about the check's certainty.
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 two sentences with no filler. The first sentence front-loads the tool's exact purpose and report contents, while the second gives a clear usage directive. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a zero-parameter status tool. It covers what the tool reports, when to call it, and the tentative nature of the simulator-availability check. The presence of an output schema means return-value details do not need to be in the description.
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 tool has zero parameters and an empty input schema, so there are no parameter semantics to explain. This matches the baseline for no-parameter tools; the description focuses on output content rather than input handling, which is appropriate.
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 uses the specific verb 'Report' and identifies a clear resource: server configuration. It enumerates the exact content (project dir, run script, interpreter, VUnit version, simulator availability), making the tool's purpose unambiguous and distinct from sibling tools that list tests, compile, run, or fetch reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call this first when diagnosing setup problems' explicitly states when to invoke the tool. It also implies a sequencing role relative to the sibling tools, providing clear usage guidance without needing to mention every alternative.
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:

[![vunit-mcp MCP server](https://glama.ai/mcp/servers/ru551n/vunit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ru551n/vunit-mcp)

Score Badge

Copy to your README.md:

[![vunit-mcp MCP server](https://glama.ai/mcp/servers/ru551n/vunit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ru551n/vunit-mcp)

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/ru551n/vunit-mcp'

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