intelligence-mcp
Server Details
Agent payments ecosystem intelligence. Scans GitHub/HN/npm across AP2, ACP, x402, MPP, UCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- goodmeta/intelligence-mcp
- GitHub Stars
- 0
- Server Listing
- intelligence-mcp
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.8/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: compare_protocols for comparisons, get_protocol_info for single protocol details, and scan_opportunities for discovering new developments. Descriptions explicitly mention when to use other tools, eliminating ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: compare_protocols, get_protocol_info, scan_opportunities. The naming is predictable and clear.
With 3 tools, the server is well-scoped for the intelligence/briefing domain. Each tool covers a distinct operation (comparison, detail lookup, scanning) without being too few or too many.
The tool set covers the core information needs for agent payment protocols: comparisons across all protocols, deep details on individual protocols, and scanning for new opportunities. 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=true and idempotentHint=true. Description adds that it outputs a comparison matrix across listed dimensions, which provides behavioral context beyond annotations. No contradictions.
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 content, second provides usage guidance. Front-loaded, 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?
Given zero parameters, no output schema, and annotations covering safety, the description fully explains what the tool returns (comparison matrix across specified dimensions) and when to use it versus sibling tools.
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; schema coverage is 100% by default. Description does not need to add parameter information, baseline is 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 it returns a side-by-side comparison matrix of five specific protocols across multiple dimensions. Verb 'Get' and resource are specific, and it distinguishes from sibling 'get_protocol_info'.
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 ('when user asks to compare protocols...') and when not to ('use get_protocol_info instead for deep details'), with example queries.
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 declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat those. The description adds context about the kind of information returned (creator, maturity level, repo URL, layer) but does not disclose any additional behavioral traits such as data freshness or caching. Given the strong annotation coverage, this is acceptable.
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 two sentences long, front-loaded with the core purpose, immediately followed by usage guidance. No extraneous 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?
Given the tool's simplicity (single parameter, full schema coverage, strong annotations), the description is complete. It covers purpose, usage, and parameter meaning without needing an output schema.
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%, and the description adds meaning by providing examples and associating each protocol identifier with its layer and creator (e.g., 'ap2' for Google's authorization layer). This goes beyond the simple enum description in the schema.
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 retrieves the canonical description of a protocol, listing specific fields (creator, maturity level, repo URL, layer). It distinguishes itself from the sibling tool compare_protocols by its focus 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 states when to use this tool (when the user asks about a specific protocol) and when to use the alternative (compare_protocols for comparing multiple protocols).
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 show readOnlyHint=true, openWorldHint=true. Description adds behavioral details: returns AI-classified/scored opportunities with actions, costs $0.01 USDC, accepts specific payment methods. 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?
Five sentences, front-loaded with primary action, then usage guidance, alternatives, and cost. 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?
Covers all key aspects: sources, domain, parameters, cost, payment, alternatives. Lacks detailed output format description, but sufficient given no output schema.
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?
100% schema coverage with descriptions. Description enriches with examples: 'e.g., 7 for last week', 'e.g., 12 for high-quality only'. Adds clarity beyond schema.
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 it scans GitHub, Hacker News, and npm for agent payments ecosystem topics. Distinguishes from siblings by naming get_protocol_info and 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?
Explicitly says when to use: when user asks about recent activity, new developments. Provides alternatives: use get_protocol_info for static details, compare_protocols for comparison.
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!
Your Connectors
Sign in to create a connector for this server.