Intelligence MCP
Server Details
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.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 4.7/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: comparing protocols, getting detailed info on a single protocol, and scanning for new developments. Descriptions explicitly cross-reference to avoid confusion.
All tool names follow a consistent verb_noun pattern in snake_case: compare_protocols, get_protocol_info, scan_opportunities. No mixing of conventions.
With only 3 tools, the server is tightly scoped to its domain of agent payment protocol intelligence. Each tool earns its place, covering comparison, single protocol details, and ecosystem scanning.
The tool set covers the core needs for an intelligence server: retrieving static details, comparing multiple protocols, and staying updated on new developments. No obvious gaps for the stated purpose.
Available Tools
3 toolscompare_protocolsCompare ProtocolsARead-onlyIdempotentInspect
Get 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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds value by specifying the output is a comparison matrix covering specific dimensions (creator, layer, etc.), providing behavioral context beyond what annotations convey.
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?
Description is extremely concise: two sentences with no wasted words. It front-loads the core purpose and then provides usage examples and alternatives efficiently.
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 no parameters and no output schema, the description is complete. It states the output format (comparison matrix), the exact protocols included, the dimensions covered, and usage context with sibling tool differentiation.
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?
There are no parameters, and schema coverage is 100%. The description does not need to add param information beyond what the schema provides, achieving the baseline for parameterless tools.
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 provides a side-by-side comparison matrix of five specific agent payment protocols across multiple dimensions. It distinguishes itself from sibling tool get_protocol_info by explicitly mentioning that tool is for 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?
Description explicitly provides when to use this tool (when user asks to compare protocols, with example queries) and when to use the alternative (get_protocol_info for deep details on a single protocol). This leaves no ambiguity about tool selection.
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 InfoARead-onlyIdempotentInspect
Get 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). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. Description adds value by detailing returned fields (creator, maturity, repo URL, layer) beyond annotation scope. No contradiction.
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: first states purpose and outputs, second provides precise usage guidance. No redundant 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?
With one parameter, full schema coverage, and annotations declaring read-only/idempotent, the description is fully adequate. Mentions sibling tool for comparisons.
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 100% coverage with enum and description. Description adds example usages for each protocol and clarifies identifier format, exceeding baseline 3.
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?
Clear verb+resource: 'get the canonical description' of a protocol. Lists specific fields (creator, maturity, repo URL, layer). Distinct from sibling compare_protocols.
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?
Explicit when-to-use: user asks about a specific protocol like 'what is AP2?' or 'who created MPP?'. Explicit when-not-to: use compare_protocols instead for comparisons.
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 EcosystemARead-onlyInspect
Scan 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: costs $0.01 USDC, accepts x402 or MPP payments, returns classified/scored opportunities with recommended 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?
Description is concise (three sentences) and front-loaded with the essential purpose. Every sentence adds value without redundancy.
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 scan tool with no output schema, the description adequately explains what it does and what it returns. It covers cost, payment methods, and ecosystem keywords. Could slightly improve by noting pagination or result count, but still highly complete.
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% with clear descriptions for days and min_score parameters. The description adds no additional semantics beyond the schema, so a baseline score of 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 content, and returns AI-classified scored opportunities. It distinguishes itself from siblings (get_protocol_info for static details, compare_protocols for comparison) with specific verb and resource.
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?
Provides explicit when-to-use instructions (user asks about recent activity, 'what's new', 'scan for opportunities') and when-not-to use (use get_protocol_info or compare_protocols for other needs). Also mentions cost and payment methods, giving clear context.
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!