Evidence-first registry of real-world APIs for AI agents, with verified metadata and comparison.
Scored across 6 tools
Each tool targets a distinct query type: open-ended task (find_api_for_task), exact filter search (search_apis), capability-level search (search_capabilities), single-record retrieval (get_api), multi-record comparison (compare_apis), and requirement verification (verify_requirement). Descriptions explicitly cross-reference to guide selection, leaving little ambiguity.
All six tools use snake_case with a verb-first pattern (compare_, find_, get_, search_, search_, verify_), and the only deviation is the longer find_api_for_task, which still follows the same convention.
Six tools is well-scoped for an API catalog and decision-support service, covering discovery, retrieval, comparison, and verification without redundancy.
The surface covers the full lifecycle: search by filters or capabilities, task-based discovery, single-API retrieval, multi-API comparison, and requirement verification. No obvious gaps for a read-only catalog.
Compare 2–8 already-known APIs side by side using canonical catalog fields plus capability-graph summary fields such as verified capability count, physical consequences, approval relevance and irreversibility. Use get_api for the full decision profile of one API and search_capabilities for capability-level filtering. No missing value is inferred and Unknown remains Unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| apis | Yes | Required list of 2–8 API slugs or names. Exact matches are preferred; unique partial matches are accepted. Unresolved identifiers are reported separately, and the call fails if fewer than two records resolve. | |
| fields | No | Optional fields to compare. The default includes core catalog fields plus verified capability count, physical-consequence count, approval-relevant count, irreversible/high-consequence count and the decision-profile URL. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| fields | Yes | |
| method | Yes | |
| records | Yes | |
| unresolved | Yes | |
| evidence_policy | Yes | |
| capability_graph | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and non-open-world behavior, so the bar is lower. The description still adds useful data-handling semantics ('No missing value is inferred and Unknown remains Unknown'), which is real behavioral context an agent cannot get from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core comparison scope before the routing hints and data-semantics caveat. Nothing is wasteful, though the field enumeration slightly overlaps schema content.
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?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. Combined with the description's purpose, sibling routing and unknown-value semantics, an agent has everything needed to invoke it 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 description coverage is 100%, so both parameters are fully documented in the schema, including the 2–8 limit, partial-match behavior and failure condition. The description's mention of 'canonical catalog fields plus capability-graph summary fields' largely restates what the fields schema already enumerates, so 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?
States a specific verb (compare) and resource (APIs) with an explicit scope of 2–8 already-known APIs and names the fields used for comparison. It also distinguishes itself from get_api and search_capabilities by naming them, so an agent can route correctly without opening schemas.
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 routes single-API deep dives to get_api and capability-level filtering to search_capabilities, which is clear alternative guidance. It stops short of stating when NOT to use it versus siblings like search_apis or find_api_for_task, so it is strong but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the best APIs for a natural-language physical-world task. Use this for open-ended task or outcome-based recommendations; use search_apis when you already know exact filters, get_api for one known API, or compare_apis for known candidates. Returns an authoritative canonical structured_results shortlist plus a best-effort AI comparison restricted to that shortlist. The canonical engine now applies Verified/High capability evidence before ranking: explicit hard requirements expressed with terms such as must, required, no or without can exclude a candidate only when verified evidence contradicts them. Unknown evidence remains eligible and is surfaced as uncertainty. requirements.mcp, openapi and auth are translated into explicit requirements; categories and capabilities remain task-shaping hints. free_tier and min_readiness are accepted for compatibility but are not hard filters.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Required natural-language goal or workflow, for example 'connect to a car and predict weather on the route'. Describe the desired outcome rather than naming a specific API. | |
| limit | No | Backward-compatible parameter. The canonical browser-parity workflow always produces five structured candidates before the AI comparison, even when another value is supplied. | |
| requirements | No | Optional task requirements appended before canonical ranking. categories and capabilities shape task intent. mcp=Yes, openapi=Yes and auth are expressed as hard task requirements and are evaluated against verified evidence; Unknown does not count as a confirmed contradiction and remains eligible with an uncertainty. free_tier and min_readiness are accepted for backward compatibility but are not hard filters. |
| Name | Required | Description |
|---|---|---|
| ai | Yes | |
| name | Yes | |
| task | Yes | |
| method | No | |
| timing_ms | No | |
| ai_comparison | No | Best-effort grounded explanation of only the structured_results candidates. |
| snapshot_date | No | |
| engine_version | No | |
| coverage_status | No | |
| effective_query | No | |
| grounding_policy | Yes | |
| source_endpoints | No | |
| coverage_warnings | No | |
| structured_results | Yes | Canonical deterministic shortlist. This is the authoritative result set. |
| compatibility_warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it as a read-only, non-idempotent lookup; the description adds the substantive behavior: Verified/High capability evidence gating, that unknown evidence stays eligible and is surfaced as uncertainty, that must/required/no/without only exclude on verified contradiction, and that free_tier/min_readiness are accepted but not hard filters. That is well beyond what annotations provide.
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 routing rule and the constraint on hard requirements are front-loaded and every sentence carries information. However, the requirements paragraph in the description restates much of what the individual property descriptions already say, adding some redundancy to an already dense block.
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 an output schema exists, the description still usefully sketches the return shape (authoritative canonical structured_results shortlist plus a best-effort AI comparison scoped to that shortlist). Combined with the ranking/evidence rules and requirement semantics, an agent has everything needed to call and interpret it.
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%, so baseline is 3, but the description adds real semantics: it clarifies which requirements become hard task requirements (mcp=Yes, openapi=Yes, auth) versus ranking hints (categories, capabilities), and warns that limit is effectively pinned to five and free_tier/min_readiness do not filter. It mostly repeats the per-parameter schema text rather than adding a distinct layer, hence 4 rather than 5.
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 first sentence states a specific verb+resource+scope: 'Find the best APIs for a natural-language physical-world task.' It goes further and explicitly distinguishes itself from three siblings by name (search_apis, get_api, compare_apis), so an agent can route without opening any schema.
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?
It gives an explicit selection rule: use this for open-ended/outcome-based recommendations, use search_apis for known exact filters, get_api for a single known API, compare_apis for known candidates. It also states per-field guidance ('Use search_apis for exact status filtering' and for a strict min_readiness threshold).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one canonical API decision profile when you already know its name or slug. The response includes the full Verified/High capability profile with execution, access, approval, reversibility, physical-consequence and evidence fields. Exact slug or exact API name is preferred; a partial identifier is accepted only when it uniquely resolves to one record.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Required API slug or API name. Exact matches are preferred; a unique case-insensitive partial slug/name match is accepted. If it is ambiguous or missing, use search_apis to find the exact identifier. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| record | Yes | |
| source | Yes | |
| evidence_policy | Yes | |
| capability_graph | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior, so safety is covered. The description adds genuinely useful context beyond those hints: the response is the full Verified/High capability profile with named field groups, and the ambiguous-identifier failure mode is disclosed.
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?
Three sentences, each earning its place: identity/scope first, response contents second, matching constraints last. Nothing is redundant or padded.
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 single-identifier read tool with full annotation coverage and an output schema, this description supplies everything an agent needs: when to use it, what comes back, and how the identifier is resolved. No meaningful gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter is already fully documented, including the exact-vs-partial matching rule and the guidance to fall back to search_apis. The description largely restates that matching rule rather than adding syntax or format detail, so the baseline 3 is correct.
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?
States a specific verb (Retrieve) and resource (one canonical API decision profile) with a clear scope qualifier ('one canonical'). It is easily distinguished from search_apis and the other siblings, which are discovery-oriented rather than single-record 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?
The opening clause 'when you already know its name or slug' tells the agent exactly the condition for choosing this over a search tool, and the partial-identifier rule sets the boundary further. It stops short of naming search_apis as the fallback in the description itself (that routing lives in the schema), so it's clear but not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the canonical registry when you already know keywords or exact requirements. All supplied filter groups combine with AND logic; array capability filters require every supplied value, and protocol fields match the exact Yes/No/Unknown status, so Unknown never satisfies Yes. Results include each API's capability_summary and direct decision-profile URL. Results are sorted by agent_readiness_score descending and then API name, with 1–20 results returned (default 10). Use search_capabilities when you need capability-level filters such as approval, physical consequence, sandbox or access friction.
| Name | Required | Description | Default |
|---|---|---|---|
| a2a | No | Exact A2A evidence status required for a match. | |
| mcp | No | Exact MCP evidence status required for a match. | |
| x402 | No | Exact x402 evidence status required for a match. | |
| limit | No | Maximum number of matching records returned. Results are sorted by readiness descending then API name. total_matches still reports the full count. No pagination is currently exposed. | |
| query | No | Optional case-insensitive text search across API name, provider, category, description, capabilities, agent capabilities and authentication fields. | |
| openapi | No | Exact OpenAPI evidence status required for a match. | |
| llms_txt | No | Exact llms.txt evidence status required for a match. | |
| categories | No | Exact category names. Supplying multiple category values allows a record to match any listed category; this category condition still combines with every other supplied filter group using AND logic. | |
| capabilities | No | Capability terms that must all be present in the record's verified capabilities. Matching is case-insensitive and allows a capability string to contain the supplied term. | |
| min_readiness | No | Strict minimum agent-readiness score. Records below this score are excluded. | |
| agent_actionable | No | When true, require agent_actionable = true. False does not exclude actionable records; omit this field unless you need the positive requirement. | |
| agent_capabilities | No | Agent capability dimensions that must all be explicitly present on a record. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| query | No | |
| method | Yes | |
| filters | Yes | |
| results | Yes | |
| returned | Yes | |
| total_matches | Yes | |
| evidence_policy | Yes | |
| capability_graph | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by disclosing cross-filter AND logic, the rule that Unknown never satisfies Yes, result sorting (readiness desc, then name), the 1-20 bound with default 10, and the absence of pagination. It stops short of describing the actual result payload shape, but the output schema covers that.
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?
Dense but front-loaded: purpose, then matching semantics, then result behavior, then the alternative. Every sentence carries information, though the sorting/limit detail is stated twice (once in prose, once in the limit schema description).
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 12-parameter filtered-search tool with an output schema and full annotation coverage, the description supplies everything needed to call it correctly, including match semantics and result sizing. Return values are correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds cross-cutting semantics the per-parameter schema text does not: filter groups combine with AND, array capability filters require every supplied value, and exact protocol status means Unknown never matches Yes. That is meaningful behavior layered on top of already-documented parameters.
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?
States a specific verb (search) and resource (the canonical registry) and immediately scopes it to the case where the caller knows keywords or exact requirements. It also names the sibling it is not (search_capabilities), so an agent can distinguish it without opening either schema.
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 this tool ('already know keywords or exact requirements') and routes the capability-filter case to search_capabilities. The condition that selects the alternative is spelled out, not left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the canonical 770-capability Verified/High decision graph directly. Use this when the question is about what an agent can actually do and under what execution conditions: task/capability text, API, category, action type, acted-on object, human approval, physical consequence, irreversibility, sandbox, hardware dependency, access friction or setup. All supplied filter groups combine with AND logic; multiple values inside one array filter are alternatives (OR). Unknown remains Unknown and may be filtered explicitly by passing the literal value Unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum capability rows returned. total_matches reports the full match count. | |
| query | No | Optional case-insensitive text search across API/provider/category, capability key/name, primitive/action type, object, execution fields and constraints. Search terms may match across different capability fields; all supplied terms must be present somewhere in the capability record. | |
| object | No | Case-insensitive substring match on the object acted upon, such as smart lock, parcel or charging session. | |
| sandbox | No | Exact sandbox/test-environment labels, including Unknown when desired. | |
| api_slugs | No | Optional API slugs. Multiple values are OR within this filter. | |
| categories | No | Exact category labels. Multiple values are OR within this filter. | |
| primitives | No | Exact capability primitives such as Observe, Locate, Predict, Plan, Control or Act. | |
| agent_setup | No | Exact agent-setup labels such as Fully self-service or Human setup required. | |
| action_types | No | Exact action types such as Read, Search, Analyze, Route or Control. | |
| actionability | No | Exact actionability labels such as Information only, Planning or Physical action. | |
| human_approval | No | Exact approval labels, for example Required, Not required, Depends on action or Unknown. | |
| access_friction | No | Exact access-friction labels such as Self-service signup, Sales contract or Hardware ecosystem. | |
| hardware_dependency | No | Exact hardware-dependency labels. | |
| physical_consequence | No | When supplied, require the exact physical-consequence boolean. | |
| irreversible_high_consequence | No | When supplied, require the exact irreversible/high-consequence boolean. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| method | Yes | |
| source | Yes | |
| filters | Yes | |
| results | Yes | |
| returned | Yes | |
| total_matches | Yes | |
| evidence_policy | Yes | |
| machine_schema_version | No | |
| capability_snapshot_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, idempotent and closed-world behavior. The description adds meaningful query behavior beyond annotations: cross-filter AND logic, OR-within-array semantics, and explicit Unknown filtering.
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?
Three sentences, front-loaded with the core action and resource. The long use-case list is dense but earns its place by routing the agent, and the filter-logic sentence is essential.
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 15 optional parameters, a full input schema, an output schema, and safety annotations, the description supplies the missing query-composition and Unknown-handling rules. Nothing critical for correct invocation is absent.
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 covers all 15 parameters at 100%, so the baseline is 3. The description adds cross-parameter semantics not fully stated in the schema, especially that filter groups combine with AND and array values combine with OR.
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?
States a specific verb and resource: search the canonical 770-capability Verified/High decision graph. The scope and domain are clear enough to distinguish it from sibling API-search tools like search_apis and find_api_for_task.
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 this tool: questions about what an agent can actually do and under what execution conditions, listing relevant filter dimensions. It does not name alternative siblings or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify whether one specific API can satisfy one exact requirement using the canonical Verified/High capability graph plus linked assertion evidence. Returns YES, NO, PARTIAL or UNKNOWN with matched capability, access/setup prerequisites, approval, safety, reversibility, reliability, coverage and other requested dimensions; direct provider facts remain distinct from inferred policy assertions. Unknown remains Unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| api | Yes | Exact API slug or API name, for example nuki-web-api or Nuki Web API. | |
| location | No | Optional geographic coverage requirement, for example Sweden. Coverage is returned as Unknown/Partial when the normalized capability graph does not contain enough location evidence. | |
| requirement | Yes | Specific requirement to verify, for example 'remotely unlock a smart lock without human approval'. |
| Name | Required | Description |
|---|---|---|
| api | Yes | |
| reasons | Yes | |
| verdict | Yes | |
| evidence | No | |
| location | No | |
| confidence | Yes | |
| dimensions | Yes | |
| consequence | No | |
| limitations | No | |
| requirement | Yes | |
| prerequisites | No | |
| schema_version | Yes | |
| api_snapshot_date | No | |
| assertion_backend | No | |
| assertion_findings | No | |
| evidence_semantics | Yes | |
| matched_capability | No | |
| capability_snapshot_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world safety, so the bar is lower. The description nonetheless discloses the response vocabulary (YES/NO/PARTIAL/UNKNOWN), what accompanies it (matched capability, prerequisites, approval, safety, coverage), and the important epistemic rule that provider facts stay distinct from inferred policy assertions while unknowns remain unknown. It stays short of a full description of confidence/pagination 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 core purpose is front-loaded in the opening clause, and the rest is dense with substantive content rather than filler. The second half is a long run-on list, slightly reducing readability, but no sentence is wasted.
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?
An output schema exists, so return shape need not be explained, yet the description wisely spends its words on the epistemic distinction between direct provider facts and inferred policy assertions — the one thing the schema cannot convey. For a read-only verification tool this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents api, location, and requirement with examples. The description adds only marginal framing (that requested dimensions are echoed) and does not enrich the parameters beyond what the schema states; 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?
States a specific verb+resource+scope: verify one API against one exact requirement, using the Verified/High capability graph plus assertion evidence. This clearly separates it from sibling find_api_for_task (search) and compare_apis (multi-API).
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 'one specific API ... one exact requirement' framing tells the agent this is a single-pair check rather than a search, and names the input contract implicitly. It does not explicitly name alternatives or when-not-to-use it, so it stops short of 5.
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.
verify_requirementsearch_capabilities1 field changedInput schema / properties / query / descriptionPrevious value: -"Optional case-insensitive text search across API/provider/category, capability key/name, primitive/action type, object, execution fields and constraints."New value: +"Optional case-insensitive text search across API/provider/category, capability key/name, primitive/action type, object, execution fields and constraints. Search terms may match across different capability fields; all supplied terms must be present somewhere in the capability record."compare_apis3 fields changedInput schema / properties / fields / descriptionPrevious value: -"Optional fields to compare. If omitted or empty, the tool uses the default core fields: provider, category, capabilities, agent_capabilities, auth_methods, openapi, mcp, a2a, x402, llms_txt, agent_readiness_score, public_documentation, authentication_verified and agent_actionable."New value: +"Optional fields to compare. The default includes core catalog fields plus verified capability count, physical-consequence count, approval-relevant count, irreversible/high-consequence count and the decision-profile URL."Input schema / properties / fields / items / enumPrevious value: -[
- "provider",
- "category",
- "description",
- "capabilities",
- "agent_capabilities",
- "auth_methods",
- "openapi",
- "mcp",
- "a2a",
- "x402",
- "llms_txt",
- "agent_readiness_score",
- "public_documentation",
- "authentication_verified",
- "agent_actionable",
- "website",
- "docs_url"
-]New value: +[
+ "provider",
+ "category",
+ "description",
+ "capabilities",
+ "agent_capabilities",
+ "auth_methods",
+ "openapi",
+ "mcp",
+ "a2a",
+ "x402",
+ "llms_txt",
+ "agent_readiness_score",
+ "public_documentation",
+ "authentication_verified",
+ "agent_actionable",
+ "website",
+ "docs_url",
+ "verified_capability_count",
+ "information_only_count",
+ "physical_consequence_count",
+ "irreversible_high_consequence_count",
+ "approval_relevant_count",
+ "capability_profile_url"
+]Output schema / properties / capability_graphAdded value: +{
+ "type": "string"
+}find_api_for_task4 fields changedInput schema / properties / requirements / descriptionPrevious value: -"Optional compatibility hints appended to the task before canonical ranking. categories, capabilities, mcp, openapi and auth influence the effective query. free_tier and min_readiness are accepted for backward compatibility but are not hard filters; use search_apis when you need strict field filtering."New value: +"Optional task requirements appended before canonical ranking. categories and capabilities shape task intent. mcp=Yes, openapi=Yes and auth are expressed as hard task requirements and are evaluated against verified evidence; Unknown does not count as a confirmed contradiction and remains eligible with an uncertainty. free_tier and min_readiness are accepted for backward compatibility but are not hard filters."Input schema / properties / requirements / properties / auth / descriptionPrevious value: -"Preferred authentication method, appended to the effective task as a ranking hint."New value: +"Authentication requirement appended as an explicit task requirement. The canonical engine excludes only when the verified API authentication methods contradict it."Input schema / properties / requirements / properties / mcp / descriptionPrevious value: -"Compatibility hint for MCP support. Only Yes becomes an explicit 'Must support MCP' task hint; use search_apis for exact Yes/No/Unknown filtering."New value: +"When set to Yes, becomes an explicit 'Must support MCP' requirement. Verified No excludes; Unknown remains eligible with an uncertainty. Use search_apis for exact status filtering."Input schema / properties / requirements / properties / openapi / descriptionPrevious value: -"Compatibility hint for OpenAPI support. Only Yes becomes an explicit task hint; use search_apis for exact Yes/No/Unknown filtering."New value: +"When set to Yes, becomes an explicit OpenAPI requirement. Verified No excludes; Unknown remains eligible with an uncertainty. Use search_apis for exact status filtering."get_api5 fields changedOutput schema / properties / capability_graphAdded value: +{
+ "type": "string"
+}Output schema / properties / record / properties / capability_profileAdded value: +{
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / record / properties / capability_profile_urlAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / record / properties / capability_summaryAdded value: +{
+ "additionalProperties": true,
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "name",
- "record",
- "source",
- "evidence_policy"
-]New value: +[
+ "name",
+ "record",
+ "source",
+ "capability_graph",
+ "evidence_policy"
+]search_apis4 fields changedOutput schema / properties / capability_graphAdded value: +{
+ "type": "string"
+}Output schema / properties / results / items / properties / capability_profileAdded value: +{
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / results / items / properties / capability_profile_urlAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / results / items / properties / capability_summaryAdded value: +{
+ "additionalProperties": true,
+ "type": [
+ "object",
+ "null"
+ ]
+}search_capabilitiescompare_apis4 fields changedInput schema / properties / apis / descriptionPrevious value: -"API slugs or names."New value: +"Required list of 2–8 API slugs or names. Exact matches are preferred; unique partial matches are accepted. Unresolved identifiers are reported separately, and the call fails if fewer than two records resolve."Input schema / properties / fields / descriptionAdded value: +"Optional fields to compare. If omitted or empty, the tool uses the default core fields: provider, category, capabilities, agent_capabilities, auth_methods, openapi, mcp, a2a, x402, llms_txt, agent_readiness_score, public_documentation, authentication_verified and agent_actionable."Input schema / properties / fields / uniqueItemsAdded value: +trueOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "evidence_policy": {
+ "type": "string"
+ },
+ "fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "method": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "records": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "values": {
+ "additionalProperties": true,
+ "type": "object"
+ }
+ },
+ "required": [
+ "slug",
+ "name",
+ "values"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "unresolved": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "method",
+ "fields",
+ "records",
+ "unresolved",
+ "evidence_policy"
+ ],
+ "type": "object"
+}find_api_for_task11 fields changedInput schema / properties / limit / descriptionAdded value: +"Backward-compatible parameter. The canonical browser-parity workflow always produces five structured candidates before the AI comparison, even when another value is supplied."Input schema / properties / requirements / descriptionAdded value: +"Optional compatibility hints appended to the task before canonical ranking. categories, capabilities, mcp, openapi and auth influence the effective query. free_tier and min_readiness are accepted for backward compatibility but are not hard filters; use search_apis when you need strict field filtering."Input schema / properties / requirements / properties / auth / descriptionAdded value: +"Preferred authentication method, appended to the effective task as a ranking hint."Input schema / properties / requirements / properties / capabilities / descriptionAdded value: +"Desired agent capability dimensions. These are appended as ranking hints, not strict filters."Input schema / properties / requirements / properties / categories / descriptionAdded value: +"Preferred catalog categories, such as Geospatial, Weather or Mobility. These are ranking hints, not strict filters."Input schema / properties / requirements / properties / free_tier / descriptionAdded value: +"Backward-compatible field only. The canonical recommendation engine does not currently hard-filter on free-tier availability."Input schema / properties / requirements / properties / mcp / descriptionAdded value: +"Compatibility hint for MCP support. Only Yes becomes an explicit 'Must support MCP' task hint; use search_apis for exact Yes/No/Unknown filtering."Input schema / properties / requirements / properties / min_readiness / descriptionAdded value: +"Backward-compatible field only. It does not hard-filter the canonical top five; use search_apis for a strict minimum readiness threshold."Input schema / properties / requirements / properties / openapi / descriptionAdded value: +"Compatibility hint for OpenAPI support. Only Yes becomes an explicit task hint; use search_apis for exact Yes/No/Unknown filtering."Input schema / properties / task / descriptionPrevious value: -"Natural-language physical-world API task."New value: +"Required natural-language goal or workflow, for example 'connect to a car and predict weather on the route'. Describe the desired outcome rather than naming a specific API."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "ai": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "ai_comparison": {
+ "additionalProperties": true,
+ "description": "Best-effort grounded explanation of only the structured_results candidates.",
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "compatibility_warnings": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "coverage_status": {
+ "type": "string"
+ },
+ "coverage_warnings": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "effective_query": {
+ "type": "string"
+ },
+ "engine_version": {
+ "type": "string"
+ },
+ "grounding_policy": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "method": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "snapshot_date": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source_endpoints": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "structured_results": {
+ "description": "Canonical deterministic shortlist. This is the authoritative result set.",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "task": {
+ "type": "string"
+ },
+ "timing_ms": {
+ "additionalProperties": true,
+ "type": "object"
+ }
+ },
+ "required": [
+ "name",
+ "task",
+ "structured_results",
+ "ai",
+ "grounding_policy"
+ ],
+ "type": "object"
+}get_api2 fields changedInput schema / properties / identifier / descriptionPrevious value: -"API slug or API name."New value: +"Required API slug or API name. Exact matches are preferred; a unique case-insensitive partial slug/name match is accepted. If it is ambiguous or missing, use search_apis to find the exact identifier."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "evidence_policy": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "record": {
+ "additionalProperties": true,
+ "properties": {
+ "a2a": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "agent_actionable": {
+ "type": "boolean"
+ },
+ "agent_capabilities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "agent_readiness_score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "auth_methods": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "authentication_verified": {
+ "type": "boolean"
+ },
+ "capabilities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "docs_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "llms_txt": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "mcp": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "openapi": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "public_documentation": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "website": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "x402": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "record",
+ "source",
+ "evidence_policy"
+ ],
+ "type": "object"
+}search_apis13 fields changedInput schema / properties / a2a / descriptionAdded value: +"Exact A2A evidence status required for a match."Input schema / properties / agent_actionable / descriptionAdded value: +"When true, require agent_actionable = true. False does not exclude actionable records; omit this field unless you need the positive requirement."Input schema / properties / agent_capabilities / descriptionAdded value: +"Agent capability dimensions that must all be explicitly present on a record."Input schema / properties / capabilities / descriptionAdded value: +"Capability terms that must all be present in the record's verified capabilities. Matching is case-insensitive and allows a capability string to contain the supplied term."Input schema / properties / categories / descriptionAdded value: +"Exact category names. Supplying multiple category values allows a record to match any listed category; this category condition still combines with every other supplied filter group using AND logic."Input schema / properties / limit / descriptionAdded value: +"Maximum number of matching records returned. Results are sorted by readiness descending then API name. total_matches still reports the full count. No pagination is currently exposed."Input schema / properties / llms_txt / descriptionAdded value: +"Exact llms.txt evidence status required for a match."Input schema / properties / mcp / descriptionAdded value: +"Exact MCP evidence status required for a match."Input schema / properties / min_readiness / descriptionAdded value: +"Strict minimum agent-readiness score. Records below this score are excluded."Input schema / properties / openapi / descriptionAdded value: +"Exact OpenAPI evidence status required for a match."Input schema / properties / query / descriptionPrevious value: -"Optional text search across name, provider, category, description, capabilities and auth."New value: +"Optional case-insensitive text search across API name, provider, category, description, capabilities, agent capabilities and authentication fields."Input schema / properties / x402 / descriptionAdded value: +"Exact x402 evidence status required for a match."Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": false,
+ "properties": {
+ "evidence_policy": {
+ "type": "string"
+ },
+ "filters": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "method": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "a2a": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "agent_actionable": {
+ "type": "boolean"
+ },
+ "agent_capabilities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "agent_readiness_score": {
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+ },
+ "auth_methods": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "authentication_verified": {
+ "type": "boolean"
+ },
+ "capabilities": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "docs_url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "llms_txt": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "mcp": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "openapi": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "public_documentation": {
+ "type": "boolean"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "website": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "x402": {
+ "enum": [
+ "Yes",
+ "No",
+ "Unknown"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "returned": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "total_matches": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "name",
+ "method",
+ "filters",
+ "total_matches",
+ "returned",
+ "results",
+ "evidence_policy"
+ ],
+ "type": "object"
+}compare_apisfind_api_for_task4 fields changedInput schema / properties / limit / descriptionRemoved value: -"Accepted for backward compatibility. The canonical browser-parity engine always produces five structured candidates before AI comparison."Input schema / properties / requirements / descriptionRemoved value: -"Backward-compatible query hints. mcp/openapi/auth/categories/capabilities are translated into explicit natural-language requirements before the canonical browser engine runs. free_tier and min_readiness are accepted but are not hard filters in browser-parity mode."Input schema / properties / task / descriptionPrevious value: -"Natural-language description of the real-world API task."New value: +"Natural-language physical-world API task."Output schema / (root)Previous value: -{
- "properties": {
- "ai": {
- "type": "object"
- },
- "ai_comparison": {
- "type": [
- "object",
- "null"
- ]
- },
- "compatibility_warnings": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "coverage_status": {
- "type": "string"
- },
- "coverage_warnings": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "effective_query": {
- "type": "string"
- },
- "engine_version": {
- "type": "string"
- },
- "grounding_policy": {
- "type": "object"
- },
- "method": {
- "type": "string"
- },
- "name": {
- "type": "string"
- },
- "snapshot_date": {
- "type": [
- "string",
- "null"
- ]
- },
- "source_endpoints": {
- "type": "object"
- },
- "structured_results": {
- "items": {
- "type": "object"
- },
- "type": "array"
- },
- "task": {
- "type": "string"
- },
- "timing_ms": {
- "type": "object"
- }
- },
- "required": [
- "name",
- "engine_version",
- "method",
- "task",
- "structured_results",
- "ai",
- "grounding_policy"
- ],
- "type": "object"
-}New value: +nullget_apisearch_apisfind_api_for_task1 field changedOutput schema / properties / timing_msAdded value: +{
+ "type": "object"
+}find_api_for_task31 fields changedInput schema / properties / limit / defaultPrevious value: -3New value: +5Input schema / properties / limit / descriptionPrevious value: -"Maximum number of ranked recommendations to return."New value: +"Accepted for backward compatibility. The canonical browser-parity engine always produces five structured candidates before AI comparison."Input schema / properties / requirements / descriptionPrevious value: -"Canonical location for structured hard constraints. Do not put capabilities, mcp, openapi, auth, free_tier, category, or min_readiness at the top level."New value: +"Backward-compatible query hints. mcp/openapi/auth/categories/capabilities are translated into explicit natural-language requirements before the canonical browser engine runs. free_tier and min_readiness are accepted but are not hard filters in browser-parity mode."Input schema / properties / requirements / properties / auth / descriptionRemoved value: -"Required authentication method."Input schema / properties / requirements / properties / capabilities / descriptionRemoved value: -"All listed real-world capabilities must be true for an eligible API."Input schema / properties / requirements / properties / categories / descriptionRemoved value: -"Allowed RealWorldAPIs categories. Use only when category itself is a hard constraint."Input schema / properties / requirements / properties / free_tier / descriptionRemoved value: -"When true, only APIs audited as having a free tier remain eligible."Input schema / properties / requirements / properties / mcp / descriptionRemoved value: -"Set to Yes when MCP support is required."Input schema / properties / requirements / properties / min_readiness / descriptionRemoved value: -"Minimum audited Agent Readiness Score."Input schema / properties / requirements / properties / openapi / descriptionRemoved value: -"Set to Yes when OpenAPI support is required."Input schema / properties / task / descriptionPrevious value: -"Natural-language description of what the agent or application needs to do. State hard requirements explicitly, for example: 'must support MCP'."New value: +"Natural-language description of the real-world API task."Output schema / properties / agent_summaryRemoved value: -{
- "properties": {
- "alternatives": {
- "items": {
- "type": "object"
- },
- "type": "array"
- },
- "grounding_policy": {
- "type": "object"
- },
- "presentation_guidance": {
- "type": "string"
- },
- "top_pick": {
- "type": [
- "object",
- "null"
- ]
- }
- },
- "type": "object"
-}Output schema / properties / aiAdded value: +{
+ "type": "object"
+}Output schema / properties / ai_comparisonAdded value: +{
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / catalog_sizeRemoved value: -{
- "type": "integer"
-}Output schema / properties / caveatRemoved value: -{
- "type": "string"
-}Output schema / properties / compatibility_warningsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / coverage_statusAdded value: +{
+ "type": "string"
+}Output schema / properties / coverage_warningsAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / effective_queryAdded value: +{
+ "type": "string"
+}Output schema / properties / eligible_countRemoved value: -{
- "type": "integer"
-}Output schema / properties / grounding_policyAdded value: +{
+ "type": "object"
+}Output schema / properties / input_normalizationRemoved value: -{
- "type": "object"
-}Output schema / properties / methodAdded value: +{
+ "type": "string"
+}Output schema / properties / recommendationsRemoved value: -{
- "items": {
- "type": "object"
- },
- "type": "array"
-}Output schema / properties / requirements_appliedRemoved value: -{
- "type": "object"
-}Output schema / properties / requirements_detectedRemoved value: -{
- "type": "object"
-}Output schema / properties / snapshot_dateAdded value: +{
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / source_endpointsAdded value: +{
+ "type": "object"
+}Output schema / properties / structured_resultsAdded value: +{
+ "items": {
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "name",
- "engine_version",
- "task",
- "catalog_size",
- "eligible_count",
- "agent_summary",
- "recommendations",
- "caveat"
-]New value: +[
+ "name",
+ "engine_version",
+ "method",
+ "task",
+ "structured_results",
+ "ai",
+ "grounding_policy"
+]find_api_for_taskDiscover, compare, and monitor 1,400+ APIs directly from your AI coding agent.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Directory of APIs, merchants, and tools AI agents can actually use.
Marketplace-evidence trust scores for AI agents: a 0-100 Evidence Score with signal breakdown.
Add one secure layer between your agents and this server.
