asqav-mcp
Server Quality Checklist
Latest release: v0.3.9
- Disambiguation4/5
Most tools have distinct purposes, but verify_output and verify_signature are closely related, though their descriptions differentiate them (output hash vs. general signature). check_policy and preflight_check also overlap slightly, but preflight_check adds agent status checking.
Naming Consistency3/5The majority of tools follow a verb_noun pattern (e.g., check_policy, create_tool_policy, list_agents), but exceptions like enforced_tool_call (adjective_noun_noun) and gate_action (noun_noun) break the pattern. The naming is readable but not perfectly consistent.
Tool Count5/515 tools cover policy management, enforcement, scanning, signing, and verification without feeling bloated. Each tool serves a specific function in the security workflow.
Completeness4/5The tool set provides CRUD for policies (via upsert create), gating, enforcement, scanning, and verification. Minor gaps exist, such as no explicit agent creation/removal tools, but the core security audit workflow is well-covered.
Average 3.6/5 across 15 of 15 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 65 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only mentions checking policy but omits critical details: is the tool read-only? Does it throw an error or return boolean if disallowed? No side effects or performance hints are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the purpose. The Args section is reasonably concise, though some information could be moved to the schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), the return value is implicit, but the description could still benefit from mentioning what the tool returns. The parameter count is low, but without behavioral details, the description feels incomplete for a policy-checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description provides the only semantic context. It gives useful examples for 'action_type' (e.g., 'data:read:users') and clarifies 'agent_id' as optional, but the agent_id description is minimal and does not explain its impact on policy evaluation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Check if an action is allowed by the organization's policies' with specific action examples, effectively conveying the primary function. However, it does not differentiate from sibling tools like 'gate_action' or 'preflight_check', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., 'gate_action' or 'enforced_tool_call'). There is no mention of prerequisites, limitations, or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden for behavioral transparency, but it only states 'Verify an existing signature' without explaining side effects, permissions, or what verification entails (e.g., read-only, cryptographic check).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but has an awkward structure with an 'Args:' header. It is adequately sized but could be more polished.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema, the description is too minimal. It does not explain the output or how this tool fits with sibling tools like verify_output or sign_action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning: 'signature_id: The signature ID to verify' is essentially a rephrasing of the schema. Schema description coverage is 0%, so the description should compensate but does not provide rich semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies an existing signature by signature_id, using a specific verb and resource, and distinguishes from siblings like sign_action which creates signatures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., verify_output, sign_action). The description lacks any context about appropriate use cases or exclusions.
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?
The description only states the tool removes a policy, implying a destructive action, but lacks details on required permissions, reversibility, error handling, or what happens if the policy does not exist. Since no annotations are provided, the description carries the full burden for behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence and a brief Args block. Every element serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects), the description is minimally adequate. It does not explain return values, but an output schema is present. However, it omits context about 'local enforcement policy' and potential side effects, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that describes the tool_name parameter as 'Name of the tool to remove the policy for', adding meaning beyond the schema's type-only definition. However, with 0% schema description coverage, more detailed guidance (e.g., format, constraints) would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Remove) and the resource (local enforcement policy). It is specific and directly conveys the tool's function, but does not explicitly differentiate from sibling tools like create_tool_policy or list_tool_policies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as create_tool_policy or list_tool_policies. There is no mention of prerequisites, typical scenarios, or exclusions.
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 full burden but only states 'Get details' without disclosing read-only nature, side effects, or what 'details' entails. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with no wasted words, but the Args section is redundant with the schema. Still, it's efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with an output schema, the description is adequate but could be improved by noting what kind of details are returned or any special behaviors, though output schema likely covers return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds meaning by stating 'The agent ID to look up' for the parameter, but it remains minimal and does not explain format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('details for a specific AI agent'), clearly distinguishing it from sibling tools like list_agents (which lists all agents) and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like list_agents or check_policy. The context is only implicit from the name and description.
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 burden. It explains the compliance_mode behavior in detail but does not disclose other behavioral traits like idempotency, side effects, or error conditions. It clearly states it creates a record, implying a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a docstring format with an Args list, which is structured but somewhat verbose. The main purpose is front-loaded, but the parameter explanations could be more concise. It is adequate but not highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (3 required) and an output schema, the description covers the essential behavior. It explains the optional payload and the compliance_mode dependency. However, it does not describe the output format, which is partially mitigated by the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explains all five parameters: agent_id, action_type, action_id, payload, and compliance_mode, with a detailed explanation of compliance_mode. This adds significant meaning beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a signed audit record for an AI agent action,' which specifies the verb and resource. It distinguishes from siblings like 'complete_action' or 'check_policy' by focusing on signing, but does not explicitly differentiate from similar logging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or suggest other tools for related tasks.
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?
Description mentions fail-open behavior (exceptions as warnings, not blockers) and return summary. However, with no annotations, it lacks details on side effects, authentication needs, or error handling beyond the fail-open note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences plus bullet-pointed args. First sentence front-loads purpose, second adds behavioral nuance, and args are clearly listed with examples. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, description does not need to detail return values but already summarizes them. Properly explains both parameters. Could mention that this is a precondition check, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description adds meaning by explaining agent_id as the agent to check and action_type with examples (e.g., 'data:read'). This significantly aids understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a combined agent-status and policy-allowed check, returning CLEARED or NOT CLEARED. This distinguishes it from sibling check_policy by specifying it includes agent status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like check_policy or complete_action. Does not mention prerequisites or when not to use.
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?
Implies read-only behavior, but no elaboration on authentication, performance, or definition of 'active' or 'local'. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, immediately states purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully adequate for a zero-parameter list tool; output schema exists so return details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100% trivially. Baseline 4 applies as no param info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Describes verb 'list' and resource 'active local tool enforcement policies' clearly. Differentiates from create/delete siblings but does not explicitly distinguish from check_policy or gate_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like check_policy. No exclusions or context 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?
No annotations are provided, and the description lacks any behavioral details such as pagination, rate limits, authentication requirements, or what happens if there are no agents. This is a significant gap for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words, perfectly sized for conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema (not shown), the description is mostly complete. It could mention that it returns a list, but the output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter information, but with no parameters the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'registered AI agents' with scope 'in the organization'. It distinguishes itself from sibling tool 'get_agent' which likely retrieves a single agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to list all agents), but does not provide explicit when-not-to-use or alternatives. No exclusions or context are given, making it minimally adequate.
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 carries the full burden. It states that the tool 'returns a risk assessment' but does not disclose whether it modifies any state, requires specific permissions, or has any side effects. For a scanning tool, read-only behavior is likely but not explicit, leaving behavioral transparency low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence stating the purpose, followed by a clear Args block. The purpose is front-loaded, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and no annotations, the description covers the tool's purpose and parameters adequately. The presence of an output schema means return values don't need elaboration. However, it does not explicitly state which parameters are required (though that is in the schema), so completeness is slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's docstring provides meaningful explanations for each parameter (e.g., 'tool_name: The tool name to scan', 'input_schema: Optional JSON string'). This adds value beyond the schema's bare titles and compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scan' and the resource 'MCP tool definition', and lists the specific threats it checks for (prompt injection, hidden unicode, etc.). This distinguishes it from sibling tools like 'scan_all_tools', which likely scans multiple tools at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives (e.g., 'check_policy' or 'preflight_check'). The usage is implied: whenever you need to scan a single tool definition. No when-not or alternative recommendations are given.
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, the description carries full burden. It discloses key behaviors: policy check, optional forwarding, signing of request and response, and an alternative signing-only mode. Lacks details on failure modes, auth needs, or rate limits, but covers the core workflow adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, but the initial sentence is dense and somewhat run-on. The structured Args list aids readability. Could be slightly more organized (e.g., bullet points) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (policy enforcement, optional forwarding, signing), the description covers the process but omits important aspects: what the output schema contains (since it exists but not described), error scenarios, prerequisites, and what happens on policy failure. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The 'Args' section explains each parameter (tool_name, agent_id, arguments, tool_endpoint) clearly, adding meaning beyond the bare schema. Could be more detailed about format or constraints, but sufficient for understanding usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool's purpose: a strong-enforcement path that performs policy-check, optionally forwards to tool_endpoint, and signs the request+response as a bilateral receipt. Distinguishes from sibling tools like check_policy, sign_action, complete_action by specifying the combined workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides minimal guidance: describes a 'strong-enforcement path' and notes an alternative where only approval is signed, requiring complete_action. However, it does not explicitly state when to use this tool vs. specific siblings, nor does it give when-not-to-use advice.
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 return values (APPROVED, DENIED, PENDING_APPROVAL) and the need to complete the bilateral receipt, but does not mention side effects, permissions, or statefulness. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose, then listing parameters. The structure is clear and every sentence adds value. Minor improvement could be using a more structured format, but it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown), the description covers return values and the follow-up step. However, it does not elaborate on handling DENIED or PENDING_APPROVAL outcomes, and assumes knowledge of 'bilateral receipt'. Overall sufficient but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully documents all five parameters with clear explanations and examples (e.g., action_type as 'data:delete:users'). This compensates entirely for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a pre-execution gate that signs decisions and returns approval outcomes. It distinguishes itself by mentioning the follow-up call to complete_action, but does not explicitly differentiate from sibling tools like check_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on calling complete_action after an APPROVED gate, but lacks when-not-to-use instructions or alternatives. The context of pre-execution gating is clear.
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 behavioral transparency. It indicates a read-like operation (scanning, returning a summary) but does not disclose if any modifications occur, permission requirements, or rate limits. The absence of destructive hints implies safety but 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence conveys the action and output efficiently with no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema (context signals indicate presence), the description adequately covers purpose and outcome. However, it lacks context on side effects or prerequisites, which for a scanning tool is minimal but still notable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter info, but the baseline for no parameters is 4, as there is nothing to clarify beyond what the empty schema inherently provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scan every registered tool policy for typosquatting and hidden unicode') and the output ('returns a per-tool risk assessment summary'). It distinguishes from sibling tool 'scan_tool_definition' which likely scans a single policy, thus providing specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies use for a global security scan (vs. checking a single policy via 'scan_tool_definition'), it does not explicitly state when to use this tool versus alternatives, nor does it provide any prerequisites or exclusions.
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 provided, so description carries the burden. It explains the verification behavior and parameter roles but does not describe side effects, return values, or error handling. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences plus an Args list. Efficient and front-loaded with the main purpose. Could be slightly more structured, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with two params and existing output schema, the description covers the essential purpose and arguments. It doesn't explain the output, but that is handled by the output schema. Adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage). Description adds meaning: signature_id is from complete_action or sign_action, expected_output is the string to verify against the signed hash. This significantly aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what the tool does: verify a signature and confirm the signed payload's output hash matches expected_output. It distinguishes from sibling 'verify_signature' by specifying the output verification step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use to detect post-sign tampering of an agent's reported result', providing clear context. Does not explicitly mention when not to use or alternatives, but the purpose is well-defined.
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?
Without annotations, the description carries the full burden. It explains the bilateral receipt concept but does not disclose potential side effects, idempotency, or security implications. Basic transparency is provided, but deeper detail 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences covering purpose and usage, plus parameter descriptions. It is front-loaded with the main purpose and contains no redundant words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 required parameters and an output schema, the description adequately explains the input and process. It does not detail the output schema (unnecessary given its existence), but it misses preconditions like having an approved action. Overall, the context is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning: gate_id is 'returned by gate_action when it approved the action' and result is 'a description or JSON string of the action's outcome'. This clarifies origin and format, adding value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sign the outcome of a gate-approved action and bind it to the approval signature as a bilateral receipt'. This specific verb+resource combination effectively distinguishes it from siblings like gate_action or sign_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that gate_id comes from gate_action when it approved the action, and result describes the outcome. This provides clear context for when to use the tool (after approval). However, it does not explicitly mention when not to use it or contrast with alternatives like sign_action.
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?
No annotations exist, so the description fully handles transparency. It discloses in-process evaluation, lack of API hop, and bilateral request+response signing via tool_endpoint, providing valuable behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with key info and well-structured with an Args list, though it could be slightly more concise; it remains efficient without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no annotations, the description covers creation and update semantics, behavioral traits, and parameters. An output schema exists to explain return values, so overall completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description lists and explains all 7 parameters (tool_name, risk_level, require_approval, max_calls_per_minute, blocked, hidden, tool_endpoint) with clear meanings, fully compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool upserts a local tool enforcement policy, specifying its use in gate_action and enforced_tool_call, and distinguishes it by mentioning in-process evaluation and bilateral signing via tool_endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies the tool is for creating or updating policies and mentions its integration points, but does not explicitly state when to use it versus sibling tools like check_policy or delete_tool_policy.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jagmarques/asqav-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server