MCP-Vetting

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation5/5
Each tool has a clearly distinct purpose: vetting remote vs local, retrieving cached verdicts, listing scanners, listing harnesses, and generating configs. No two tools overlap in what they do, and the descriptions reinforce their unique roles.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern: vet_server, vet_directory, get_verdict, list_scanners, list_harnesses, get_config. The verbs (vet, get, list) are descriptive and uniform.
Tool Count5/5
With 6 tools, the set is well-scoped for a vetting framework, covering both operational actions and informational queries. There is no bloat or redundancy.
Completeness5/5
The tool surface covers the core lifecycle: vetting remote and local servers, retrieving cached results, enumerating available scanners and harnesses, and generating configuration. No obvious gaps hinder a user from completing a vetting workflow.
Average 3.2/5 across 6 of 6 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This server has been verified by its author.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions a data property ('ready-to-paste config adapters') but does not state that the tool returns a list, that it is read-only, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but is a fragment rather than a complete sentence. It is concise but under-specified; a clearer structure like 'List all harnesses with...' would be more effective.
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 the tool has no parameters and an output schema exists, the description is too terse to fully convey the tool's purpose and behavior. It lacks a verb and any contextual guidance, leaving significant gaps for a standalone 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 zero parameters and 100% coverage trivially, so the baseline for 0 params is 4. The description adds no parameter information, but none is needed due to the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase, 'Harnesses with ready-to-paste config adapters,' and lacks an explicit verb like 'list' or 'retrieve.' It describes the content but does not clearly state the tool's action, making it reliant on the name for purpose. It also does not distinguish from siblings such as list_scanners.
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 like list_scanners or get_config. No use cases, preconditions, or exclusions are mentioned, leaving the agent without context for selection.
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 notes the tool is offline and returns a VetResult dict, but fails to mention side effects, required permissions, or whether it modifies anything. This is a significant gap for a tool with no structured behavioral hints.
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?
The description is a single concise sentence, but it is under-specified. The phrase 'Returns the VetResult dict' is redundant given an output schema exists, and the lack of parameter details makes the brevity feel like under-specification rather than effective economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no annotations, and only a minimal description. It does not explain the 'strict' parameter, what vetting involves, or any behavioral expectations. For a 2-parameter tool with zero annotation coverage, this description is grossly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 clarify parameter meaning, but it does not mention 'path' or 'strict'. The path parameter is implied by 'directory', but 'strict' is completely unexplained, leaving the agent without guidance on how to set 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?
The description clearly states the tool's function: vetting a local MCP server source directory offline. It uses a specific verb and resource, and the 'offline' qualifier distinguishes it from sibling tools like vet_server.
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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or prerequisites. The offline/local context is implied but not developed into actionable usage guidance.
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 carry the full burden of behavioral disclosure. It does not state that the operation is read-only, has no side effects, or what the tool actually does beyond implying these scanners are available. For a zero-parameter tool, minimal behavior is expected, but even a simple read-only hint is missing.
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 extremely concise, using one short phrase. It is well-structured as a minimal statement, though it is not a complete sentence. For a simple list tool, this brevity is acceptable.
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?
With zero parameters, no annotations, and an existing output schema, the description is arguably adequate but minimal. It lacks a full verb and does not provide context about what 'static scanners' are or how they relate to the other tools. It is complete enough to infer the purpose but leaves room for more clarity.
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 does not need to explain parameter semantics. Baseline for 0 parameters is 4, and the description adds no unnecessary detail, which is appropriate.
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 'The static scanners this framework runs' is a noun phrase rather than a full sentence with an explicit verb. It conveys that the tool lists the static scanners in the framework, but lacks a clear verb like 'list' and does not distinguish from sibling tool list_harnesses beyond the noun 'scanners.'
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 about when to use this tool versus sibling tools like list_harnesses or get_config. The description simply states what scanners are, not when to invoke this tool or what context it fits into.
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 carries full burden. It only says 'emit', which implies output generation, but does not disclose side effects, error handling, permissions, or what happens with invalid harnesses. 'Ready-to-paste' hints at output format but little else.
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?
A single, front-loaded sentence with no redundant words. It immediately states the tool's purpose and the list of harnesses.
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?
With 5 parameters, 0% schema coverage, and no annotations, this short description is insufficient. It does not explain how the parameters relate, what 'name' refers to, or when a user would need env/args, although the output schema does exist.
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%, yet the description only explains the `harness` parameter by listing valid values. It provides no meaning for `name`, `command`, `env`, or `args`, leaving the agent to guess their roles.
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?
Description uses a specific verb ('Emit') and a concrete resource ('ready-to-paste MCP config block') with a list of valid harnesses. This clearly distinguishes it from sibling tools like vet_server or list_harnesses.
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 context is clear: use it to generate an MCP config block for a particular harness. However, it does not explicitly mention when not to use it or point to alternatives like list_harnesses.
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?
With no annotations provided, the description carries the burden of disclosing behavior. It reveals a key behavioral trait: it may trigger a vetting operation if the cached result is not fresh. This warns the agent that the tool might perform a potentially expensive action. It lacks specifics on what 'fresh' means or if there are side effects, but the core conditional behavior is clearly conveyed.
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 a single, well-structured sentence. It front-loads the primary action and the conditional logic without redundancy. Every word contributes meaning, making it exceptionally concise and efficient.
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?
Given the tool's simplicity (one parameter, output schema exists), the description covers the essential behavior: returning cached verdicts or triggering vetting. It does not define 'target' or 'fresh', which are domain-specific, but the sibling tools provide context. The description is adequate for a tool of this complexity, though not exhaustive.
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?
The input schema provides only a parameter named 'target' with type string, and schema coverage is 0%. The description mentions 'a target' but does not define what constitutes a target, its format, or any constraints. It fails to compensate for the lack of schema detail, adding no meaningful semantics beyond the parameter name.
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 action: return a cached verdict or otherwise vet the target. It identifies the resource (target) and the conditional behavior, distinguishing it from sibling tools like vet_server and vet_directory that likely perform direct vetting without a cache-first approach.
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?
Usage is implied: use this tool when you need a verdict for a target, and it will handle freshness. However, it does not explicitly state when to use this versus alternatives, nor does it mention any prerequisites or exclusions. The conditional 'if fresh, else vet it now' provides context but not explicit alternative comparisons.
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, the description must carry the full burden for behavioral disclosure. It does disclose the return format (VetResult dict with verdict, findings, provenance, files scanned) and accepted input formats, but it does not explain whether the tool downloads/executes packages, requires network access, or has side effects. This leaves gaps in understanding the tool's operational behavior beyond the basic input->output mapping.
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 long and front-loads the core purpose, then provides target formats and output structure. No filler or redundant information is present. It is appropriately sized for the tool's simplicity.
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?
Given that an output schema exists (so return values are already structured), the description adequately covers the main purpose, target formats, and output summary. The main missing element is the meaning of 'strict' and any usage exclusions, but overall the description is reasonably complete for a tool with two parameters. The absence of side-effect disclosure is a minor gap given the likely read-only nature of vetting.
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 explains the 'target' parameter by listing the supported package identifier formats, which is not present in the input schema. However, the 'strict' boolean parameter is completely undocumented in both the schema and description, leaving its meaning and effect unknown. Since schema description coverage is 0%, the description only compensates for one of the two parameters.
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 a specific action ('Vet') applied to a specific resource ('remote MCP server') and enumerates accepted target formats (npm:pkg, pypi:pkg, gh:owner/repo, bare npm name). This distinguishes it from sibling tools like vet_directory, which presumably handles local directories. The mention of the VetResult dict further clarifies the tool's purpose.
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 by specifying 'remote MCP server' and the exact package identifier formats, implying it is intended for remote package references. However, it does not explicitly state when not to use this tool or suggest alternatives like vet_directory for local directories. Thus it has clear context but no explicit exclusions or alternative direction.
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:

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

Score Badge

Copy to your README.md:

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

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/ElDiegolar/mcp-vet'

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