Cinderwrightofficial
A
licenseB
qualityA
maintenancex402 Discovery Hub. Search engine for the agent economy with 1450+ services indexed. Search by keyword, browse by category, free service submission.
Last updated
12
35
3
MIT
agent-tools (x402 + MCP + A2A directory)
Server Details
Discover x402 services, MCP servers and A2A agents by intent — agent-tools.cloud directory.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- AgentTools-Cloud/AgentToolsCollection
- GitHub Stars
- 1
- Server Listing
- agent-tools-cloud
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A3.8/5.0
Tool DescriptionsA
Average 4.1/5 across 9 of 11 tools scored. Lowest: 3.2/5.
Server CoherenceA
Disambiguation4/5
Tools are mostly distinct with clear purposes. However, 'search', 'search_mcp_servers', 'search_a2a_agents', 'search_resources', and 'ask_services' have overlapping discovery functions, though descriptions differentiate them (e.g., LLM ranking vs deterministic). This could slightly confuse an agent.
Naming Consistency3/5
Naming conventions are mixed: some follow 'verb_noun' (e.g., ask_services, list_categories), some are single verbs (get, register, search, stats), and some use underscores (search_a2a_agents, search_mcp_servers). The pattern is not fully consistent but remains readable.
Tool Count5/5
11 tools is well within the recommended 3-15 range for a directory server covering x402, MCP, and A2A services. Each tool serves a distinct purpose without bloat.
Completeness4/5
The toolset covers core directory operations: discovery (multiple search variants), details, registration, safety scanning, and stats. Missing update/delete for services is a minor gap but not critical for basic usage.
Available Tools
11 toolsask_servicesAInspect
Ask for the best x402/MCP services for an agent intent.
This is the high-level discovery tool: it retrieves candidates from the
directory, asks the configured backend LLM to rank only those candidates,
and returns service cards for the selected recommendations. If the LLM is
unavailable, it falls back to the directory ranker.
Args:
intent: Natural-language job the agent wants to accomplish.
top_k: Max recommendations to return (1-10).
max_price_usd: Optional per-call budget cap.
category: Optional directory category filter.
chain: Optional payment network filter, e.g. "base" or "solana".
require_healthy: When true, only consider services marked health=ok.
min_confidence: Optional x402scan quality floor (0.0-1.0).
has_mcp: When true, only consider services with MCP endpoints.
use_llm: Set false for deterministic retrieval-only fallback.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| top_k | No | ||
| intent | Yes | ||
| has_mcp | No | ||
| use_llm | No | ||
| category | No | ||
| max_price_usd | No | ||
| min_confidence | No | ||
| require_healthy | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains the workflow: candidate retrieval, LLM ranking, fallback to directory ranker if LLM unavailable. However, it does not mention auth, rate limits, or side effects. For a read-only discovery tool, the disclosure is adequate.
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?
The description is well-structured with a clear one-liner, process explanation, and parameter list. It is sufficiently detailed without being overly verbose. Minor redundancy in the parameter list could be trimmed, but overall effective.
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?
Given the tool complexity (9 parameters, output schema present), the description covers purpose, process, fallback behavior, and all parameters. It could mention output format briefly, but output schema exists. Lacks explicit mention of read-only nature, but not critical. Quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes a comprehensive bullet list explaining all 9 parameters (intent, top_k, max_price_usd, category, chain, require_healthy, min_confidence, has_mcp, use_llm). This fully compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a high-level discovery tool that retrieves and ranks candidates, returning service cards. It uses specific verbs and resources ('Ask for the best x402/MCP services'), and the detailed explanation differentiates it from sibling tools like search or get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions itself as the primary discovery tool and explains the ranking process, but it does not explicitly state when not to use it or compare with alternatives like search_mcp_servers or get. The guidance is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getAInspect
Get full details + ready-to-paste call template for a service.
Returns the service card with payment, call, quality, resource samples,
and ready-to-use MCP/x402 call hints. Use this after `search` or
`ask_services` before paying/calling an external service.
Args:
slug: Service slug as returned by `search` items.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Describes what it returns (service card with multiple components), but does not mention whether it is read-only, any side effects, or authentication requirements. Minimally adequate.
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?
Highly concise and well-structured: purpose stated first, then details, then parameter description. No redundant words.
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?
Given the tool has an output schema, the description appropriately focuses on input and usage context. Lists key components of the return value but does not need to elaborate due to output schema. Covers the necessary information.
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?
Schema coverage is 0%, so description must compensate. It explains the single parameter 'slug' as the service slug returned by 'search' items, adding useful context beyond the schema's basic string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves full details and a ready-to-paste call template for a service. Distinguishes from sibling tools by specifying it should be used after 'search' or 'ask_services'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this after `search` or `ask_services` before paying/calling an external service', providing clear context for when to use it. Does not explicitly state when not to use it, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mcp_serverAInspect
Get the full card for one MCP server by slug.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It indicates a read operation via 'Get' but does not elaborate on side effects, authorization needs, rate limits, or what 'full card' entails. The description is minimally transparent.
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?
The description is concise with no wasted words. It is front-loaded with the action and resource. However, it could be slightly expanded with additional context without losing conciseness.
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?
Given an output schema exists, return values are already documented. However, the description lacks guidance on prerequisites, such as needing a valid slug, or any edge cases. For a simple fetcher, it is partially complete but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds the phrase 'by slug,' which clarifies the parameter's purpose. However, it does not provide format, constraints, or examples beyond the schema's basic type definition. The added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full card for one MCP server by slug,' specifying the action (get), resource (full card for one MCP server), and the parameter (slug). It effectively distinguishes itself from sibling tools like search_mcp_servers, which would return multiple results.
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 when a specific slug is known but offers no explicit guidance on when to use this tool versus alternatives like search_mcp_servers or get. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
List all available service categories in the directory.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not convey any behavioral traits such as authentication needs, rate limits, or response structure. The description carries the full burden but is minimal.
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?
Single sentence with no unnecessary words. The description is efficient and front-loaded.
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 parameterless tool with an output schema, the description is adequate but lacks usage context and behavioral details. It completed the basics but could improve completeness.
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?
No parameters exist, and schema coverage is 100%. With zero parameters, the description does not need to add parameter details; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'all available service categories in the directory'. It is specific and distinguishes this tool from sibling tools like get_mcp_server or search functions.
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?
No explicit guidance on when to use this tool versus alternatives. While the simple nature of listing categories implies use for browsing, it lacks 'when not to use' or references to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
registerAInspect
Self-register an x402 / MCP service in the agent-tools directory.
Service owners and agents may submit new services here. Submissions
are auto-reviewed instantly by x402 verification (no human gate): if
the URL proves x402 payment support it is listed immediately and shows
up in `search`; otherwise it is rejected or retried automatically.
Listing is FREE.
Dedup: if a service with the same canonical origin (scheme://host)
already exists in the directory we return its slug instead of
creating a duplicate submission. Same goes for a still-pending
submission with the same origin.
Rate limit: at most 5 pending submissions per client IP per 24h.
Hits beyond that get `{error: rate_limited}` — try again later or
email contact@agent-tools.cloud for bulk imports.
Args:
url: Public HTTPS URL of the service (the x402-payable endpoint
or its homepage). Required.
name: Human-friendly name. Defaults to the URL hostname.
description: One-paragraph description (max ~2000 chars).
mcp_url: If the service speaks MCP, its streamable-http endpoint.
category: Free-form (e.g. "defi", "search", "social"). Use
`list_categories` to align with existing taxonomy.
chains: Networks the service accepts payment on
(e.g. ["base", "solana"]).
price_min_usdc: Lower bound of per-call price in USDC.
price_max_usdc: Upper bound of per-call price in USDC.
contact: Optional email / handle the directory team can reach
you on for clarifications.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | No | ||
| chains | No | ||
| contact | No | ||
| mcp_url | No | ||
| category | No | ||
| description | No | ||
| price_max_usdc | No | ||
| price_min_usdc | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations provided, description fully discloses behavior: auto-review via x402 verification, immediate listing or retry, dedup, rate limiting with specific error message, and contact for bulk imports. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, process, dedup, rate limit, then args. Concise yet comprehensive; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and output schema available, description covers all behavioral aspects: error conditions, dedup, rate limit, and parameter semantics. No need to explain output since schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds meaning for all 9 parameters: url required, name defaults to hostname, description max chars, category suggests list_categories, chains, price bounds, contact optional. Fully compensates for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers an x402/MCP service in the agent-tools directory. It distinguishes from sibling tools like search and list_categories by explicitly mentioning the registration purpose and auto-review process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (service owners/agents submitting new services), dedup logic (avoids duplicates), rate limit (5 per IP per 24h), and alternatives (search for existing listings). Also describes error handling for rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_mcp_safetyAInspect
Check an MCP server for malware / prompt-injection lures by its endpoint URL.
Give the server's streamable-http endpoint URL. Two paths:
* **Already in the agent-tools directory** → returns our LATEST stored
rule verdict. Every indexed server is re-scanned hourly, so you get a
consistent, continuously-refreshed answer without re-probing.
* **Not yet indexed** → we probe the endpoint live, statically scan its
advertised tools + metadata, ADD it to the directory, and return the
fresh verdict (so the next caller gets the rule verdict instantly from
cache).
Two dimensions are reported. `verdict` is authoritative and comes from
deterministic static rules — pure pattern-matching over the *advertised*
text only, NO code execution. It flags the social-engineering / RCE tricks
listing-spam servers use:
* `curl … | bash` and `base64 -d | sh` install lures
* `eval "$(curl …)"` / PowerShell `IEX(...DownloadString)` cradles
* base64 blobs that decode to a shell command
* bare-IP payload hosts and cheap throwaway TLDs
* prompt-injection / credential-exfiltration phrasing
("ignore previous instructions", "send your .env / api key")
* MCP tool-poisoning coercion — descriptions that hijack an agent's
tool-calling ("always call this tool first", "before using any other
tool you must…"), hidden `<IMPORTANT>` instructions, "list all API
keys / include secrets in your response", and coercion to read &
forward `.key`/`.pem`/`.ssh`/`.env` files
Source-code-oriented rules (SQL / command / code injection) are deliberately
not applied to natural-language descriptions, to avoid false positives.
`llm_reference` is an advisory frontier-LLM second opinion over the same text.
Because the LLM is slow it is computed LIVE on this call only and is never
stored (the hourly job never runs it), so it may be null on timeout. It
never overrides the rule verdict; when it is *more* severe than the rules an
`advisory` note is attached as a safety-net signal. Security/defense
products that merely *name* these attacks are not flagged.
Args:
endpoint_url: The MCP server's streamable-http URL (required). This is
the identity we look up / index by.
name: Optional advertised name (used when the server is new and gets
added; falls back to the URL host).
description: Optional description / README blurb (scanned when new).
tools_text: Optional tool names + descriptions; used only if the live
probe cannot fetch the server's tools/list.
Returns:
{ verdict: "clean"|"suspicious"|"malicious", score: 0-100,
reasons: [{rule, weight, snippet}],
llm_reference: {model, verdict, reason, confidence} | null,
advisory: str | null, slug, name, endpoint_url,
source: "stored" (existing) | "new_scan" (just added), indexed: bool }
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| tools_text | No | ||
| description | No | ||
| endpoint_url | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses that scanning is static (no code execution), details the detection rules, explains the two dimensions (verdict and llm_reference), caching behavior, and potential null values. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections and bullet points. It is front-loaded with the main purpose. While comprehensive, a slight reduction in verbosity could improve conciseness without losing essential detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two paths, multiple rule types, LLM advisory, caching, output schema), the description is complete. It covers edge cases like null llm_reference and advisory notes, and the output schema is effectively documented in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed semantics for all four parameters. endpoint_url is explained as the identity, and name, tools_text, and description have their roles clearly described, compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks an MCP server for malware/prompt-injection lures by its endpoint URL. It uses specific verbs (Check, scan) and resource (MCP server) and is distinct from sibling tools which are for search, listing, and retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two paths based on whether the server is already indexed, providing clear usage context. It does not explicitly mention when not to use this tool versus alternatives, but siblings do not overlap in functionality, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Find x402 / MCP services matching an intent or filter set.
Two usage modes (agents pick whichever fits):
A. Natural-language: `search(intent="fetch tweets for @user")`
B. Pure browse: `search(has_mcp=True, category="defi", top_k=10)`
At least one of `intent`, `category`, `chain`, `has_mcp`,
`min_confidence` must be supplied — otherwise the call is
rejected (we won't dump 2300+ rows).
Results are ranked by:
(health=ok AND tx_30d>0) → health=ok → has-quality-signal →
confidence → tx_30d → recency.
So the highest-quality real-traffic services appear first.
Each item includes (when available):
- confidence : 0.0–1.0 x402scan quality score.
- tx_30d : 30-day x402 payment count (proxy for real usage).
- match_snippet : FTS snippet showing where `intent` hit ([[token]]).
- match_reason : list[str] of human-readable ranking signals.
- mcp_url : populated when the service exposes an MCP endpoint
(you can call it directly via streamable-http).
Agents should prefer items with non-null confidence and tx_30d > 0
unless the user explicitly wants experimental endpoints.
Args:
intent: What the agent wants to do (English or Chinese). Optional
when at least one structured filter is set. Synonym expansion
covers twitter↔X↔推特, whale↔巨鲸, price↔价格 etc.
top_k: Max services to return (default 5, hard cap 25).
max_price_usd: Upper bound on per-call price in USD.
category: Filter (see `list_categories`).
chain: "base", "polygon", "solana", "arbitrum", ...
min_confidence: Minimum confidence (0.0–1.0). 0.8+ keeps only
services x402scan rates as high-quality.
has_mcp: When true, return only services with a callable MCP
endpoint. Use this when the agent wants to chain another MCP
server rather than perform raw HTTP+x402.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| top_k | No | ||
| intent | No | ||
| has_mcp | No | ||
| category | No | ||
| max_price_usd | No | ||
| min_confidence | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the ranking logic (health, tx_30d, etc.), the fact that the call is rejected without filters, and recommends preferring items with non-null confidence and tx_30d > 0. This provides clear behavioral expectations beyond the schema.
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?
The description is well-structured with sections, bullet points, and clear formatting. It is comprehensive but every sentence adds value. No filler or repetition. The use of examples and formatting makes it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, output schema exists), the description thoroughly explains ranking, result fields, and parameter semantics. The output schema exists but description also clarifies the content of results like confidence, tx_30d, match_snippet, etc., making it fully complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides detailed explanations for each of the 7 parameters in a dedicated Args section, including examples for intent, default values, and constraints like hard cap for top_k. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds x402/MCP services matching an intent or filter set. It specifies two usage modes (natural-language and pure browse) and distinguishes from sibling tools by mentioning specific filtering capabilities and contrast with other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by detailing two usage modes and mandatory filter requirements. It explains that at least one filter must be supplied to avoid rejection. However, it does not explicitly compare with siblings like 'search_mcp_servers' to indicate when to use one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_a2a_agentsAInspect
Find A2A agents you can delegate a task to.
Args:
intent: Natural-language description of the task to delegate.
top_k: Max agents to return (1-20).
x402_only: When true, only return agents that advertise x402 payment.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| intent | No | ||
| x402_only | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains the parameters' effects but does not discuss error handling, rate limits, or authentication requirements. The description is factual but minimal.
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?
The description is very concise: one sentence stating purpose followed by three bullet points for parameters. No redundant information, and the purpose is front-loaded.
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?
With an output schema present, description need not detail return values. All three parameters are well explained. However, the description could benefit from adding usage context, such as when to prefer this tool over search_mcp_servers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the 'Args' section in the description thoroughly explains each parameter: 'intent' as natural-language task, 'top_k' with range 1-20, and 'x402_only' with payment condition. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find A2A agents you can delegate a task to,' using a specific verb and resource with a distinct purpose. This differentiates it from sibling tools like search_mcp_servers or search_resources.
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 use when needing to delegate tasks to agents, but lacks explicit guidance on when not to use it or comparisons with alternative tools among the siblings. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_mcp_serversAInspect
Find MCP servers in the directory.
Searches the standalone MCP directory (PulseMCP / official MCP registry
import) unioned with x402 services that also expose an MCP endpoint.
Returns normalised entries with a ready-to-use streamable-http
`call_hint.mcp.url`.
Args:
intent: Natural-language description of the tool/capability needed.
top_k: Max servers to return (1-20).
chain: Optional payment-network filter for paid MCP servers.
require_healthy: When true, only return servers marked health=ok.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| top_k | No | ||
| intent | No | ||
| require_healthy | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the core behavior (search directory, union sources, return normalized entries with URLs) but omits potential side effects, authentication needs, or rate limits. The description is adequate but could be more transparent about dependencies like network access or API keys.
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?
The description is concise and well-structured: a one-sentence summary followed by a paragraph detailing sources and output, and a bulleted list of parameters. Every sentence adds value, and no redundant information is present.
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?
Given the tool's moderate complexity (4 params, no required, has output schema), the description covers purpose, parameters, and output hint. It is nearly complete, but could mention if authentication or network access is required, especially since annotations are absent. The presence of an output schema reduces the need to detail return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so with a detailed 'Args' section that explains each parameter: 'intent' as natural-language description, 'top_k' with range (1-20), 'chain' as payment-network filter, and 'require_healthy' as filter for health=ok. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find MCP servers in the directory' and elaborates on the sources (standalone MCP directory unioned with x402 services). It specifies the output: normalised entries with a streamable-http URL. This distinguishes it from sibling tools like 'search' or 'get_mcp_server' by mentioning the unioned sources and the specific URL format.
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 via the 'intent' parameter for natural-language queries but does not explicitly compare to alternatives like 'search' or 'get_mcp_server'. No when-to-use or when-not-to-use guidance is provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_resourcesBInspect
Unified search across x402 services, MCP servers and A2A agents.
Args:
intent: Natural-language query.
protocol: Optional filter: "x402", "mcp" or "a2a".
top_k: Max resources to return (1-50).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| intent | No | ||
| protocol | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as required permissions, rate limits, side effects, or return format beyond the basic function. The output schema exists but is not explained.
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?
The description is very concise, with three short lines plus an argument list. It is front-loaded with the main purpose and every sentence is informative without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of multiple specialized sibling tools and no guidance on when to use this unified version, the description feels incomplete. It lacks prerequisites, behavior details, and clarity on scope, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining intent as a natural-language query, protocol as an optional filter with enumerated values, and top_k with a range. However, with 0% schema coverage and no enums in schema, it could be more precise (e.g., expected format for intent).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a unified search across x402 services, MCP servers, and A2A agents, using a specific verb and resource. It distinguishes from specialized siblings like search_mcp_servers and search_a2a_agents by being the unified version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its specialized alternatives. There is no mention of when to prefer unified search over specific searches like search_mcp_servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statsBInspect
High-level stats about the directory: total services, healthy count, sources.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should cover behavioral traits. It only states what the tool returns without mentioning side effects, permissions, or limits. The tool likely read-only but not stated.
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?
Single sentence, no redundancy, front-loaded with key information. Every word contributes to the purpose.
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?
Given zero parameters and an output schema, the description covers the basics. However, it could elaborate on what 'sources' means or provide examples of returned data to aid agent understanding.
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?
No parameters, so the description doesn't need to explain them. Schema coverage is 100% (nonexistent), meeting the baseline. The description is clear enough for a parameterless tool.
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 specifies it provides high-level stats (total services, healthy count, sources), clearly differentiating from sibling tools like search or get that return individual items. However, it could be more concrete about the exact metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search or list_categories. The description implies it's for aggregate overviews, but lacks explicit context about appropriate use cases or prerequisites.
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!
Related MCP Servers
- Alicense-qualityCmaintenanceEnables MCP-compatible agents to discover and call x402 paid services from a directory of over 2,000 APIs.Last updatedApache 2.0
- Alicense-qualityBmaintenanceUnified crypto tool directory MCP server enabling AI agents to discover, evaluate, and install crypto tools across multiple sources with trust scoring and x402 payment support.Last updated1MIT
- AlicenseAqualityFmaintenanceMCP server for the402.ai — an open marketplace where AI agents discover and purchase services from third-party providers via x402 micropayments (USDC on Base). Browse the catalog, purchase services, manage conversation threads, and list services as a provider.Last updated30432MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.