A machine-readable directory where AI products register themselves so AI agents can discover them. Ask it in natural language (NLWeb), call it as an MCP server over HTTP, or search the JSON API. Autonomous registration via GitHub issues, free listings, per-listing pages with schema.org JSON-LD.
Scored across 6 tools
Most tools have distinct purposes, but search_products and search_mcp_servers overlap since products can include MCP servers. The other tools are clearly differentiated.
Naming is mixed: get_product, how_to_register, score_url, and search_* tools do not follow a single consistent pattern. The search_ prefix is repeated, but the overall convention is inconsistent.
Six tools is a reasonable, focused set for an AI product index covering lookup, registration guidance, URL scoring, and three search domains.
The tool surface covers core retrieval, search, and registration guidance. Direct creation/update is not exposed, but the how_to_register tool appropriately delegates that external process, so no major dead ends are apparent.
Fetch one listing from the AI Product Index by slug, with every published field.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug, as returned by search_products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral information. It states that the tool returns 'every published field', which discloses the completeness of the response. However, it does not mention error behavior (e.g., what happens if the slug is not found), authentication requirements, or any potential side effects. For a read-only fetch tool, this is a minimal but not exhaustive disclosure.
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 sentence that is concise, front-loaded with the action, and includes a meaningful qualifier ('with every published field'). It contains no fluff or redundant wording, making it highly 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?
For a simple one-parameter fetch operation, the description is nearly complete. It covers what is fetched and the method, and the schema covers the parameter source. The absence of an output schema means the 'every published field' phrase serves as a return-value expectation. However, it could be slightly more complete by explicitly stating that the slug comes from search_products within the description itself, rather than relying on the 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?
The input schema has 100% coverage: the required 'slug' parameter is described as 'The listing slug, as returned by search_products.' The main description does not add any further semantic detail about the parameter, but the schema description is already informative and sufficient given the simplicity of the parameter.
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 'Fetch one listing from the AI Product Index by slug, with every published field' uses a specific verb ('fetch'), names the resource ('listing', 'AI Product Index'), and clarifies the selection method ('by slug'). It clearly distinguishes from sibling tools like search_products by focusing on retrieving a single item rather than 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 implicitly conveys the use case: obtain a single listing when you already have its slug. While it doesn't explicitly state 'use this instead of search_products when you have a slug' or list exclusions, the context is clear enough. The schema description for 'slug' explicitly says 'as returned by search_products', which reinforces the relationship to the sibling search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the exact steps and schema for registering a product in the index — autonomous, free, no human approval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is autonomous, free, requires no human approval, and returns informational content (steps and schema). This effectively communicates a safe, read-only, self-service behavior without leaving major hidden behaviors uncovered.
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, well-structured sentence that front-loads the core purpose and adds key behavioral details (autonomous, free, no human approval) without any 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?
For a zero-parameter, informational tool with no output schema, the description is complete: it tells the agent exactly what will be returned and the conditions of use. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the return value rather than parameter details, and no parameter clarification 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 uses a specific verb ('Returns') and identifies the exact resource: the steps and schema for registering a product in the index. This clearly distinguishes it from sibling tools like get_product, search_products, and score_url, which serve different purposes.
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 makes it clear this is the tool to use when you need to know how to register a product, and it adds helpful context: the process is autonomous, free, and requires no human approval. It does not explicitly name alternatives or exclusions, but among the siblings none are direct alternatives for registration instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grade any public URL A–F across 20 weighted agent-readability checks, including llms.txt, schema.org JSON-LD, crawler policy, agent/MCP/API cards, Agent Skills, markdown negotiation, canonical and HTTPS. Free; returns which checks failed. The paid endpoint at /api/audit adds the reason and a paste-ready fix for each.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute http(s) URL to grade. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that the tool is free, returns a grade plus the list of failed checks, and covers a specific set of checks. It does not mention network-fetch behavior or rate limits, but the given details materially describe what happens.
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 deliver a high density of useful information: grade range, check count, example check categories, cost, failure output, and a paid upgrade path. Every clause earns its place 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?
The tool has one simple parameter and no output schema, so the description must explain the return value — and it does: grade A–F plus which checks failed. It also covers pricing and the more detailed paid endpoint. A formal response schema is not stated, but the agent has enough to call the tool correctly.
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% because the `url` parameter already explains it as an 'Absolute http(s) URL to grade.' The description adds the 'public' qualifier, but this is a minor addition beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Grade'), a resource ('any public URL'), and a concrete grading scale ('A–F across 20 weighted agent-readability checks'). It is immediately distinct from sibling tools like get_product or search_mcp_servers, so no ambiguity remains.
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 clearly says the tool works for 'any public URL' and draws a practical line between the free call (returns failed checks) and the paid endpoint (adds reasons and fixes). It does not explicitly name sibling alternatives, but the paid endpoint acts as the relevant alternative and the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 16,526 remotely-callable MCP servers from the official MCP registry — every one has a URL, so it can be added without installing anything. Filter by transport, host, or whether it needs credentials. Servers distributed only as installable packages are deliberately excluded: this answers "what can I call now", not "what exists".
| Name | Required | Description | Default |
|---|---|---|---|
| auth | No | Restrict to servers that need no credentials, or that do. | |
| host | No | Restrict to servers on a hostname (substring match). | |
| limit | No | ||
| query | No | What the server should do, e.g. "github issues" or "browser automation". | |
| transport | No | Restrict to a transport, e.g. streamable-http or sse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description clarifies it lists remotely-callable servers without requiring installation, implying a read-only search operation. It does not mention any side effects or permissions, but the nature of a search tool is clear.
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, consisting of two sentences that efficiently convey the tool's purpose, scope, and key differentiator without unnecessary detail.
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 provides sufficient context for an agent to call the tool correctly, including the registry source and filtering options. While no output schema is given, for a search tool this is acceptable; the absence of explicit return format is a minor gap but not critical.
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?
All five parameters have descriptions in the schema, including examples for query and explanations for filters like transport, host, and auth. The description text reinforces these filters, ensuring the agent understands each parameter's purpose.
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 searches MCP servers from the official registry, specifies its scope (remotely-callable, excludes installable packages), and differentiates itself from sibling tools like search_products or search_x402_endpoints by focusing on 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 implies usage by explaining what it answers ('what can I call now') and what it excludes, but does not explicitly state when to prefer this over alternatives. Still, the purpose is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search https://index.percall.dev — a directory of AI products, APIs, agents and MCP servers that register themselves. Returns matching listings with their URLs and machine-readable endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Restrict to listings carrying this tag. | |
| limit | No | Max results (default 10). | |
| query | No | Words matched against name, tags and description. Omit to list everything. | |
| category | No | Restrict to one category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds context about the self-registered index and the return content (URLs and endpoints), which is useful. However, it does not state that the operation is read-only, any rate limits, or the default limit and query-omission behavior that are only present in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and each sentence provides meaningful information without redundancy. It is appropriately sized and well-structured.
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 search tool with no required parameters and no output schema, the description gives a reasonable overview of the source, scope, and return type. However, it fails to mention how it relates to sibling search tools or edge cases like omitting the query, leaving some gaps in complete guidance.
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 already provides 100% coverage with clear descriptions for all four parameters. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a directory of AI products, APIs, agents, and MCP servers, with a specific verb and resource. It lacks explicit differentiation from sibling search tools like search_mcp_servers, which also search the same index, so it is a clear but not fully distinguishing purpose.
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 context for using the tool as a general directory search, but it does not mention when to choose it over sibling tools such as search_mcp_servers or search_x402_endpoints, and it offers no exclusions. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 14,689 x402-payable HTTP endpoints — the machine-payable web, normalized from the Coinbase CDP Bazaar. Use this to find an API an agent can pay for per call (USDC on Base and other chains) and to see what it costs before calling it. Filter by chain, HTTP method, host or maximum price; results are ranked by relevance then cheapest first.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Restrict to endpoints on a hostname (substring match). | |
| chain | No | Restrict to one chain, e.g. base, solana, polygon. | |
| limit | No | ||
| query | No | What the endpoint should do, e.g. "weather forecast" or "token price". | |
| method | No | Restrict to an HTTP method, e.g. GET or POST. | |
| max_price | No | Maximum price per call in USD. Endpoints priced in an unrecognised asset are excluded when this is set, because their price is unknown rather than zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The term 'search' implies a read-only operation, and the description does not mention any side effects, authentication, or rate limits. While not explicitly stating non-mutation, the nature of the tool makes it clear, so a slight deduction for lack of explicit disclosure.
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 primary purpose, and efficiently conveys all necessary information without redundancy. It is well-structured and easy to parse.
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 search tool with no output schema, the description provides sufficient context for an agent to decide when to use it and what parameters to supply. It covers the core functionality and the key constraints, making it complete for the given complexity.
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 high (83%), with most parameters already having descriptive text. The description text adds minimal extra value beyond the schema, such as clarifying 'max_price' behavior regarding unrecognised assets, but this is also present in the schema. Baseline is 3 due to high 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 ('Search') and the resource ('14,689 x402-payable HTTP endpoints'), distinguishing it from sibling tools like search_products or search_mcp_servers. The scope is explicit and immediately understandable.
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 the tool: 'to find an API an agent can pay for per call' and 'to see what it costs before calling it.' It also lists filter options, providing clear guidance on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_producthow_to_registerscore_urlsearch_mcp_serverssearch_productssearch_x402_endpoints
