Beacon - verified-merchant index for AI shopping agents
Server Details
Neutral verified-merchant index for AI shopping agents; regulated/alcohol-first; earned-trust only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- primoliquors/beacon-skill
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.3/5 across 5 of 5 tools scored. Lowest: 2.7/5.
Each tool has a distinct purpose: find_best_merchant ranks merchants, get_merchant_view shows details, index_stats provides statistics, search_offerings finds products, and verify_capability checks specific capabilities. No overlap in functionality.
Most names follow a verb_noun pattern (find_best_merchant, get_merchant_view, search_offerings, verify_capability), but 'index_stats' is ambiguous (index as noun or verb?) and breaks the pattern slightly. Overall consistent use of lowercase and underscores.
With 5 tools, the server is well-scoped for a merchant index for AI shopping agents. Each tool covers a core need without redundancy or bloat.
The tool set covers key operations: finding best merchants, viewing details, searching offerings, stats, and verification. Minor gaps (e.g., listing all merchants or categories) but sufficient for the stated purpose.
Available Tools
5 toolsfind_best_merchantAInspect
Rank merchants that can actually fulfill a purchase need, by honest signals only.
Args:
category: product category, e.g. "vodka".
ship_to: ISO region the order must ship to, e.g. "US-FL".
require_age_gate: only return merchants that enforce 21+.
limit: max results.
optimize_for: what matters to the BUYER -- "trust" (default), "price"
(lowest matched price), or "speed" (same-day, then next-day
fulfillment). Ties always break by earned trust.
product_type/dest_state/channel: pass all three (e.g. "spirits", "FL",
"ship"|"local_delivery") for STRICT COMPLIANCE mode -- only merchants
with attested age-gate + attested license + a legal jurisdiction
path are returned, each with its compliance verdict.
Every result carries ships_to states (match them against where the buyer
lives), best_price, and the evidence behind the record. Paid placement never
affects any ranking (ranking_basis states the basis actually used).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| channel | No | ||
| ship_to | No | ||
| category | No | ||
| dest_state | No | ||
| ready_only | No | ||
| optimize_for | No | trust | |
| product_type | No | ||
| require_age_gate | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that paid placement never affects rankings, ranking_basis is stated, and results include evidence. With no annotations, it covers behavioral traits well, though lacks details on potential side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with arguments listed and clear purpose. Slightly lengthy but efficient in conveying necessary info. Front-loaded with main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and no output schema, the description is highly complete. Covers all parameters, describes return values (ships_to states, best_price, evidence), and provides context on compliance and ranking basis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema, which has 0% description coverage. Explains each parameter: category, ship_to, require_age_gate, limit, optimize_for, and the strict compliance mode combination of product_type/dest_state/channel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it ranks merchants that can fulfill a purchase need using honest signals. Distinguishes from sibling tools like get_merchant_view (which likely views details) and search_offerings (which searches offers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool and describes parameters like optimize_for and strict compliance mode. Does not explicitly state when not to use it, but context implies it's for ranking merchants for fulfillment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_merchant_viewCInspect
Full agent view of one merchant: record + offerings + capabilities + evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| merchant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only lists return components but omits any mention of side effects, permissions, rate limits, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's output. It is front-loaded but lacks any structured formatting like bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description provides minimal context. It does not explain the output structure, prerequisites, or when to use this tool over siblings, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only says 'one merchant' which is already implied by merchant_id, adding no details about format, source, or validation of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a comprehensive view of a single merchant including record, offerings, capabilities, and evidence. It distinguishes itself from siblings like search_offerings and verify_capability by aggregating multiple aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 find_best_merchant or search_offerings. The description provides no context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
index_statsBInspect
Graph coverage stats: counts of registry entries, merchants, offerings, capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions 'graph coverage stats' without specifying read-only, caching, or required permissions. For a stat tool, behavioral details like data freshness or side effects are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear, specific information. No wasted words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a parameterless stat tool. Lacks details on return format or data currency, but output schema is absent so agent must infer. Could be improved with behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description does not need to add meaning beyond schema. Baseline of 4 is appropriate as schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'graph coverage stats' with specific counts (registry entries, merchants, offerings, capabilities). It distinguishes from siblings that focus on finding, viewing, or verifying individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when overall coverage statistics are needed. No explicit guidance on when not to use or alternatives, but sibling names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_offeringsCInspect
Find offerings (products) matching a category, joined to merchant + capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No | ||
| in_stock_only | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'joined to merchant + capabilities' implying return shape, but does not disclose read-only nature, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is efficient and front-loaded, but could add more detail without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered, but description lacks details on pagination, ordering, or filtering behavior. For a search tool with 3 parameters, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only hints at 'category' parameter. 'limit' and 'in_stock_only' are not explained, leaving the agent to infer meaning from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds offerings/products matching a category, and mentions joining with merchant and capabilities. It distinguishes from siblings like 'verify_capability' and 'index_stats', but could be more precise compared to 'find_best_merchant'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings like 'find_best_merchant'. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_capabilityBInspect
Verify a merchant capability with evidence, e.g. age_gate_21 or ships_to_US-FL.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | ||
| merchant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, side effects, authentication needs, or return format. For a tool with zero behavioral hints, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys the core purpose without any filler. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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 or annotations, the description lacks completeness. It does not explain the verification logic, return values, or behavioral constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds value by providing examples for the 'capability' parameter (e.g., age_gate_21). However, it does not explain the format of 'merchant_id' or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'verify' and resource 'merchant capability' with concrete examples like 'age_gate_21' or 'ships_to_US-FL'. This distinguishes it from sibling tools which focus on searching, viewing, or indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Does not specify prerequisites, when not to use, or contextual conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!