AgentAegis

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct security or compliance function. There is no ambiguity between similar-sounding tools like vuln_scan_network and vuln_scan_web_app because they clearly differentiate between network and web application scanning.
Naming Consistency3/5
Most tool names follow a noun_noun or noun_verb pattern in snake_case, but there is inconsistency: some are noun_verb (e.g., incident_triage), some are noun_noun (e.g., cve_lookup), and one is verb_noun (vet_endpoint). The naming is readable but lacks a strict uniform convention.
Tool Count2/5
With 28 tools, the server exceeds the typical upper bound for a well-scoped set. While the domain is broad (security and compliance), the number feels bloated and could be consolidated (e.g., combining related scans or audits).
Completeness5/5
The tool set covers the full lifecycle of security assessment and compliance: vulnerability scanning, compliance frameworks, audits, evidence collection, policy generation, incident triage, and account management. There are no obvious missing operations for the stated domain.
Average 3/5 across 28 of 28 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 70 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 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.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden but only states a generic generation action. No disclosure of side effects, authorization needs, or output format.
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?
Single sentence, but critically under-specified. Does not front-load key operational details; wasted opportunity to clarify purpose.
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?
Complex tool (6 params, no output schema, many siblings) but description provides zero context beyond a generic phrase. Incomplete for effective agent use.
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 has 6 parameters with 17% description coverage (only previous_scan_id described). The tool description adds no meaning beyond the schema, failing to compensate for low coverage.
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 'generate audit-ready compliance reports' is vague. It does not specify the resource (e.g., compliance report) or differentiate from similar sibling tools like policy_generate or compliance_framework_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context on prerequisites, expected input data, or suitable scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool performs destructive actions, requires authentication, or has side effects. It fails to add any value beyond the name.
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 extremely short (one sentence), but it is under-specified rather than concise. It lacks necessary detail and does not earn its place as a useful guide.
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?
Given the complexity (4 parameters, nested objects, no output schema, no annotations), the description is completely inadequate. It does not explain return values, required context, or side effects, making it insufficient for an AI agent to use effectively.
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 only 25% (only previous_scan_id has a description). The tool description adds no information about any parameters, leaving the agent to rely entirely on the schema for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the tool is for classifying and responding to security incidents, which is a clear verb+resource combination. It distinguishes from sibling tools like threat_intel_lookup or vuln_scan, which focus on different aspects. However, it is somewhat broad and could be more specific about the actions involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any mentions of prerequisites or exclusions. The description is a single sentence with no usage context.
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 convey behavior. It labels the tool as an 'audit' but does not clarify if it is read-only, what side effects exist, or what the output contains, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one phrase) but lacks essential information, making it under-informative. It is not well-structured for a tool with multiple parameters and complex usage.
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?
Given 4 parameters (one required with nested fields), no output schema, and no annotations, the description provides almost no context. The agent cannot determine expected input format, output, or how the audit works, making it 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 only 25% (only 'previous_scan_id' has a description). The tool description adds no meaning to the parameters; it does not explain the purpose of 'users', 'admin_roles', or 'sensitive_permissions', 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Audit' and resource 'user access' with a clear principle 'least-privilege', but it does not differentiate from sibling audit tools like 'audit_report_generate' or 'compliance_framework_check', leaving ambiguity in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; the description is a single phrase without context, and sibling tools list is long with no differentiation.
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 available, the description alone must convey behavioral traits. It only states the basic function and omits critical details like whether it is read-only, destructive, requires authentication, or triggers external actions. This lack of transparency increases the risk of unintended consequences.
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 extremely concise—a single sentence. While brevity is positive, it comes at the cost of essential information. The sentence alone could be part of a more informative description, but as the entirety, it is under-specified for the tool's complexity.
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?
Given the tool's complexity (4 parameters, nested objects, no output schema, no annotations), the description is severely incomplete. It does not explain what an evidence collection plan is, how integrations are used, what the return value looks like, or how this tool fits into a compliance workflow. An agent would be hard-pressed to use this correctly.
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?
The description adds no meaning to any of the 4 parameters. Schema description coverage is only 25% (only previous_scan_id has a schema description). The input schema itself has nested objects and enumerations that cry out for explanation, but the description provides none. This forces the agent to guess parameter usage or rely on external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generate evidence collection plans') and the resource ('compliance controls'). It is specific about what the tool does, though it does not explicitly differentiate from sibling tools like audit_report_generate or control_gap_analysis. Still, the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, intended scenarios, or situations where this tool should be avoided. Without such guidance, an agent may misuse or overlook 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?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention whether the scan is destructive, requires authentication, impacts the target, or produces side effects. The term 'scan' implies read-only but is not explicit, and potential risks (e.g., triggering alerts) are omitted.
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 short sentence (8 words), which is concise but fails to earn its place due to missing critical information. It is front-loaded but insufficient for the tool's complexity.
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?
Given 6 parameters (with nested objects), no output schema, and no annotations, the description is extremely incomplete. It does not explain asynchronous behavior, how to retrieve results, or how to handle authentication. The tool's complexity requires significantly more context.
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 only 17% (only previous_scan_id described). The tool description adds no explanation for any parameter, such as target_url, scan_depth, authentication, or exclude_paths. This forces the agent to rely on a poorly described schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (scan), resource (web app), and scope (OWASP Top 10 vulnerabilities), effectively distinguishing from siblings like vuln_scan_network or sast_scan. However, it lacks specificity about the scanning methodology or output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., sast_scan, dependency_audit). No mention of prerequisites, frequency, or scenarios where it should not be used, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral context such as potential duration, destructiveness (likely none), required permissions, or rate limits. For a scanning tool, these are important omissions.
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 (one sentence) but lacks necessary detail. It is front-loaded but insufficiently informative for a tool with 5 parameters. Conciseness should not come at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, low schema coverage), the description is inadequate. It does not explain return values, behavior of async, or differences between scan types. The agent lacks enough information to use the tool effectively.
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 only 20% (1 of 5 parameters described in schema). The tool description does not compensate by adding parameter meaning; it does not mention target format, scan_type options, or how async works. The agent must infer semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scan' and the resources 'IP/domain' and what is found ('open ports, services, and vulnerabilities'). It is specific enough but does not differentiate from sibling tools like 'vuln_scan_web_app' or 'sast_scan', which could lead to 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies general usage but does not address exclusions, prerequisites, or scenarios where other tools (e.g., vuln_scan_web_app) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as whether the tool modifies data, accesses external systems, or requires specific permissions. Merely saying 'comprehensive' is insufficient for a security audit tool.
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?
Extremely concise (one phrase), which is efficient but at the cost of providing necessary detail. No structure or front-loading of key points beyond the broad purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the audit covers, what results look like, or any behavioral constraints.
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 33% (only previous_scan_id described). The description adds no meaning beyond what's in the schema; it does not explain domain or include_mx_analysis. With low coverage, the description should compensate but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Comprehensive email security audit' which clearly indicates the tool is for auditing email security. It distinguishes from siblings like dns_security_check or ssl_tls_audit by focusing on email. However, it lacks a specific verb like 'perform' or 'run', and 'comprehensive' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like audit_report_generate or compliance_framework_check. No mention of prerequisites 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?
No annotations exist, and the description does not disclose behavioral traits. It fails to mention whether the tool is read-only or mutates state, any required permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks structure. It does not follow best practices of front-loading key information or organizing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description is incomplete. It does not explain return values, required inputs, or how to use the tool effectively.
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 schema description coverage is only 14%. The description does not explain the purpose or expected values for any parameter, relying solely on the schema which has minimal descriptions. The term 'tailored' hints at customizations but is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'generate' and resource 'security policy documents' with 'tailored' indicating customization. It is clear and distinguishes from sibling tools like audit_report_generate, though it does not elaborate on the scope or types of 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as compliance_framework_check or control_gap_analysis. There is no mention of prerequisites 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, the description carries full burden for behavioral traits. It only states 'lookup', implying a read operation, but omits details about authorization needs, rate limits, error handling, or what happens with no results. This is insufficient for a security tool.
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 extremely concise (8 words), but comprehensiveness is sacrificed. While every sentence earns its place, the single sentence lacks detail crucial for accurate tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's security context and lack of output schema, the description should explain return values, interpretation of results, and integration with other tools. It fails to provide this, leaving the agent with insufficient context for correct usage.
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 coverage is low (33%) and the description does not add meaning beyond the schema. Required parameters 'indicator' and 'indicator_type' have no description, and the enum is self-explanatory but not clarified. The optional parameter has a schema description, but the tool description fails to compensate for the covered gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lookup' and resource 'IOC' against threat intel feeds, making the purpose evident. It distinguishes from sibling tools like 'cve_lookup' and 'secret_scan' by focusing on indicators of compromise, though it does not explicitly differentiate itself.
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 usage guidelines are provided. The description lacks guidance on when to use this tool versus alternatives (e.g., for specific indicator types), prerequisites, or exclusions, leaving the agent to infer context.
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. It mentions 'analysis' and 'roadmap' but does not disclose idempotency, side effects, authorization requirements, rate limits, or whether it mutates data. The term 'deep-dive' suggests computational cost but is not explicit.
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 a single sentence, very concise with no wasted words. However, it is too brief and could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (2 required), no output schema, and a complex domain (compliance), the description is insufficient. It does not specify supported frameworks, output format, or how it differs from sibling tools. A more complete description would add value.
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 only 20% (1 of 5 parameters documented in schema). The description provides no parameter details. While the schema lists enums and requirements, the description adds no meaning beyond what schema offers. The previous_scan_id parameter has a detailed description in schema, but that is not part of the description field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'deep-dive analysis' and 'remediation roadmap'. The verb 'analysis' and specific domain 'compliance control gaps' make the purpose clear. However, it does not differentiate from similar sibling tools like compliance_framework_check or audit_report_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or context for invocation. The description is silent on usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It only states the action but does not disclose whether the tool is read-only, requires authentication, has rate limits, contacts an external API, or returns results. This is a significant gap.
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 very short (5 words) but front-loads the essential purpose. However, given the tool has 3 parameters and no other context, more detail would be warranted. It is not inefficient but feels under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema or annotations. The description does not cover parameter usage, expected output, prerequisites, or behavior. It is incomplete for a tool of this complexity.
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 coverage is low (33%) and the description does not explain the parameters target and check_type beyond the tool's general purpose. It adds no detail about how to use them or their formats, failing to compensate for the low schema coverage.
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 checks email/domain in breach databases (HIBP), using specific verb 'Check' and resource 'email/domain in breach databases'. It distinguishes itself from sibling tools like cve_lookup or threat_intel_lookup by specifying HIBP and breach database context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks when-not-to-use or usage context, assuming the agent knows from the name. No explicit alternatives or exclusions are mentioned.
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, the description should disclose behavioral traits. It does not mention side effects, read-only nature, required permissions, or whether it creates any records (despite the previous_scan_id parameter suggesting a lineage). The description is too brief to convey these aspects.
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-formed sentence that conveys the core purpose without any extraneous information. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested object, no output schema, multiple sibling tools), the description is insufficient. It lacks details about output format, prerequisites, and how to interpret results, making it incomplete for confident use.
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 only 33%, and the tool description adds no parameter-specific guidance. It does not explain the organization_profile fields or their significance, nor does it detail the framework enum values. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('assess') and the target ('an organization's security posture against a compliance framework') and lists specific frameworks. However, it does not specify what the output of the assessment is (e.g., a report, score, or list of findings), which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its siblings (e.g., control_gap_analysis, audit_report_generate). It does not mention prerequisites, limitations, or scenarios where alternative tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Look up' which implies read-only but does not disclose data source, rate limits, or any side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with key action. Every word contributes.
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?
No output schema, no annotations, and only two parameters. The description is too short to convey output format, error handling, or data source. For a lookup tool with potentially rich output, it is incomplete.
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 coverage is 50% with only previous_scan_id having a description in the schema. The main description adds no parameter details, and the cve_id parameter lacks explicit meaning beyond the pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up CVE details, CVSS scores, and patches. It uses a specific verb and resource, but does not differentiate from sibling tools like threat_intel_lookup which may also provide CVE information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The description implies general CVE lookup but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'assess', implying a read operation, but does not confirm side effects (e.g., read-only), authentication needs, rate limits, or output format. Minimal transparency.
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 concise sentence that is front-loaded and contains no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex required parameter, no output schema, and no annotations, the description is too sparse. It does not explain return values, error conditions, or the nature of the assessment (e.g., whether it produces a report or updates state).
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 50% (only previous_scan_id has a description). The tool description adds no parameter insights, failing to compensate for the undocumented 'users' parameter. The meaning of 'users' must be inferred from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Assess MFA coverage and strength' uses a clear verb-resource pair and is reasonably distinct from sibling tools like access_review or credential_check. However, it lacks specificity on what the assessment entails (e.g., report, metrics) and does not explicitly differentiate from similar 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/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, no when-not-to conditions, and no mention of prerequisites or context. The description simply states the purpose without usage direction.
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. It does not disclose behavioral traits like read-only nature, resource consumption, or required permissions. Minimal information beyond 'static analysis'.
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?
Extremely concise—one sentence that covers purpose and language support without any redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters including a nested object and no output schema, the description is too brief. It omits expected return values, parameter specifics, and usage context, leaving the agent underinformed.
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 low (33%); only previous_scan_id has a description. The tool description adds no parameter details, failing to explain the 'source' object or the impact of severity_threshold. Compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs static analysis for security vulnerabilities and lists supported languages, distinguishing it from other security scanning tools like secret_scan or vuln_scan_network. However, it does not specify the output, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as dependency_audit, cve_lookup, or vuln_scan_web_app. The description only states what it does, not when it is appropriate or not.
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, the description must fully disclose behavioral traits. It only states the tool detects secrets, omitting whether it is a read-only scan, any side effects, or operational constraints like rate limits.
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-front-loaded sentence with no wasted words. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, 3 parameters, no output schema), the description is far too minimal. It does not explain input formats (how to provide source code or repo), output expectations, or error conditions.
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 only 33% (only previous_scan_id has a description). The tool description adds no parameter information, leaving two parameters (source, include_history) entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detect hardcoded secrets in source code' clearly states the tool's function with a specific verb and resource. However, it does not differentiate from sibling tools like credential_check or sast_scan, which have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions or prerequisites. The description lacks context for appropriate usage.
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, the description must disclose behavioral traits. It only says 'audit' but doesn't state whether it is read-only, requires network access, or has side effects like creating records.
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?
Single sentence efficiently conveys purpose and ecosystems with no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has complex nested input schema and no output schema. Description does not clarify valid source combinations or the purpose of previous_scan_id. Insufficient for the complexity.
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 adds value by listing ecosystems (matches manifest_type enums), but does not explain the source object structure or the optional previous_scan_id. Schema coverage is 50%, description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits dependencies for known vulnerabilities and lists six package ecosystems, providing precise scope. It differentiates from general vulnerability scanning by focusing on dependencies, though no explicit sibling differentiation is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like secret_scan or sast_scan. Prerequisites or constraints are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Audit'. It does not mention whether network requests are made, if it is read-only, what output to expect, or any side effects. This is insufficient for safe invocation.
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 a single concise sentence with no wasted words. It is front-loaded but lacks depth; however, for brevity it earns a high score as every word contributes to purpose clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (including an optional ID), no output schema, and no annotations, the description is too sparse. An agent would lack understanding of return format, effects, and how to use the optional parameter effectively.
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 coverage is low (33%) and the description adds no parameter information. While the schema includes a description for 'previous_scan_id', the tool description itself does not clarify the meaning or usage of any parameter, failing to compensate for the low coverage.
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 explicitly states the tool audits SSL/TLS configuration for a domain, using specific verb and resource. Among sibling tools like 'dns_security_check' and 'email_security_audit', this one uniquely targets SSL/TLS, making differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It simply states the action without context of appropriate usage scenarios.
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, the description carries the full burden. It states the criteria (exploitability and business impact) but does not disclose whether this is a read or write operation, any side effects, authentication needs, or output format. The minimal sentence leaves significant uncertainty about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence without fluff. It wastes no words, but the brevity comes at the cost of completeness. Could benefit from one or two additional clarifying sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects, no output schema, no annotations), the description is insufficient. It does not explain the output, the prioritization algorithm, or any dependencies. A tool this complex needs at least a few more sentences to be complete.
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 only 33% (only previous_scan_id has a description). The tool description does not explain the meaning or structure of the 'findings' array or 'business_context' object beyond the schema. It hints at prioritization criteria but does not map them to parameters, leaving the agent underinformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: prioritize vulnerabilities based on exploitability and business impact. This verb-resource pair is specific and distinguishes it from sibling tools like cve_lookup (lookup only) or incident_triage (incident response).
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 given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., having scan results), context (e.g., after a vulnerability scan), or exclusions. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only implies a read-only check but does not disclose behavioral details such as whether it modifies state, auth requirements, rate limits, or what constitutes a security issue.
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?
Single, focused sentence that front-loads the tool's purpose. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has two parameters, no output schema, and no annotations. Description is too minimal (one sentence) to convey what the check returns, how results are structured, or what security issues are considered.
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 coverage is 50% (only previous_scan_id has description). Domain parameter lacks description, and tool description does not explain parameter roles, formats, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Check' and resource 'DNS security', listing specific record types (SPF, DKIM, DMARC, DNSSEC). Distinguishes from sibling tools like credential_check or ssl_tls_audit by focusing on DNS records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no exclusion criteria. Agent must infer usage context from the tool name alone.
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 must convey behavioral traits. It states the tool combines multiple checks into a verdict, implying a read-only operation. However, it does not disclose error cases, side effects, or whether the tool modifies state.
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 a single sentence that efficiently conveys purpose and scope. It front-loads the key output (PROCEED/CAUTION/BLOCK). Minor improvement could be splitting into two sentences, but overall concise.
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 no output schema, the description should explain return structure. It mentions 'with reasons' but not the format or detail. The tool is composite and complex; the description gives high-level info but lacks depth for complete agent understanding.
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 covers 100% of parameters with descriptions. The description adds value by explaining that previous_scan_id builds a traversable chained-workflow lineage retrievable via agent_scan_get, which goes beyond the schema's basic description.
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 produces a composite trust verdict (PROCEED/CAUTION/BLOCK) for an endpoint, combining multiple security checks. This specific verb-resource pair and the composite nature distinguish it from sibling tools like dns_security_check or ssl_tls_audit.
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 indicates the tool should be used when an agent is about to call or pay an endpoint, but lacks explicit guidance on when not to use it or direct references to alternatives. While siblings are listed, no comparative usage advice is 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 the transparency burden. It discloses the tool is read-only (retrieves prior scans), includes full output, and is free to call. This is sufficient for a simple retrieval operation, though it lacks details on error scenarios or rate limits.
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 sentence that efficiently conveys purpose, input (scan_id), output (full stored output), benefit (build on earlier results, free). Front-loaded with key action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently hints at the return format (full output). Parameter descriptions are clear. The tool is simple, and the description covers the essential context for correct use, though omitting details on how scan_id is obtained (hinted at from agent_history).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions. The tool description does not add extra meaning beyond the schema (e.g., scan_id format, default for include_full_output). Per guidelines, baseline is 3 when coverage is high and description adds no new semantics.
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 it retrieves a prior scan by scan_id, including full output, and emphasizes the benefit of reusing results without cost. This distinguishes it from sibling tools that perform new scans (e.g., sast_scan, vuln_scan_web_app) or list scans (agent_history).
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 implies usage when you want to build on earlier results, but it does not explicitly specify when not to use this tool or how it compares to alternatives like agent_history for retrieving scan IDs. No direct mention of 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 are provided, so the description carries full behavioral burden. It states it returns FAQ and is free, but does not detail side effects, idempotency, or behavior with invalid topics. It is adequate but not thorough.
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 concise sentences cover the tool's purpose, topics, and cost. No redundant information, making it easy to parse quickly.
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 simple FAQ tool with one optional parameter and no output schema, the description covers the main aspects: what it returns (FAQ on listed topics) and that it is free. Minor missing details like response format or error handling are acceptable given the tool's simplicity.
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?
With 0% schema description coverage, the description lists the topic categories in text, adding value over the bare enum schema. However, it does not explicitly map enum values to their filtering behavior, leaving some ambiguity.
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 clearly states the tool returns FAQ content on specific topics (authentication, billing, etc.) and distinguishes it from sibling security/audit tools by its focus on documentation and help.
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 notes it is 'free to call' and has an optional topic filter, implying use for getting FAQ info. While it doesn't explicitly exclude other tools, the purpose is clear enough for an agent to differentiate.
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 full burden of behavioral disclosure. It details the scanning actions (exfiltration, prompt-injection sinks, etc.) and the output (verdict with findings). It does not mention side effects or authorization requirements, but as a read-only scanner, the description is sufficiently transparent.
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 a single, dense sentence that packs all key information (action, purpose, checks, output) upfront. It is efficient with no wasted words, though breaking it into shorter sentences could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex input schema with nested objects and no output schema. While the description covers the scan's scope and verdict, it does not describe the return format or error scenarios, leaving gaps for an agent to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (the 'source' object's inner fields lack descriptions, while 'previous_scan_id' has one). The tool description does not add meaning beyond what the schema provides for the parameters; it focuses on tool functionality rather than 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?
The description uses a specific verb ('scan') and resource ('MCP server') and clearly enumerates the types of risks it checks for (exfiltration, prompt-injection, etc.), distinguishing it from sibling security tools that target different systems or vulnerabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('BEFORE trusting it'), implying the context of vetting an MCP server. However, it does not provide explicit guidance on when not to use it or mention alternatives among siblings.
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 carries full burden. It discloses the scan's inputs (git repo or SKILL.md) and the verdict output, and lists several risk categories. However, it does not mention whether the tool makes external network calls, modifies anything, or its authentication requirements, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence using an em dash and arrow to convey purpose, target, risks, and outcome. Every phrase is informative and necessary, with no redundancy.
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 no output schema, the description adequately explains the output verdict (PROCEED/CAUTION/BLOCK). It covers the main input types and risk categories. Minor gap: it doesn't specify if the verdict is the only output or if there is a detailed report, but it is largely sufficient for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. The description adds clarity by associating 'git repo' and 'SKILL.md' with the source type enum, but does not further elaborate on the source object's structure (url, skill_md) beyond the schema. The previous_scan_id parameter has a detailed schema description, so the description provides no extra value there.
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 scans an agent SKILL for supply-chain risk and provides a PROCEED/CAUTION/BLOCK verdict. It mentions specific checks (prompt-injection, hidden-unicode, over-broad grants, etc.), making it distinct from sibling security tools like sast_scan or secret_scan.
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 phrase 'BEFORE trusting it' gives a clear usage context. The description lists specific risks checked, implying when to use. However, it does not explicitly state when not to use or provide alternatives among siblings, so it falls 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?
No annotations provided, so description carries full burden. 'Free to call' indicates safe, non-destructive operation. Lists return fields and optional filters. Lacks details on ordering or definition of 'recent', but sufficient for a history 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and return info. Every word adds value; no wasted text.
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 no output schema, description adequately covers return fields and purpose. Missing details on result ordering and 'recent' definition, but sufficient for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description merely repeats 'Optional limit/tool/target/since filters' without adding new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'lists' and resource 'recent scans' with fields (scan_id, tool, target, status, time). Clearly distinguishes from sibling 'agent_scan_get' which retrieves a single scan.
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?
States usage purpose 'so you can retrieve or chain from a prior result', providing clear context. No explicit when-not-to-use or alternatives, but the context implies appropriate use.
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 are provided, so the description carries the burden. It clearly states the tool returns information and is free to call, implying no side effects. It could further emphasize read-only nature, but the current text 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?
The description is two sentences with no wasted words. The purpose is clearly stated first, followed by the cost detail. Perfectly concise.
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?
Given the tool has no input parameters and no output schema, the description fully explains what it returns and its cost. It is complete for an agent to understand and use the 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?
There are zero parameters and schema coverage is 100%. The description adds meaning by explaining what the tool returns, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns prepaid balance, monthly limit, current month usage, and breakdown of remaining tool affordability, distinguishing it effectively from sibling audit and scan tools.
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 states it is free to call, implying it can be used freely; however, it does not explicitly mention when to use this tool versus alternatives. Given its zero-parameter nature and billing context, this is acceptable.
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, but the description discloses read-only nature, zero cost, and returned fields. It lacks explicit mention of no side effects, but the info provided is sufficient for a whoami 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no waste. Efficient and clear.
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?
Despite no output schema, description fully explains what is returned. For a simple identity tool with no parameters, it is complete.
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?
No parameters exist. Schema coverage is 100% (empty). Baseline is 4 for zero-parameter tools, and description adds no unnecessary param info.
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 returns agent identity, identification method, and usage metrics. It uses specific verb 'Returns' and distinguishes from sibling audit/scan tools.
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 phrase 'Free to call' implies no restrictions, but no explicit when-to-use or alternatives. However, its unique purpose among siblings makes usage obvious.
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:

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

Score Badge

Copy to your README.md:

[![agentaegis-mcp MCP server](https://glama.ai/mcp/servers/astafford8488/agentaegis-mcp/badges/score.svg)](https://glama.ai/mcp/servers/astafford8488/agentaegis-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/astafford8488/agentaegis-mcp'

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