What can you do with this server?

Read-only EDC product discovery against Drop Beacon's public catalog (per the README, schema-listed api_key arguments and the get_price_comparison/get_market_trends tools are retired and unsupported). * Search the catalog (search_products): find everyday-carry gear by keyword, brand, or category; up to 25 matches with titles, prices, availability, brands, images, and product links. * See what's new (get_latest_drops): recent in-stock listings first seen in the last 7 days (schema says up to 30; README caps the tool family at 25-result snapshots). * Research a brand (get_brand_info): public brand profile with product counts, price range, categories, and top products. * Check stock (check_availability): up to 10 matching available listings with per-retailer prices and purchase links for a named product. * Retired/unavailable (get_price_comparison, get_market_trends): not offered by this public MCP — use the website's market and comparison pages instead. * Constraints: no database access, no credentials/API keys, no direct SQL or arbitrary URLs; 60 tool calls/minute locally, catalog snapshots only (not a stock guarantee).

de en es ja ko ru zh

Drop Beacon

by direct-web

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Drop Beacon MCP

Read-only EDC product discovery through Drop Beacon's public HTTPS catalog API. No database password, DATABASE_URL, or API key is required.

Install

Requires Node.js 20 or newer. Configure your MCP client:

{
  "mcpServers": {
    "drop-beacon": {
      "command": "npx",
      "args": ["-y", "drop-beacon-mcp@0.3.0"]
    }
  }
}

Related MCP server: vr-org-mcp

Tools

Tool	Public data returned
`search_products`	Up to 25 currently available catalog matches
`get_latest_drops`	Recent in-stock listings first seen within seven days
`get_brand_info`	Public brand profile and available-product count
`check_availability`	Up to 10 matching available listings

Categories: knife, fidget, flashlight, pen, wallet, multi_tool, patch, other. Search arguments accept up to 120 characters. Results are catalog snapshots, not guarantees of current retailer stock. Compare the exact material, configuration and condition on the linked product page. No match does not mean unavailable everywhere. First seen means discovered by Drop Beacon, not released by the manufacturer.

Migration from 0.2.x

Remove DATABASE_URL and API_KEY from client and hosted-service settings. Upgrade any cached installation to 0.3.0 or newer. If a real database password was ever shared, revoke it with the database provider; editing a listing alone cannot revoke access.

Direct SQL access, arbitrary URLs, private records, and internal market analytics are not supported. get_market_trends and get_price_comparison have been retired from this public MCP; use the market pages and product comparison on the website. The old optional API_KEY gate and legacy SSE endpoints are removed. Do not send credentials as tool arguments.

Security boundary

The package has no database driver and only performs credential-free GET requests to https://edc4me.com/api/drops and /api/brands. Explicit output allowlists prevent new upstream fields from silently becoming MCP output. Requests reject redirects, time out after 15 seconds, cap response bodies at 2 MB, and return generic errors without upstream response bodies. Tool arguments cannot override the origin, endpoint, HTTP method, or headers.

The process allows 60 tool calls per minute, shared across clients and reset on restart; this is a best-effort local limit, not a distributed quota. The public API also applies its own edge protections. A 429 response asks the client to wait, never to supply database access.

Stdio is the default. Optional stateless HTTP uses PORT, binds to loopback by default, and serves POST /mcp plus GET /health. Hosted services can explicitly set HOST=0.0.0.0. Browser origins other than https://edc4me.com are rejected, request bodies are limited to 64 KB, and batched requests are rejected. No customer-specific authentication is needed because only public catalog data is available.

Development

npm ci && npm test

npm run security:scan scans tracked files, including documentation and environment examples, without printing secret values. See SECURITY.md for limitations and local hook setup.

Drop Beacon · Public API · MIT

Available Tools

4 tools

check_availabilityA

Read-onlyIdempotent

Find available catalog matches for a product name. No match does not mean unavailable everywhere. Confirm precise material, configuration, price and retailer stock on the linked page.

