MoonMCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
Each tool has a clearly distinct purpose: analyze_headers audits HTTP security headers, content_discovery probes for sensitive paths, dns_lookup resolves DNS records, fingerprint identifies technology stacks, etc. No overlapping functionality.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_headers, dns_lookup, enumerate_subdomains, port_scan). There are no mixed conventions or irregularities.
Tool Count4/522 tools is on the higher side but appropriate for a comprehensive security reconnaissance server. Each tool covers a specific aspect of the workflow, and there are no redundant tools. Could potentially be trimmed slightly, but overall well-scoped.
Completeness5/5The tool set covers the full reconnaissance lifecycle: passive OSINT (subdomain enum, DNS, CVE lookup), active scanning (port scan, HTTP probe, content discovery), vulnerability scanning (nuclei), scope management, and status/configuration. No obvious gaps for the intended domain of offensive security testing.
Average 4/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It does not disclose what happens if the target does not exist, whether removal is irreversible, or any side effects on associated data.
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?
Single sentence with no filler words. Front-loaded with key information. Could be expanded slightly without harming conciseness.
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 only one parameter, no output schema, and non-trivial sibling tools, the description is insufficient. It omits return behavior, error cases (e.g., missing target), and prerequisite conditions for safe invocation.
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 sole parameter 'target' lacks format specification (e.g., domain, IP, regex). Schema description coverage is 0%, and the description only says 'previously added scope entry' without clarifying acceptable values.
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 verb 'remove', resource 'scope entry', and context 'from allow or deny lists'. It effectively distinguishes the tool from siblings like scope_add and scope_list.
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 explicit guidance on when to use this tool versus alternatives like scope_add or scope_exclude. The description only implies that the entry must have been previously added, but lacks contextual cues.
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 fully bears the burden. It discloses that the scan is 'unprivileged and non-malformed (full handshake)' and 'intrusive' requiring explicit permission. This gives good insight into behavior. Missing details about potential side effects or limitations are minor.
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 consists of three concise sentences, each adding information: scan type, port parameter, banner grabbing, and prerequisites. No extraneous content. Efficiently structured.
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 no output schema and no annotations, the description should explain the output format or what is returned (e.g., list of open ports, service banners). This is missing. Also, there is no mention of error conditions or result interpretation. For a scan tool, this is a significant gap.
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?
Schema description coverage is 0%, so the description must compensate. It explains the 'ports' parameter format ('top' or ranges) and mentions 'optionally grabs service banners' (grab_banner). However, 'timeout' and 'target' are not further explained, leaving gaps. Partial but useful guidance.
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 specifies 'TCP connect-scan an in-scope host', indicating the verb (scan) and resource (host ports). It is distinct from siblings like 'vuln_scan' or 'dns_lookup', though no explicit differentiation is made. The purpose is clear and specific.
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 mentions prerequisites: requires MOONMCP_ALLOW_INTRUSIVE and host in scope. However, it does not provide guidance on when to use this tool versus alternatives such as 'vuln_scan' or 'content_discovery'. The context is clear but lacks exclusions or alternative recommendations.
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 discloses one important behavioral trait (exclusions override allowlist), but lacks information on persistence, reversibility, or permissions. More transparency is needed for a mutation 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?
Two sentences with no redundant information. The verb 'Mark' and resource 'target as out-of-scope' are front-loaded, and the sentence about override adds value efficiently.
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 tool, the description covers purpose and key behavior but omits context like target format, statefulness, and how to undo an exclusion. This gap may hinder agents unfamiliar with the domain.
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?
With 0% schema description coverage for the single parameter 'target', the description adds no extra meaning about what constitutes a valid target (e.g., domain, IP). The schema only provides the name, leaving the agent to guess the format.
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 marks a target as out-of-scope, with a distinguishing behavioral note that exclusions override the allowlist. This differentiates it from sibling tools like scope_add and scope_remove.
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 usage for exclusion but does not explicitly state when to use this tool versus scope_remove or scope_add, nor provides alternative guidance. The note about override is helpful but insufficient for clear decision-making.
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 that the tool is passive and that it flags interesting URLs. It does not mention rate limits, authentication needs, or output format. Provides basic behavioral context but lacks detail on non-destructive guarantees or limitations.
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, no fluff. Front-loads the core purpose and key differentiator ('passive'). Efficiently communicates the tool's value and special feature (flagging interesting URLs). Every sentence contributes meaningfully.
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 tool with 3 parameters and no output schema, the description covers the main purpose and the interesting URL flagging feature. However, it does not explain the behavior of limit or include_subdomains, nor does it describe the output format or any operational constraints. Adequate for a simple tool but leaves gaps that could impact correct invocation.
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?
Schema description coverage is 0%, and the description does not explain the 'limit' or 'include_subdomains' parameters. It briefly mentions 'domain' indirectly through the main purpose and 'flags' as a concept, but provides no syntax, defaults, or usage details for individual parameters. The description fails to compensate for the lack of schema documentation.
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 it fetches historical URLs for a domain from the Internet Archive. Explicitly mentions surfacing old endpoints, parameters, and forgotten files, with flagged interesting URLs. Distinguishes itself from sibling tools like content_discovery (active) and enumerate_subdomains (different 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?
Describes the tool as 'Passive,' implying suitable for passive reconnaissance. However, it does not explicitly state when to use this tool vs. alternatives, nor does it provide exclusion criteria or alternative tool suggestions. Usage context is implied but not clearly specified.
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 the full burden. It discloses the grading and flagging behavior but omits side effects like network requests, authentication needs, or error handling. It is adequate but not thorough for a tool that fetches external URLs.
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 primary action. It lists specific headers in a structured manner, but could be slightly more streamlined. Still, every sentence serves a 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?
For a single-parameter tool with no output schema, the description covers what is audited (headers, leaks, cookies) and notes the 'in scope' constraint. It is fairly complete, though additional detail on return format or errors would improve it.
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 only parameter 'target' has 0% schema description coverage. The description clarifies that it expects a URL ('Fetch a URL'), adding semantic meaning beyond the bare schema type 'string'. This compensates for the schema gap.
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 fetches a URL and audits HTTP security headers, listing specific headers and their grades. It also mentions flagging information-leaking headers and risky cookie flags, distinguishing it from siblings like tls_inspect or http_probe.
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 explicit guidance on when to use this tool versus alternatives. The phrase 'In scope only' implies a constraint but does not offer criteria for selection or exclusions, leaving the agent to infer usage context.
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 discloses key behaviors: single request, default HTTPS, return fields, and redirect chain. However, it omits error handling, rate limits, and scope enforcement details.
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?
Two sentences, dense with information, first sentence front-loads the action and return fields, second clarifies input flexibility. No wasted words.
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?
The description covers the core functionality and return values adequately for a simple tool, but lacks details on error cases, prerequisites, or scope handling that would be expected given no annotations or output schema.
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?
With 0% schema description coverage, the description adds value by explaining the target parameter (bare host vs full URL, default https) but does not explicitly describe method, verify_tls, or follow_redirects. The return fields hint at some behavior.
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 sends a single HTTP request and returns a structured result including specific fields. It distinguishes itself as 'the primary building block for web recon' among siblings like fingerprint or content_discovery.
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 usage for basic HTTP probing but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites are mentioned.
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 the full burden. It lists the types of information returned and constrains operation to in-scope targets, but it does not disclose whether the tool is read-only, any potential side effects, authorization requirements, or error handling 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, key outputs, and a usage hint. It is front-loaded with the core action, though a slightly more structured format could improve readability.
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 2 parameters and no output schema, the description covers the main purpose and important outputs. It lacks details on return format or error cases, but given the tool's simplicity, it is reasonably complete.
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?
Schema coverage is 0%, so the description must compensate. It implies 'target' is a host and mentions default port 443, but does not fully describe parameter semantics or constraints. It adds some value beyond the raw schema but not complete clarity.
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 inspects a host's TLS certificate and lists specific details returned (subject, issuer, validity, etc.), with a strong emphasis on Subject Alternative Names for recon. It distinguishes itself from sibling tools by focusing on TLS inspection and operating only on in-scope targets.
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 usage for TLS certificate inspection and notes 'In scope only' as a constraint. However, it does not provide explicit guidance on when to use this tool versus alternatives like fingerprint or dns_lookup, nor does it specify conditions 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that results are sorted by CVSS base score (descending). However, no annotations exist, and the description does not mention rate limits, pagination, or response format, leaving gaps in behavioral understanding.
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?
Two sentences with zero waste. Front-loaded with verb, resource, and example, making it immediately actionable.
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?
Covers core purpose and sorting behavior but lacks explanation of return fields, pagination, or result format. For a search tool with no output schema, this is a gap. Sibling tools like cve_lookup hint at additional functionality but not described.
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?
Schema has two parameters (keyword, limit) with 0% description coverage. Description only illustrates 'keyword' via example and does not explain 'limit' or its default, failing to add significant meaning beyond the 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?
Description clearly states 'Keyword-search the NVD for CVEs' with a concrete example, distinguishing it from siblings like cve_lookup (direct lookup) and vuln_scan (broader scanning).
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 this to map a fingerprinted product/version to known vulnerabilities', providing clear context. Does not explicitly state when not to use or mention alternatives, but sibling tool cve_lookup implies a different use case.
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 exist, so the description carries full burden. It only states 'list', indicating a read operation, but lacks details on authentication, real-time vs cached data, or output format. This is minimal but not contradictory.
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 short sentence, front-loaded with action and object. No wasted words.
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 no parameters and no output schema, the description is minimal but sufficient for a simple list. However, it lacks details about output representation or potential side effects, which would be helpful for an agent.
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?
Tool has zero parameters, so baseline score 4 applies. Description adds no parameter info, but no parameters exist to document.
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 uses specific verb 'List' and resource 'scope entries', clearly distinguishing from sibling tools that add, exclude, or remove entries. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for viewing scope but provides no explicit context on when to use versus alternatives like recon_target or scope_add. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a dependency (dnspython for certain record types) and that it attempts a reverse PTR lookup. With no annotations provided, it carries the full burden and does so well, though it omits details on error handling or result format.
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?
Two sentences, no unnecessary words. Front-loaded with the main action and key details. Efficient and to the point.
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's simplicity (one required parameter, no output schema), the description covers the main functionality, dependency, and a secondary action (reverse lookup). It is complete enough for an agent to understand what to expect.
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?
Schema coverage is 0%, so the description must compensate. It clarifies the 'target' parameter is a hostname for DNS resolution, but does not specify format (e.g., FQDN) or validate constraints beyond scope. Adds some meaning but not comprehensive.
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 'resolve' and the resource 'host's DNS records', listing specific record types (A/AAAA, MX/NS/TXT/CNAME/SOA/CAA) and reverse PTR lookup. This distinguishes it from sibling tools like 'enumerate_subdomains' or 'host_intel'.
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 mentions a prerequisite ('target must be in scope') but does not provide guidance on when to use this tool over alternatives like 'enumerate_subdomains' or 'host_intel'. Usage context is implied but not explicit.
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 burden. It explains the tool fetches a URL and returns version hints with evidence, but does not disclose potential rate limits, side effects, or permission requirements.
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 sentence that efficiently conveys the tool's action and outputs, with 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?
For a simple one-parameter tool, the description covers the purpose, scope constraint, and high-level return content (version hints and evidence). Without an output schema, it provides sufficient context, though details on error handling or out-of-scope behavior are missing.
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 description compensates. It implies 'target' is a URL by stating 'Fetch a URL,' adding meaning beyond the schema's bare 'Target' title. More explicit format details would improve clarity.
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 fetches a URL and fingerprints its technology stack, listing specific categories (web server, CDN/WAF, etc.). This distinguishes it from sibling tools like analyze_headers or host_intel.
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 includes 'In scope only,' which gives a constraint on usage, but does not provide when to use this tool versus alternatives or when to avoid it.
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 full burden. It discloses non-intrusive, safe nature and that it chains other tools. However, it does not detail rate limits, error handling, or side effects, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first sentence states the core purpose; the second elaborates without redundancy.
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?
Description covers the key actions (subdomain enumeration, DNS, TLS, HTTP probe, header grade, tech fingerprint) adequately for a composite tool, though it lacks details on output format or error behavior. No output schema present.
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?
Schema coverage is 0%. Description mentions 'domain' but does not explain the 'include_subdomains' parameter or provide additional detail beyond the schema, so it adds limited value for the boolean parameter.
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 explicitly states it performs 'one-shot passive+light recon' and lists specific tasks: subdomain enumeration, DNS, TLS, HTTP probe, header grade, and tech fingerprint. It clearly distinguishes from sibling tools by being a composite of safe 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description recommends it as 'the first call against a new target' and states 'no intrusive scanning'. It implicitly differentiates from more specific or intrusive tools, but does not explicitly list when not to use or name alternatives.
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 transparently lists the files fetched and what is extracted from each (paths, URLs, etc.) and mentions scope restrictions. It does not elaborate on network behavior or rate limits, but the core actions are clear.
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 main action and then listing specifics. It could be slightly more structured (e.g., breaking into sentences for each file), but it is efficient and avoids 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?
Given the tool's simplicity (one parameter, no output schema), the description provides a complete picture of what the tool does, including which files, what is extracted, and scope. It enables an agent to assess suitability for discovery tasks.
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 only parameter 'target' is not described in the description. With 0% schema description coverage, the description should clarify what 'target' expects (e.g., hostname or URL), but it fails to do so, leaving ambiguity.
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 it fetches and parses well-known files (robots.txt, sitemap.xml, security.txt, humans.txt) and extracts specific elements from each. It distinguishes itself from the sibling 'content_discovery' by being focused on these specific disclosure files.
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 notes it is 'quick, low-noise' and 'in scope only,' implying it is ideal for initial reconnaissance. However, it does not explicitly state when not to use it or provide direct alternatives among siblings.
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?
Discloses intrusive nature and required permissions. Reports what is returned (status, size, content type). No annotations provided, so description carries burden. Lacks details on concurrency and rate limiting, but overall good.
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?
Two well-structured sentences. First sentence states purpose and scope, second details behavior and requirements. 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?
Fairly complete given no annotations or output schema. Covers purpose, permissions, parameters partially. Missing concurrency explanation, but overall adequate for agent selection.
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?
Schema coverage 0%, description adds meaning for 'target' (in-scope host) and 'wordlist' (built-in or caller-supplied). Does not explain 'concurrency' parameter.
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 probes an in-scope host for common sensitive paths, providing specific examples like admin panels, .git, etc. It distinguishes from siblings by focusing on sensitive path discovery.
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?
Provides clear context: requires MOONMCP_ALLOW_INTRUSIVE and host in scope. Mentions built-in vs caller-supplied wordlist. Does not explicitly state when not to use or alternatives.
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 discloses key behavioral traits: it is passive (no packets sent), queries multiple sources in parallel, merges results, and allows source restriction. It does not mention rate limits or data freshness, but for a read-only tool the disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences, front-loading the core purpose. No superfluous words, and the information is well-structured for quick parsing.
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?
While the description covers purpose, parameters, and behavior, it lacks output details (e.g., format of results, additional metadata) and does not mention authentication requirements. Given no output schema, this missing information reduces completeness for an agent expecting to process results.
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 description adds meaning beyond the schema by explaining the `sources` parameter's purpose (restrict providers) and referencing `server_status` for available options. Although the schema has 0% description coverage, the description compensates well for both parameters.
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 specific verb 'enumerate subdomains' and the resource 'domain', and distinguishes it from sibling reconnaissance tools by specifying it is passive and uses OSINT sources. This makes the tool's purpose immediately clear and distinct.
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 clear context for when to use the tool (passive subdomain enumeration) and mentions optional provider restriction. However, it does not explicitly state when not to use it or suggest alternative tools for active enumeration, though this is implied.
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 discloses intrusive behavior, external tool dependency, and parameter mapping. It does not detail output or side effects, but adequately characterizes the tool as a non-safe, external-scanning operation.
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?
Two short paragraphs, first sentence captures purpose, every sentence adds critical information (prerequisites, parameter mapping, restrictions). No wasted words.
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 no output schema, the description lacks details about return values or result formatting, which could help an agent anticipate the response. Otherwise, it covers prerequisites and parameter usage adequately.
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 explain parameters. It maps 'templates' to nuclei -t and 'severity' to -severity with an example. 'Target' is implied by context but not further detailed; overall adds value beyond the 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 'Run a nuclei template-based vulnerability scan against an in-scope target,' specifying the verb, resource, and tool. It distinguishes from siblings like port_scan and run_scanner by explicitly mentioning nuclei and templates.
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 prerequisites (nuclei installed, no safe stdlib equivalent), and intrusive nature requiring env vars. It implies when to use but does not explicitly name alternatives among siblings.
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, but the description adequately explains what the tool returns: description, CVSS score/severity/vector, CWE mappings, and references. It implies a read-only, non-destructive operation.
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?
Two sentences: first states purpose and syntax, second details outputs. No wasted words, front-loaded with the most important information.
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 single-parameter lookup tool with no output schema or annotations, the description provides sufficient information about purpose, input format, and output content. Missing details like rate limits or data source specifics, but acceptable for this complexity.
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 single parameter 'cve_id' is given an example format (e.g., CVE-2021-44228) in the description, which adds significant meaning beyond the schema's minimal title. Schema coverage is 0%, so the description compensates well.
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 looks up a single CVE by ID, specifies the resource (NVD database), and distinguishes from sibling tools like cve_search which likely perform broader searches.
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?
It explicitly says 'Look up a single CVE by ID', providing clear context for when to use this tool. While no explicit when-not-to-use or alternatives are given, the sibling list implies cve_search is for broader queries.
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, so description carries burden. Discloses passive behavior, two modes (free InternetDB vs full API if key configured). Could mention rate limits or data freshness, but covers key points.
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?
Two short paragraphs, no redundant information. Every sentence adds value. Front-loaded with main action.
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?
No output schema, so description should describe return values. It lists some free InternetDB data (ports, hostnames, etc.) but could explicitly state output format. Still complete enough for a simple lookup 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?
Only one parameter 'ip' with 0% schema coverage. Description context implies the parameter is an IP address. No format details (IPv4/IPv6, CIDR), but purpose makes it clear. Adequate given simplicity, but schema coverage gap warrants slight deduction.
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 'Look up an IP's exposure via Shodan.' The verb 'look up' and resource 'IP's exposure' are specific. Distinguishes from siblings like 'port_scan' (active) and 'dns_lookup' (DNS records) by specifying Shodan as the source.
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?
Describes when to use: passive reconnaissance via Shodan. Mentions it is passive and queries Shodan, not the target, implying use case. Does not explicitly list when not to use or alternatives, but context from sibling names provides differentiation.
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 burden. It implies a read-only listing operation with no side effects, and adds detail about the output (CLI list, install status, fallback). It does not explicitly state safety, but the behavior is clear from 'List'. Additional context about rate limits or auth is not needed for this simple listing 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 consists of two concise sentences with no unnecessary words. The first states functionality, the second provides usage guidance. Every sentence adds value.
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?
Given the tool has no parameters, no output schema, and no annotations, the description fully covers what the agent needs: what it returns and when to use it. It is complete for its purpose.
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 the schema coverage is 100% by default. The baseline for such cases is 4. The description does not need to add parameter information.
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 lists external security CLIs known to MoonMCP, their installation status on PATH, and the native MoonMCP fallback for each. It uses specific verb 'List' and resource 'external security CLIs', and distinguishes from siblings run_scanner and vuln_scan by advising use before them.
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 explicitly advises use before calling run_scanner or vuln_scan to know what is available. This provides clear context, though it doesn't mention other scenarios or when not to use. Still, it's helpful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses: allowed tool list, verbatim argument passing, optional target with scope check, missing tool fallback (structured note + native command), JSONL auto-parsing, and an environment variable gate. This is comprehensive.
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 two sentences: the first states the core purpose, the second elaborates key behaviors. Every phrase earns its place with no redundancy.
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?
Given the tool's complexity (external command execution) and minimal schema, the description covers all critical aspects: allowed tools, argument handling, target scope, error behavior, output parsing, and access gating. No output schema exists, but the description adequately hints at return format.
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 explains the allowed values for 'tool', the verbatim nature of 'args', and the optional 'target' with scope checking. While it doesn't detail argument syntax, it adds substantial meaning beyond the schema's bare type/title.
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 starts with a clear verb+resource: 'Run an installed external security CLI and return its output.' It distinguishes from sibling tools by specifying it runs known external tools, which sets it apart from other recon/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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the allowed tools and provides some usage constraints (verbatim args, scope checking, env gating) but does not explicitly compare to siblings or state when not to use it. It implies a specific use case but lacks direct exclusions.
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. It discloses a key behavioral trait: active tools will not touch anything not covered by the scope. No contradictions or omissions noted.
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 concise paragraph, front-loaded with the primary action, and includes examples efficiently. Every sentence adds value.
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?
Given the tool's simplicity (one parameter, no output schema), the description is fully complete. It covers what the tool does, how to use it, and the impact on active testing.
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?
Schema coverage is 0%, so the description must compensate. It thoroughly explains the 'target' parameter with examples (domain, wildcard, exact host, IP, CIDR), adding essential meaning beyond the schema's bare 'string' type.
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 ('Authorize') and resource ('target for active testing'), clearly stating the tool's function. It distinguishes from sibling tools like scope_remove and scope_exclude by focusing on adding scope.
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 explains when to use the tool (to add targets to active testing scope) and implies that active tools will refuse non-scoped targets. It lacks explicit mention of alternatives or when not to use it, but the context is clear.
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?
Without annotations, the description carries full burden. It details what is reported (scope, scanning flags, enhancers, CLIs) and implies non-destructive read. Could explicitly state it has no side effects, but high coverage earns a 4.
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?
Two efficient paragraphs with no filler. Every sentence adds value; front-loaded with 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?
Despite no output schema, the description enumerates exactly what the tool reports. No gaps remain for a status tool.
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?
No parameters exist, so schema coverage is 100%. Description adds no redundant info; baseline is met.
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?
Verb 'Report' and resource 'MoonMCP's configuration and capabilities' are clear. No sibling tool serves this status function, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this first to understand what the server can do' — provides clear usage context and implies sequencing relative to other tools.
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/Moonwuk/MoonMcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server