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
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.2/5 across 10 of 10 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: ask_services uses LLM for recommendations, search uses deterministic ranking, search_a2a_agents and search_mcp_servers target specific resource types, get and get_mcp_server retrieve details, and register, list_categories, stats are unique. No two tools are ambiguous in their intended use.
Most tools follow a verb_noun pattern (e.g., ask_services, list_categories), but there are inconsistencies: 'get' and 'register' are bare verbs, 'get_mcp_server' mixes verb_noun with underscore, and 'stats' is a noun-only name. The pattern is not uniform, though still readable.
With 10 tools covering discovery, retrieval, registration, and statistics, the count is well-scoped for a directory server. Each tool serves a clear purpose without redundancy, and the number feels appropriate for the domain.
The core operations of search, detail retrieval, and registration are covered, but update and delete/removal of services are missing. Additionally, a bare 'list all' without filters is not directly supported. These gaps mean agents may encounter dead ends when managing services.
Available Tools
10 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.| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently discloses the retrieval, LLM ranking, and fallback processes, though it does not mention idempotency or lack of side effects.
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 concise, well-structured with a summary and bullet-like parameter list, and contains no unnecessary 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 complexity (9 parameters, no annotations), the description covers all parameters and overall behavior, and an output schema exists for return values, making it 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 0%, but the description includes a full 'Args' list with clear explanations for each of the 9 parameters, adding significant value.
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 it is a 'high-level discovery tool' that retrieves and ranks services for an agent intent using an LLM, distinguishing it from sibling tools like search or search_mcp_servers.
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 explains it is for discovering services for an agent intent and mentions fallback behavior, but does not explicitly state when to prefer alternatives or when not to use this tool.
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.| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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. It discloses what the tool returns (service card with various samples and call hints) but does not mention side effects, auth needs, or read-only nature. This adds value but lacks full transparency.
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 concise with three focused sentences: purpose, contents, usage context, followed by an args list. Every sentence earns its place, and the most important info is front-loaded.
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 output schema exists (not shown) and only one parameter, the description covers key points: what it returns, when to use. It does not explain output schema details, but that is acceptable. Could be more precise about the call template.
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 schema has zero description coverage for the 'slug' parameter, but the tool description adds 'Service slug as returned by `search` items,' which provides crucial context about where the slug originates. This compensates for the schema gap.
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 states a specific verb ('Get') and resource ('full details + ready-to-paste call template for a service'). It distinguishes from siblings like 'search' and 'ask_services' by specifying it returns a service card with payment, call, quality, resource samples, and call hints.
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 'Use this after `search` or `ask_services` before paying/calling an external service,' providing clear context for when to use the tool. It does not mention when not to use it, but the guidance is sufficient.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It indicates a read operation but lacks details on authentication, rate limits, or any special constraints. The output schema exists, so return format is covered elsewhere.
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?
One sentence of 7 words, front-loaded with the action. Every word is necessary and no redundant information. Highly concise.
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 simple tool with one required parameter and an output schema, the description is complete. It explains what the tool does and how to use it without missing critical information.
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% (no descriptions in schema), but the single parameter 'slug' is self-explanatory. The description adds minimal context by stating 'by slug', which clarifies its role as identifier. This is adequate for one simple param.
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 identifies the verb 'Get', the resource 'full card for one MCP server', and the method 'by slug'. This distinguishes it from sibling tools like 'search_mcp_servers' which imply listing or searching.
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 implies usage when you have a specific slug, and suggests not using it for searching (use 'search_mcp_servers' instead). However, it does not explicitly state when not to use or mention alternatives.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the tool lists categories, but does not mention if it is read-only, if there are pagination limits, or any other behavioral traits. The output schema exists but the description adds no context beyond the basic action.
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, informative sentence with no extraneous words. It is appropriately front-loaded and efficient.
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 (no parameters, output schema present), the description is nearly complete. However, it could briefly mention that it returns a list or the nature of the output, though the output schema presumably covers that.
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?
With zero parameters, the schema coverage is effectively 100%. According to the guidelines, this baseline is 4. The description adds no parameter information, but none is needed.
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 verb 'list' and the resource 'service categories', making it unambiguous. It distinguishes from sibling tools like 'search' or 'ask_services' by focusing on listing all available categories without additional filtering.
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 provides no guidance on when to use this tool versus alternatives. For example, it does not mention that this tool returns all categories without filtering, which would help an agent choose between 'list_categories' and 'search' or 'ask_services'.
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.| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-review, instant listing condition, dedup, rate limit with error response, and that listing is free.
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 sections (dedup, rate limit, args), but somewhat lengthy. Still, every sentence adds value and the core purpose is front-loaded.
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 complexity (9 params, 1 required) and presence of output schema, the description covers input, behavior, and context thoroughly. No missing elements.
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 description thoroughly explains all 9 parameters with purpose, defaults, constraints, and hints (e.g., 'list_categories' for category).
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's purpose: 'Self-register an x402 / MCP service in the agent-tools directory.' It distinguishes from siblings like 'search' and 'get' by focusing on submission vs. retrieval.
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 ('Service owners and agents may submit new services'), provides alternatives (dedup behavior, rate limiting, hint to use 'list_categories'), and explains auto-review process.
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.| 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
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses ranking logic, required conditions for rejection, and result fields but omits information on performance limits or idempotency, which is acceptable for a search tool.
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 well-structured with clear sections for usage modes and arguments, but slightly verbose. Each sentence adds value, though could be more concise without losing meaning.
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 complexity and presence of an output schema, the description covers essential context like ranking criteria and result fields. It lacks mention of pagination or rate limits, but overall is sufficiently complete for an AI agent.
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%, so the description fully compensates by explaining each parameter's purpose, defaults, constraints, and behavior (e.g., synonym expansion for intent, hard cap on top_k, filter options). This goes well beyond the schema's type/default information.
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 'Find x402 / MCP services matching an intent or filter set' with specific verb and resource. It distinguishes two usage modes (natural-language and pure browse) and explains the domain, effectively differentiating this tool from siblings like search_mcp_servers and search_a2a_agents.
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 provides explicit when-to-use guidance for both modes A and B, along with constraints (at least one filter required) and ranking preferences. However, it does not explicitly compare to sibling tools or state when not to use this tool.
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.| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| intent | No | ||
| x402_only | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, whether results are paginated, or any side effects. It only describes parameter behavior.
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 concise: one sentence for purpose followed by a clear bullet list of parameters. No unnecessary 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 covers the input parameters fully, and an output schema exists (so return values need not be explained). However, it lacks context on prerequisites or limitations (e.g., network, authentication).
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 description adds clear, meaningful explanations for all three parameters ('intent', 'top_k', 'x402_only') beyond the schema, which has 0% schema description coverage.
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 action ('Find A2A agents') and the context ('you can delegate a task to'), distinguishing it from sibling tools like 'search_mcp_servers' and 'search_resources'.
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 implies when to use the tool (to find agents for delegation) but does not explicitly contrast with alternatives or state when not to use it.
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.| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| top_k | No | ||
| intent | No | ||
| require_healthy | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavior: search scope, union sources, result format with call_hint.mcp.url, and parameter effects. No contradictions or omissions.
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 concise and well-structured: a one-line summary, followed by details and parameter list. Every sentence is informative and earns its place.
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 having an output schema, the description is complete: covers search scope, result format, filtering, and parameter defaults. No missing context for agent invocation.
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 provides complete parameter semantics for all 4 parameters: intent, top_k, chain, require_healthy. This adds significant value beyond 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 finds MCP servers in the directory, distinguishes from siblings like search_a2a_agents, and provides specific scope (standalone MCP + x402 services).
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 explains parameters and search scope but does not explicitly state when to use this tool versus alternatives like search_resources or get_mcp_server. Usage is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_resourcesAInspect
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).| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | ||
| intent | No | ||
| protocol | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions search functionality and parameters but does not disclose whether it is read-only, any authorization needs, rate limits, or the structure of results. The output schema exists but is not referenced.
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 concise, with a clear one-line purpose and a structured list of arguments. Every sentence contributes value without redundancy, making it easy to scan.
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 complexity of a unified search tool, the description covers the search action and parameters but omits details about the output format, pagination, or how to interpret results. Since an output schema exists, the need for return value explanation is reduced, but the description still lacks behavioral context for an agent to use it 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 description coverage is 0%, so the description must add meaning. It explains 'intent' as a natural-language query, 'protocol' as an optional filter with values, and 'top_k' as max resources. This provides context beyond the schema, but it does not clarify defaults or required formats. The addition is moderate but insufficient to fully compensate for the lack of schema descriptions.
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 'Unified search across x402 services, MCP servers and A2A agents.' This specifies the verb (search), the resources (three distinct types), and differentiates it from more specific siblings like search_mcp_servers and search_a2a_agents.
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 explains the parameters (intent, protocol filter, top_k), giving context for use. It implies that for a cross-type search, use this tool; for a specific type, use siblings. However, it does not explicitly state when not to use or provide direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statsAInspect
High-level stats about the directory: total services, healthy count, sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It implies a read-only operation (stats), but does not mention any other behaviors like data freshness, caching, or potential side effects. Adequate for a simple stat tool but lacks depth.
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 extremely concise: one sentence that directly states the purpose and the data included. No unnecessary words, and the core information is front-loaded.
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 has no parameters and an output schema exists, the description sufficiently communicates what the tool returns. It could mention that stats are about the entire directory, but it is adequate for a simple aggregation tool.
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 zero parameters, so the schema fully covers them. According to the 0-param baseline rule (score 4), the description adds no further value about parameters, but that is acceptable since there are none.
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 provides high-level stats about the directory and lists what it returns (total services, healthy count, sources). It distinguishes from sibling tools like search or get which are not for overall stats. However, it lacks an explicit action verb (e.g., 'get' or 'fetch').
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. The purpose is implied by the name and sibling tools, but the description does not explicitly state when to use or when not to use it.
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!