Name	Required	Description	Default
`product`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine value beyond them: results are approximate catalog matches, absence of a match is not global unavailability, and precise material/configuration/price/stock must be verified on the linked page — important interpretive context for an open-world lookup.

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?

Three short sentences, front-loaded with the core action before the caveats. Nothing is redundant, though the final sentence about confirming details on the linked page is slightly tangential to invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only lookup with rich annotations and no output schema, the description supplies what is missing: the nature of the matches and how to interpret a negative result. It stops short of describing what a match entry contains beyond implying a linked page.

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?

Only one parameter exists ('product') and the schema documents no constraints at all (0% coverage, no description). The description compensates by clarifying the parameter is a product name used for matching, which is the key semantic an agent needs; a higher score is capped by the absence of any guidance on name format or ambiguity handling.

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?

States a specific verb ('Find') and resource ('available catalog matches for a product name'), so an agent knows this is a catalog-match lookup rather than a pure inventory check. It is clear on its own, but it never distinguishes itself from the sibling search_products, which sounds like it could also return catalog matches.

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 (checking availability by name) and adds a useful interpretation caveat that a no-match result is not proof of universal unavailability. However, it gives no explicit when-to-use guidance versus search_products or the other siblings, leaving the choice to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_brand_infoB

Read-onlyIdempotent

Find a public brand profile and its available-product count. No internal analytics or customer records.

Name	Required	Description	Default
`brand`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description usefully adds that only public data is exposed and internal analytics/customer records are out of scope, but says nothing about lookup failure behavior, fuzzy matching, or data freshness.

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?

Two short sentences with the primary capability front-loaded and the scope exclusion second. No padding, though the second sentence is a bare negation that could carry more routing value.

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 one-parameter read tool with annotations covering safety, the description does state the return content (brand profile plus available-product count), which partly offsets the missing output schema. However, the input's meaning is left entirely unexplained and no not-found/error behavior is described, leaving it only minimally 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%, so the description carries the full burden for the single 'brand' parameter, and it provides nothing: no indication whether 'brand' is a name, slug, or ID, and no format or matching guidance. This is a clear gap the description should have compensated for.

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 names a specific verb ('Find') and resource ('public brand profile and its available-product count'), so an agent can distinguish it from product-search siblings like search_products. It stops short of naming or contrasting any sibling explicitly, so it lands at 4 rather than 5.

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 clause 'No internal analytics or customer records' draws a boundary that implies when this tool is appropriate (public brand data lookups only), but it never states when to use it over search_products or check_availability, nor any prerequisites. Usage is implied rather than instructed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_latest_dropsA

Read-onlyIdempotent

Read in-stock listings first seen within seven days. First seen is a discovery date, not a manufacturer release date. Results are a bounded sample, not the entire market.

Name	Required	Description	Default
`limit`	No
`category`	No

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavioral context: 'first seen' is a discovery date rather than a release date, and results are a bounded sample rather than a complete market view. Those caveats materially affect interpretation of the output.

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 short, front-loaded sentences with zero filler; each one carries a distinct piece of information (scope, date semantics, result completeness). Nothing could be cut without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only two-parameter read tool with annotations covering the safety profile and no output schema, the description supplies the essential scope and data-interpretation caveats. The one gap is parameter meaning, but the small, mostly self-explanatory schema limits the impact.

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 neither parameter is named or explained. 'Bounded sample' loosely gestures at the limit, and the category enum values are self-describing, but the description does not clarify what limit actually controls (count cap of 25) or how category filters results.

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?

States a specific verb and resource ('Read in-stock listings') plus a precise scope ('first seen within seven days'). An agent can distinguish it from check_availability or search_products by the recency window, though no sibling is named explicitly.

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 by the seven-day discovery window, and 'bounded sample, not the entire market' hints that a broader search (e.g. search_products) is needed for full coverage. However, no explicit when-to-use or when-not-to-use guidance or named alternative is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_productsB

