dropscan-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action, with clear boundaries between scanboxes, mailings, recipients, forwarding addresses, webhook rules, and shipments. No overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, making the set predictable and easy to navigate.
Tool Count4/5
21 tools is slightly high but justified by the multi-entity domain (scanboxes, mailings, recipients, etc.). Each tool serves a specific purpose, though a few could be merged or removed.
Completeness4/5
Core CRUD operations are covered for most entities, but missing delete/update for recipients and forwarding addresses. The essential workflows (receive, scan, forward, destroy, manage webhooks) are well-supported.
Average 3.6/5 across 21 of 21 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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.
This repository includes a glama.json configuration file.
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?
With no annotations, the description carries full burden. It only discloses 'Read-only' and the HTTP method, missing details on authentication, rate limits, or side effects. The behavioral disclosure is minimal.
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 (two sentences plus endpoint), but it lacks parameter descriptions and returns information. It could be more efficient by adding these details without extra fluff.
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 simplicity (one parameter, no output schema), the description is incomplete. It does not mention what the response contains or how the address_id should be formatted. More context is needed for proper 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 description coverage is 0%, meaning the description adds no meaning beyond the schema. The parameter 'address_id' is not explained or contextualized in the description, which fails to compensate for the low 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 uses 'Get' as a specific verb and 'forwarding address by id' as the resource, clearly indicating the operation. It distinguishes from sibling 'create_forwarding_address' and other 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?
The description states 'Read-only' but provides no explicit guidance on when to use this tool vs alternatives like list_recipients or create_forwarding_address. No exclusions or context are given.
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 convey behavioral traits. It states 'Read-only' and shows the HTTP path, but fails to disclose required permissions, behavior on missing scanbox/recipient, or any side effects. The bare minimum is mentioned.
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 brief (2 sentences plus a path), but this brevity comes at the cost of completeness. While there is no fluff, the minimal content does not adequately serve the agent. An average conciseness score is appropriate.
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 two required parameters and no output schema, the description lacks context about return values, error handling, or the resource model. The user gets no sense of what a 'recipient' is or what to expect from the response.
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 does not explain the purpose of scanbox_id or recipient_id beyond their names. With 0% schema description coverage, the tool fails to add meaning to these parameters. Users are left guessing how to obtain valid IDs.
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 retrieves a single recipient of a scanbox with 'Get one recipient of a scanbox. Read-only.' This specifies a verb (get) and resource (recipient), distinguishing it from sibling tools like list_recipients (list) and create_recipient (create).
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 list_recipients for multiple recipients or get_webhook_rule for other resources. The description omits any when-to-use or when-not-to-use 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?
The description mentions 'Read-only' and 'first 5 documents', which are important behavioral traits. However, with no annotations provided, it lacks details on error handling, pagination, authentication, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes the essential verb and resource. The endpoint path is extra but not harmful. It could be more structured but is efficient.
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 no output schema and no annotations, the description should cover return format, error states, and authentication. It only mentions the data scope (first 5 documents), leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no information about the parameters (uuid, scanbox_id) beyond what the schema provides. This is insufficient for a tool with two required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves OCR plaintext for a mailing, limited to first 5 documents. It distinguishes from sibling tools like get_mailing or get_mailing_pdf that return different formats or full data.
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 get_mailing or get_mailing_pdf. The 'Read-only' note provides some context but does not help an agent decide when to invoke this tool over others.
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?
The description indicates the tool is read-only and gives the HTTP method (GET), which is useful. However, it does not disclose potential behaviors such as auth requirements, error conditions, or what happens if save_path is null. With no annotations, the description carries the burden but falls short of full transparency.
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 concise, containing only two sentences and an endpoint. It is front-loaded with the key action. However, it could be slightly more informative without becoming verbose.
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 three parameters, no output schema, and no annotations, the description is incomplete. It lacks parameter documentation and behavior for optional fields like save_path. More detail is needed for a download tool that handles file saving.
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 input schema has 0% description coverage, and the description does not explain any parameters. While the endpoint hints at 'scanbox_id' and 'uuid', no semantics are provided for 'save_path' or the required parameters beyond the schema's type.
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 action ('Download a mailing's ZIP') and specifies the resource ('individual PDFs') with the verb 'download'. It also includes the HTTP endpoint and identifies the tool as 'Read-only', which distinguishes it from mutation 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?
The description does not provide guidance on when to use this tool over siblings like get_mailing_pdf or get_mailing. It mentions 'Read-only' but lacks explicit context for selection or exclusion of alternatives.
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?
The description declares 'Read-only', but with no annotations provided, it carries the full burden. However, it does not disclose authorization needs or rate limits, which are relevant for a read operation.
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 very concise (two lines) and front-loaded with the action. However, it would benefit from including parameter details without becoming overly verbose.
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 is provided, and the description does not explain the return value. Combined with missing parameter semantics, the description is incomplete for an agent to fully understand the tool's behavior.
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 sole parameter 'rule_id' has no description in the schema or the tool description. With 0% schema coverage, the agent has no semantic understanding of what the parameter expects.
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 action 'Get one webhook rule by id' and specifies it's read-only, which differentiates it from sibling tools like list_webhook_rules, create_webhook_rule, etc.
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 (e.g., list_webhook_rules for fetching all rules). The description does not mention prerequisites or 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 provided, so the description carries the full burden. It mentions 'Read-only' and provides the HTTP endpoint, but omits details such as file size, return format, error conditions, or side effects. The read-only hint is minimal and does not fully disclose 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?
The description is short (two sentences plus an endpoint line) and front-loaded with the core action. It wastes no words, but the structure could be improved by grouping related information. Minor point: the endpoint adds context but is not essential.
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?
Given no output schema and no annotations, the description provides basic purpose and read-only nature. However, it lacks details on how save_path works, the nature of the returned image, and error handling. Adequate for simple use but not fully 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 0%, and the description does not explain any parameters except indirectly via the endpoint path (scanbox_id, uuid). The save_path parameter is not mentioned at all, leaving its purpose and interaction unclear.
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: 'Download a mailing's envelope image (JPEG) and save it.' It specifies the resource (envelope image) and action (download/save), and distinguishes from sibling tools like get_mailing_pdf or get_mailing_plaintext.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for envelope images specifically, but does not compare to siblings or state prerequisites. Usage is inferred from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Read-only' and provides the HTTP endpoint and default save path. However, it does not disclose overwrite behavior, error handling (e.g., missing PDF), authentication needs, or file size limits. Since no annotations exist, the description carries the burden but leaves gaps.
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 concise (4 lines), front-loaded with the primary purpose, and includes key details like the HTTP route and default save path. No redundant sentences, but could add more context without significant bloat.
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 params, no annotations, no output schema, and many siblings), the description is incomplete. It does not explain the return value (saved file vs. nothing), relationship to other mailing tools, or behavior when a file already exists. An AI agent may lack sufficient context to choose correctly.
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 0%, so the description must add meaning. It explains 'save_path' with a default value and hints that 'scanbox_id' and 'uuid' are path parameters via the HTTP route. However, it does not describe what 'uuid' represents (mailing UUID) or provide detailed context for 'scanbox_id'.
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 'Download a mailing's scanned PDF and save it to disk', specifying the verb (download), resource (mailing's scanned PDF), and action (save to disk). It distinguishes from siblings like 'get_mailing' (likely metadata) and 'get_mailing_zip' (compressed archive).
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 over alternatives like 'get_mailing_zip' or 'get_mailing_envelope'. The 'Read-only' note hints at non-destructive use, but no exclusions or when-not-to-use information is provided.
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. It warns about changing the real production account and specifies the double-gating condition (DROPSCAN_ALLOW_WRITES=1 and confirm=true). However, it does not describe what happens to previous recipients or the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose first, then safety warning, then endpoint hint. No wasted words, highly efficient.
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?
For a 4-parameter tool with no output schema, the description covers the operation and safety gate but lacks parameter explanations and usage context relative to sibling tools. Adequate but not comprehensive.
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 0%, yet description only adds meaning for confirm (via double-gating mention). The other parameters (scanbox_id, mailing_uuid, recipient_id) are not explained or contextualized.
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 clearly states 'Assign a recipient to a mailing' with a specific verb and resource. It implicitly distinguishes from create_recipient (which creates a new recipient) but does not explicitly mention sibling differentiation.
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 like create_recipient or list_recipients. The double-gating requirements are mentioned but no context on when assignment is 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?
The description only states it is read-only. With no annotations provided, it fails to disclose additional behavioral traits such as return format, potential errors, or state dependencies.
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 extremely concise with two sentences and an endpoint reference. No unnecessary information.
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?
For a simple get tool with one parameter and no output schema, the description is minimally adequate. It identifies the resource and states read-only, but could be more complete about return values or error scenarios.
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 description mentions 'by id' but adds no semantics beyond the input schema. The parameter name is self-explanatory, yet with 0% schema description coverage, the description should elaborate on what the shipment_id represents or its format.
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 action 'Get', the resource 'shipment (physical forwarding batch)', and the identifier 'by id'. This distinguishes it from sibling tools like list_recipients or create_recipient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a simple retrieval by ID, but no explicit guidance on when to use versus alternatives or when not to use. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'Read-only' and indicates it is a GET request, implying safety. However, no details are given about authorization, error handling, or rate limits. With no annotations, the description carries full burden, and it is minimally adequate.
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 very concise: one sentence and a URL path. It is front-loaded with the purpose and contains no unnecessary words.
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 one parameter and a simple operation, so completeness is adequate. However, without an output schema, the description does not hint at the response structure (e.g., list of recipient objects), leaving the agent uncertain about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only implies that 'scanbox_id' identifies the scanbox. It does not explain the format, constraints, or how to obtain the ID, providing insufficient compensation for missing schema 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 clearly states the tool lists recipients for a scanbox with a specific verb ('List') and resource ('recipients configured for a scanbox'). It distinguishes from sibling tools like 'create_recipient' (create) and 'list_scanboxes' (list scanboxes).
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 (e.g., 'create_recipient' or 'get_recipient'). There are no explicit when-not-to-use or prerequisite statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the destructive nature and gating requirements. However, it omits details like idempotency, rate limits, or authentication needs, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 6 lines, including a warning and API endpoint reference. Every sentence adds value, but the structure could be improved by separating the warning from parameter documentation.
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 11 parameters, 7 required, no output schema, and no annotations, the description is insufficient. It does not explain the return value, how to fill all required fields, or the full behavior of the confirm parameter. The tool's complexity demands more detail.
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?
With 0% schema description coverage, the description must compensate. It explains country_code and zip_code (including the request body field name for zip), but ignores most other required parameters (firstname, lastname, street, etc.) and optional ones (company, state, info, confirm). The mention of confirm is partial relative to its role.
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 'Create a forwarding address (used as a forward target).' It uses a specific verb and resource, and distinguishes from sibling tools like get_forwarding_address.
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 highlights that the tool modifies the production account and requires double-gating (DROPSCAN_ALLOW_WRITES=1 and confirm=true), providing clear context. However, it does not explicitly mention when to avoid using it or list 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 discloses that it changes the real production account and requires double-gating, which is good transparency. However, it does not detail side effects (e.g., whether update is partial or full replacement) or error states.
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 concise with a clear front-loaded purpose, followed by a warning and HTTP method. It's efficient with no redundant sentences, though it could be more structured by listing parameters.
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?
For a simple update tool, the description provides the purpose and safety guardrails, but omits parameter explanations and return value (no output schema). It is adequate but not fully complete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it fails to explain any parameters. Only the 'confirm' parameter is implicitly mentioned in the warning, but without semantic context. Other parameters (url, events, authorization_header, rule_id) are left undefined.
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 'Update a webhook rule,' which is a specific verb-resource combination. It distinguishes from sibling tools like create_webhook_rule and delete_webhook_rule, and provides the HTTP method PATCH, reinforcing the purpose.
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 warns about affecting production and mentions double-gating requirements (DROPSCAN_ALLOW_WRITES=1 and confirm=true), but does not explicitly state when to use this tool versus alternatives, nor does it provide context for appropriate usage scenarios.
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 full burden. It explicitly states 'Read-only', which is a key behavioral trait. It also includes the HTTP method and endpoint path, adding context beyond the schema. However, it does not mention authentication requirements 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 extremely concise: two lines with no wasted words. The first line states the purpose, and the second line gives the API endpoint, which is informative and efficient.
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?
Given the simplicity of the tool (2 parameters, no output schema), the description is adequate but lacks details about the return format beyond 'details/extracted content'. It does not explain what fields or data will be returned, which would help with completeness.
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 description does not explain the parameters uuid and scanbox_id beyond their presence in the endpoint path. The schema has 0% coverage (no descriptions), and the description does not compensate by clarifying what these IDs represent or how to obtain them.
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 'Get one mailing with its details/extracted content', using a specific verb and resource. It distinguishes from sibling tools like list_mailings (list) and other get_* tools (e.g., get_mailing_pdf) by specifying 'details/extracted content'.
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 for retrieving a single mailing via 'Get one mailing', and notes it is read-only. However, it does not provide explicit guidance on when to use this tool versus alternatives like get_mailing_pdf or get_mailing_zip, nor does it mention prerequisites or context.
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?
Despite no annotations, the description discloses critical behavioral traits: the tool mutates the production account and requires double-gating for safety. It also enumerates event types. However, it does not detail response behavior or error handling, limiting full transparency.
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 brief and front-loaded with the purpose and safety warning. The events list is necessary but could be more concise. Overall, it is well-structured with no superfluous content.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description should provide more context. It covers the safety mechanism and events, but leaves url and authorization_header unexplained. It is minimally complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does by listing valid event values. But it omits descriptions for 'url', 'confirm', and 'authorization_header', leaving the agent to infer their meaning from names alone. This is insufficient for a 4-parameter tool.
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 'Create a webhook rule.' and specifies the endpoint POST /webhook_rules, with a list of allowed events. This verb+resource combination distinctly differentiates it from sibling tools like list, get, update, delete webhook rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Changes the real production account. Double-gated: requires DROPSCAN_ALLOW_WRITES=1 AND confirm=true.' This strongly advises caution and prerequisite conditions, though it stops short of stating when not to use or recommending alternatives.
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?
The description mentions 'Read-only' and the HTTP method (GET), which are behavioral traits. However, with no annotations provided, the description carries the full burden. It does not disclose what the response contains (e.g., list of scanbox objects), pagination, or error handling. A bit more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. The description is front-loaded with the core purpose and includes a clarifying HTTP method and read-only status. Every word earns its place.
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?
Given no output schema and simple parameters, the description is adequate but not fully complete. It does not describe the return format, potential pagination, or what fields are included in scanbox objects. For a list operation, agents would benefit from knowing the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. The description adds value by clarifying the operation's nature (list, read-only) beyond the empty schema. The baseline of 3 is exceeded because the description provides meaningful context for a parameterless tool.
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 action ('List all scanboxes on the account') and the resource ('scanboxes'), with a distinct verb-noun pair. The sibling tools include other list operations (e.g., list_recipients), so it's easy to differentiate.
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?
No explicit guidance on when to use this tool versus alternatives. However, the simple nature of the tool and lack of parameters make usage context self-evident. A brief note on when to prefer list_scanboxes over other list tools would improve the score.
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; description adds 'Read-only' and the HTTP method/endpoint, but lacks details on pagination, rate limits, or empty results.
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 plus endpoint line, no fluff. Efficiently communicates core purpose.
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?
Simple tool, but missing output format description. Lacks guidance on what the returned list looks like.
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 in schema (100% coverage), so description need not add parameter details. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'list' and the resource 'webhook rules on the account', with a read-only note. Distinguishes from sibling tools like create/update/delete.
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?
Implies usage for listing all rules, but no explicit guidance on when to use vs. alternatives like get_webhook_rule or criteria for filtering.
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 warns about changing the real production account, specifics cancellation windows, and the double-gate check. This reveals important behavioral traits beyond the basic 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines of critical information plus the endpoint. Each sentence adds value, and the structure with warning emoji is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (cancellation with time windows and double-gating), the description covers the essential context. It lacks details about return values and error handling, but no output schema is expected.
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 description coverage is 0%, so the description must compensate. It adds meaning to the 'confirm' parameter by explaining its role in double-gating, but it does not describe scanbox_id, mailing_uuid, or action_request_id beyond their names.
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 'Cancel a pending action request on a mailing.' It uses a specific verb and resource, and distinguishes from sibling tool 'request_mailing_action'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains cancellation windows by action type (scan, destroy, forward) and double-gating requirements (DROPSCAN_ALLOW_WRITES, confirm). This guides the agent in when to use the tool, though no explicit 'when not to use' is given.
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?
No annotations exist, but description fully discloses destructive, irreversible nature and the required gating flags. This is exemplary transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with action, warning, endpoint, and conditions. Uses bullet and emoji for emphasis. No superfluous content.
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?
Adequately warns about destructiveness but omits parameter explanation and return values. For a simple destructive action, it covers the main risks, but parameter details are missing.
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 0%, so description must explain parameters. It only mentions confirm requirement implicitly but does not describe rule_id or the confirm parameter's role. Lacks semantic detail for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Delete a webhook rule' with HTTP endpoint, clearly identifying the verb and resource. Differentiates from sibling tools like create_webhook_rule and update_webhook_rule.
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?
Description warns about irreversible production changes and specifies double-gating requirements (DROPSCAN_ALLOW_WRITES=1 and confirm=true). Provides clear context but does not explicitly mention when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the destructive nature ('changes the real production account'), the gating mechanism, and conditional parameter requirements. It does not mention idempotency or side effects, but the essential behavioral traits are covered.
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 moderately sized and uses a warning emoji, a POST endpoint hint, and clear parameter groupings. It is well-structured but could be slightly more concise by removing the redundant 'POST /scanboxes/...' line.
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 covers the main behavior and safety constraints. It is complete for a creation tool with conditional parameters, though it omits the return value or confirmation response.
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?
Schema coverage is 0%, so the description must compensate. It adds meaning to 'type' (Person/Company) and the conditional requirements for firstname, lastname, and name. However, it does not describe 'scanbox_id' or 'confirm' beyond the warning, leaving some parameters underspecified.
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 action ('Create a recipient') and the target resource ('on a scanbox'), providing a specific verb+resource pair. It distinguishes from sibling tools like 'list_recipients' by implying creation rather than listing.
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 includes a prominent warning about affecting production and the double-gating requirement (environment variable and confirm=true). It also explains parameter dependencies (type determines required fields). However, it does not explicitly contrast with alternative tools or specify when not to use this tool.
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 explicitly states the tool is read-only and mentions pagination behavior via the older_than parameter. With no annotations provided, the description carries the full burden, and it adequately covers safety (no destruction) and pagination, though it could mention rate limits or error handling.
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 very concise, with a one-line summary followed by bullet points for each parameter. Every sentence adds value, and there is no redundant or unnecessary information.
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?
The tool is simple and the description covers parameters and read-only nature. However, it omits details like default sorting order, page size, or how to get the next page (beyond the cursor). It is adequate but could be more complete for a listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are thoroughly explained beyond the schema: scanbox_id has an example, current_status lists valid enum values, and older_than explains pagination logic. This fully compensates for the 0% schema description 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 verb 'List' and resource 'mailings in a scanbox', specifying the HTTP endpoint and read-only nature. It distinguishes from siblings like list_recipients or get_mailing by focusing on mailings within a specific scanbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (listing mailings in a scanbox), but does not explicitly mention when not to use it or suggest alternatives like get_mailing for a single mailing. Sibling differentiation is implicit through the resource name.
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?
No annotations provided, so description carries full burden. It clearly warns that destroy physically shreds letters (irreversible), forward incurs cost, and the action is double-gated (env var + confirm). This is excellent behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: short intro, prominent warning, then bullet-pointed argument explanations. Every sentence adds value without redundancy. Uses formatting effectively (⚠️, bold, line breaks).
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 annotations, no output schema, and 6 parameters with 0% schema coverage, the description covers all critical aspects: action types, side effects, parameter dependencies, and required confirm. Could mention return values or errors, but not essential for usage.
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?
Schema coverage is 0%, so description must compensate. It explains action_type values (scan, forward, destroy), requirements for forward (forwarding_address_id and forwarding_date), and confirm must be True. Does not detail scanbox_id or mailing_uuid, but these are self-explanatory from context.
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 requests a physical action on a mailing (scan/forward/destroy). It distinguishes from siblings like cancel_mailing_action and create_forwarding_address by focusing on the action request endpoint.
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?
Provides clear usage context: irreversible actions, cost for forward, double-gate requirement (env var + confirm). Explicitly notes when confirm must be True and when forwarding fields are required. Does not mention alternatives to using this tool but sets strong expectations.
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:

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

Score Badge

Copy to your README.md:

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

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