Agent payments ecosystem intelligence. Scans GitHub, Hacker News, and npm for activity across AP2, ACP, x402, MPP, and UCP protocols. Free protocol comparison, paid scan via x402 USDC.
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.
Average 4.6/5 across 3 of 3 tools scored.
Each tool has a distinct and non-overlapping purpose: compare_protocols for side-by-side comparison, get_protocol_info for in-depth single protocol details, and scan_opportunities for external scanning. Descriptions explicitly clarify when to use each, eliminating ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: compare_protocols, get_protocol_info, scan_opportunities. This pattern is predictable and clear.
Three tools is perfectly scoped for the focused domain of agent payment protocols. Each tool serves a distinct, essential function without redundancy or missing coverage.
The tool set covers all core use cases for the domain: retrieving individual protocol info, comparing multiple protocols, and discovering new developments. There are no obvious gaps for a research-oriented server.
compare_protocolsCompare ProtocolsAGet a side-by-side comparison matrix of all five agent payment protocols (AP2, ACP, x402, MPP, UCP) across creator, layer, agent delegation, budget limits, cross-merchant coordination, and MCP integration. Use when the user asks to compare protocols ('AP2 vs ACP', 'which protocol handles budgets?', 'what's the difference between x402 and MPP?', 'show me the landscape'). Use get_protocol_info instead for deep details on a single protocol.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's safe. The description adds valuable behavioral context by specifying the output is a comparison matrix across specific dimensions (creator, layer, etc.), which goes beyond what annotations alone provide.
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 consists of two sentences: the first defines purpose and content, the second gives usage guidance and alternative. Every sentence contributes value with no wasted words.
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?
The description fully explains the tool's output (comparison matrix with listed dimensions) despite having no output schema. Combined with zero parameters, the description is complete for an agent to understand the tool's behavior.
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?
The tool has zero parameters, so the description does not need to add parameter semantics. Baseline 4 is appropriate; the description correctly omits parameter details since none exist.
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 explicitly states it provides a 'side-by-side comparison matrix of all five agent payment protocols' and lists the dimensions compared (creator, layer, etc.). It clearly distinguishes from the sibling tool get_protocol_info by specifying the scope (all five protocols vs. deep details on a single protocol).
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?
The description explicitly says to use this tool when the user asks to compare protocols (e.g., 'AP2 vs ACP') and directs to use get_protocol_info for deep details on a single protocol, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_protocol_infoGet Protocol InfoAGet the canonical description of an agent payment protocol including creator, maturity level, repo URL, and what layer it operates at (authorization, commerce, or settlement). Use when the user asks about a specific protocol ('what is AP2?', 'who created MPP?', 'is x402 production ready?', 'what layer does ACP operate at?'). Use compare_protocols instead when comparing multiple protocols against each other.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol identifier (e.g., 'ap2' for Google's authorization layer, 'x402' for Coinbase's settlement layer). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety profile is covered. Description adds context about output fields (creator, maturity, repo URL, layer) but no additional behavioral traits beyond what annotations provide. No contradictions. Score is 3 per rubric: annotations cover safety, description adds some context.
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?
Two sentences, front-loaded with the main purpose and return fields, followed by usage guidance and alternative. Every sentence earns its place; no waste.
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 tool's simplicity (1 param with full schema coverage, no output schema, annotations covering safety), the description is complete: it explains what the tool returns, when to use it, and when to use the sibling. No 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 100% for the single parameter 'protocol' with enum and clear description. The tool description adds value by providing examples and associating each protocol with its layer (e.g., 'ap2' for Google's authorization layer). This goes beyond the schema, so score 4.
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 'Get the canonical description of an agent payment protocol including creator, maturity level, repo URL, and what layer it operates at'. It specifies the resource (protocol info) and the fields returned. It distinguishes from sibling compare_protocols by noting when to use each.
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 states when to use ('when the user asks about a specific protocol') with concrete examples, and when not to use ('Use compare_protocols instead when comparing multiple protocols'). Clear alternative provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_opportunitiesScan Agent Payments EcosystemAScan GitHub, Hacker News, and npm for new repos, packages, and discussions in the agent payments ecosystem (AP2, ACP, x402, MPP, UCP). Returns AI-classified and scored opportunities with recommended actions. Use when the user asks about recent activity, new developments, or opportunities in agent payments ('what's new in agent payments?', 'any new x402 repos?', 'scan for opportunities'). Use get_protocol_info instead for static protocol details, or compare_protocols for side-by-side comparison. Costs $0.01 USDC. Accepts: x402 (USDC on Base) or MPP (Tempo USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window in days (e.g., 7 for last week, 30 for last month). Default 7. | |
| min_score | No | Minimum opportunity score out of 20 (e.g., 12 for high-quality only, 8 for broader results). Default 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds critical context: cost ($0.01 USDC), accepted payment methods (x402, MPP), and that results are AI-classified with scores/actions. No contradiction with annotations.
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?
Three concise sentences: purpose, usage cues, cost/payment. Front-loaded with key action, no redundant information.
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?
Despite no output schema, description covers return format (AI-classified/scored opportunities with recommendations), cost, payment methods, and data sources. All essential context for an agent to use effectively.
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 100% with clear descriptions for both parameters (days, min_score). Description does not add additional parameter meaning beyond defaults/cost implication; thus baseline 3 is appropriate.
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 scans GitHub, Hacker News, and npm for agent payments ecosystem developments, with specific verb ('Scan'), resources, and ecosystem scope. It distinguishes itself from siblings (get_protocol_info, compare_protocols) by focusing on dynamic scanning.
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 provides when to use (user asks about recent activity/new developments in agent payments) with example queries, and when not to use (static info: get_protocol_info; comparison: compare_protocols). Excellent guidance.
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.
No comments yet. Be the first to start the discussion!