Read-onlyIdempotent

Search currently available public EDC catalog listings. Prices may represent different configurations; verify the product page before comparing or purchasing.

Name	Required	Description	Default
`brand`	No
`limit`	No
`query`	No
`category`	No

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that with the warning that prices may reflect different configurations and need verification on the product page. It still says nothing about result ordering, pagination, or what an empty result means.

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 tight sentences with no filler; the core purpose is front-loaded and the reliability caveat follows immediately. Every sentence 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?

No output schema exists, so the description would ideally say something about the shape or reliability of returned listings, and it does partially via the price-configuration warning. However, four undocumented parameters and no statement about result volume or ordering leave gaps for an agent that must decide how to constrain a search.

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% across four parameters, so the description carries the burden and adds essentially nothing: brand, query, category, and limit are never explained, nor is the max of 25 on limit or the meaning of the category enum values. The only faint signal is that searching is textual, which the tool name already conveys.

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?

States a specific verb and resource ("Search ... public EDC catalog listings") and narrows scope with "currently available", which distinguishes it from a general catalog dump. It does not explicitly contrast itself with siblings like get_latest_drops or check_availability, so an agent must infer the boundary.

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 by "search" and the caveat "verify the product page before comparing or purchasing" hints that results are not authoritative for purchase decisions. There is no explicit when-to-use or when-not-to-use guidance, and no sibling tool is named as the alternative for browsing new drops or checking stock.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.3.0Oct 20, 2026

Changedcheck_availability5 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / api_key

Removed value: -{
-  "description": "Optional API key for authenticated access.",
-  "type": "string"
-}

removedInput schema / properties / product / description

Removed value: -"Product name or URL slug to check availability for (e.g., 'Chris Reeve Sebenza', 'hinderer-xm-18')"

addedInput schema / properties / product / maxLength
```
Added value: +120
```
addedInput schema / properties / product / minLength
```
Added value: +1
```

Changedget_brand_info5 fields changed
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / api_key
```
Removed value: -{
-  "description": "Optional API key for authenticated access.",
-  "type": "string"
-}
```
- removedInput schema / properties / brand / description
```
Removed value: -"Brand name or URL slug to look up (e.g., 'Spyderco', 'chris-reeve', 'Benchmade')"
```
- addedInput schema / properties / brand / maxLength
```
Added value: +120
```
- addedInput schema / properties / brand / minLength
```
Added value: +1
```

Changedget_latest_drops8 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / api_key

Removed value: -{
-  "description": "Optional API key for authenticated access.",
-  "type": "string"
-}

removedInput schema / properties / category / description

Removed value: -"Filter drops by product category (e.g., 'knives', 'flashlights', 'fidgets_haptics')"

addedInput schema / properties / category / enum

Added value: +[
+  "knife",
+  "fidget",
+  "flashlight",
+  "pen",
+  "wallet",
+  "multi_tool",
+  "patch",
+  "other"
+]

removedInput schema / properties / limit / description

Removed value: -"Number of results to return (default: 15, max: 30)"

addedInput schema / properties / limit / maximum
```
Added value: +25
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

Removedget_market_trends
Removedget_price_comparison

Changedsearch_products14 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / api_key

Removed value: -{
-  "description": "Optional API key for authenticated access.",
-  "type": "string"
-}

removedInput schema / properties / brand / description

Removed value: -"Filter by brand name (e.g., 'Spyderco', 'Benchmade', 'Olight', 'Magnus')"

addedInput schema / properties / brand / maxLength
```
Added value: +120
```
addedInput schema / properties / brand / minLength
```
Added value: +1
```

removedInput schema / properties / category / description

Removed value: -"Filter by product category. Options: knives, wallets, flashlights, pens, fidgets_haptics, multi_tools, watches, bags"

addedInput schema / properties / category / enum

Added value: +[
+  "knife",
+  "fidget",
+  "flashlight",
+  "pen",
+  "wallet",
+  "multi_tool",
+  "patch",
+  "other"
+]

removedInput schema / properties / limit / description

Removed value: -"Number of results to return (default: 10, max: 25)"

addedInput schema / properties / limit / maximum
```
Added value: +25
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

removedInput schema / properties / query / description

Removed value: -"Search keyword to match against product titles (e.g., 'titanium knife', 'Olight flashlight', 'fidget spinner')"

addedInput schema / properties / query / maxLength
```
Added value: +120
```
addedInput schema / properties / query / minLength
```
Added value: +1
```

6 tool updatesv0.2.0Apr 12, 2026
- First observedcheck_availability
- First observedget_brand_info
- First observedget_latest_drops
- First observedget_market_trends
- First observedget_price_comparison
- First observedsearch_products

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-10-20 04:45 across 4 tools

Disambiguation4/5

Most tools have clearly distinct intents: get_latest_drops, get_brand_info, and check_availability are separable by purpose. However, search_products and check_availability both return available listings and could be confused, though their descriptions distinguish general search from a specific product-name availability check.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: search_products, get_latest_drops, get_brand_info, check_availability. The verbs vary appropriately with the action, and there is no mixing of conventions.

Tool Count5/5

Four tools are well-scoped for a read-only EDC catalog discovery server. Each tool covers a distinct user need (search, new drops, brand info, availability check), with no bloat or excessive thinness.

Completeness4/5

The surface covers core discovery operations: searching products, viewing latest drops, getting brand info, and checking availability. Minor gaps include no direct product-detail endpoint or category/brand listing, though the descriptions point to external linked pages for detailed verification.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

pocket-agent-mcp A
io.github.cwhited26
Pocket Agent (aipocketagent.com) MCP server — read tools for personas, apps, and product info.
Agent Orchestration AI & Machine Learning
411
https://aipocketagent.com/api/mcp
Agentic.ai Directory A
io.github.u00dxk2
Independent directory of agentic AI tools — search, compare & recommend via MCP. Read-only.
Search AI & Machine Learning Agent Orchestration
102
https://agentic.ai/mcp
AgentScout A
com.agentscouthq
Read-only search over 2,065+ AI agent tools and 276 MCP servers. Free, no sign-up needed.
Search Developer Tools
51
https://mcp.agentscouthq.com/mcp
agentic-commerce A
io.bosonprotocol
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Blockchain E-commerce & Retail Autonomous Agents
632
https://mcp.bosonprotocol.io/mcp

Related MCP Servers

amazon-in-mcp
E-commerce & Retail Search
justadityaraj
A
license
A
quality
C
maintenance
MCP server for amazon.in — cheapest in-stock, best-value picks, and price history links.
Updated 4 months ago (2026-07-11 14:44 UTC)
2
3
77 npm
10
MIT
vr-org-mcp
Entertainment & Media Search Games & Gamification
evanatpizzarobot
A
license
A
quality
A
maintenance
Read-only MCP server for VR.org providing live VR/AR/XR news, editorial, deals, headset comparisons, top games/apps, and Q&A through ten tools. Requires no API keys or configuration.
Updated 22 days ago (2026-10-13 05:44 UTC)
11
69 npm
MIT
Destiny Codex
Games & Gamification Search
OpenChatGit
A
license
Not graded
quality
D
maintenance
MCP server for querying Destiny 2 game data from Bungie's manifest. Provides tools for item lookup, search, filtering, perk rolls, and relationship traversal.
Updated 4 months ago (2026-07-02 11:21 UTC)
2
PolyForm Noncommercial 1.0.0
tgden
Search Communication Open Data
JustJuice55
A
license
Not graded
quality
C
maintenance
Public Telegram catalog MCP server: search 1.4M+ channels, groups, bots, and posts, and browse marketplace listings, with no auth or API key.
Updated 9 days ago (2026-10-26 12:12 UTC)
1
MIT