Find any agent service, and check it before you pay for it or rely on it.
Scored across 10 tools
Each tool targets a clearly distinct operation: discovery (get_tree, search_services, get_service), monitoring (get_changes, get_history, get_report, get_stats), and reporting/submission (report_outcome, send_feedback, submit_service). The only mild overlaps are get_report vs get_stats (weekly report vs 24h count snapshot) and get_tree vs search_services, but the descriptions explicitly frame the tree-then-search flow so an agent can distinguish them.
Every tool name is snake_case with a verb_noun structure: get_* (six tools), search_services, send_feedback, submit_service, report_outcome. No camelCase or stylistic mixing, and the get_ prefix consistently signals read operations.
Ten tools sit comfortably in the well-scoped range for a service directory covering search, detail, monitoring, reporting, and submission. No redundant or obviously filler tools, and no single operation is artificially split.
The surface covers the full loop: discover (tree, search), inspect (service, history, changes), aggregate (stats, report), report outcomes, give feedback, and submit new services. Minor gaps exist, such as no tool to view the referenced public roadmap or to update/withdraw a submitted service, but core workflows have no dead ends.
Recently detected changes to monitored documentation and API schemas, across all reviewed services or for one. A detected change is pending interpretation, not necessarily a breaking change.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Limit to one service. | |
| days | No | Default 7. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine domain context with 'pending interpretation, not necessarily a breaking change,' which steers interpretation of results, but it says nothing about time-window defaults, pagination, or result volume.
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 compact sentences, with the resource and scope front-loaded and the semantic caveat second. Nothing is wasted, though 'recently' is left vague when a concrete default window is available to state.
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 two-parameter read-only tool with no output schema and no nested objects, the description covers scope, filtering intent, and the nature of the returned data. It is close to complete, with only the trigger to use it over get_history left implicit.
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 (id, days) are already documented in the schema; baseline 3 applies. The description's 'or for one' loosely reinforces the id filter but adds no format or semantics beyond what the schema supplies, and never mentions the days window.
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 clear resource (recently detected changes) and its scope (monitored documentation and API schemas across all reviewed services or one), plus a definition of what a 'detected change' means. It does not name or contrast with any sibling such as get_history, so the agent must infer the boundary between current changes and historical ones.
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 phrase 'across all reviewed services or for one' implies the optional id filter, and 'pending interpretation' hints at the state of results. However, there is no explicit when-to-use guidance, no exclusion vs get_history/get_report, and no stated prerequisite for interpreting the results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Individual check results for a service over the last days, newest first. Use it to see patterns (intermittent failures, slowdowns) behind the summary figures.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| days | No | Default 7. | |
| limit | No | Default 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the ordering ('newest first') and the use case, which is useful context beyond annotations. Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false). However, the description does not mention pagination behavior (limit parameter handling), rate limits, or whether all historical data is retained beyond the days parameter. With annotations covering safety, this is adequate but not rich.
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, front-loaded with the core output description and then the usage guidance. No wasted words; every sentence 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?
Given the absence of an output schema, the description should explain what the return values contain beyond the ordering. It mentions 'individual check results' and 'patterns' but does not specify the fields or structure of a check result. For a tool that returns potentially large datasets, more detail on pagination or result shape would be helpful. The annotations cover the safety profile, and the description is adequate but leaves gaps for an agent to confidently call it and interpret results.
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 67%, with 'days' and 'limit' having descriptions ('Default 7.' and 'Default 50.'). The description does not add any parameter details beyond what is in the schema. Baseline 3 is appropriate when schema provides partial 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 tool returns 'individual check results for a service over the last days, newest first', which is a specific verb+resource and indicates the ordering. It does not explicitly differentiate from sibling tools like get_report or get_stats, but the specificity of 'individual check results' helps the agent understand it's a detailed drill-down.
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 provides clear context: 'Use it to see patterns (intermittent failures, slowdowns) behind the summary figures.' This implies when to use it versus summary tools like get_report or get_stats, though it does not name those alternatives explicitly 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.
The weekly State of Agent Services report: coverage, probe results, payment networks, prices and purpose tags across everything we track. Counts and distributions only, with their method. Omit id for the latest published report; 'current' gives provisional week-to-date figures.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Report id (the Monday that starts the week, e.g. '2026-10-19'), or 'current'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds substantive context beyond them: results are aggregates only ('counts and distributions only, with their method') and 'current' figures are provisional week-to-date, a data-freshness caveat the annotations do not convey. It stops short of describing pagination or output volume.
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?
Purpose and scope are front-loaded in the first sentence, with parameter-mode guidance following. It is dense and largely waste-free, though the middle clause ('Counts and distributions only, with their method') is slightly clipped in phrasing.
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 optional parameter with no output schema, the description adequately covers what the report contains and how to select the latest versus provisional version. It could say a bit more about scope boundaries versus the stats/history siblings, but nothing essential for a correct call 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?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot express: the absent-id default (latest published report) and the distinction between a final dated report and the provisional 'current' mode. That is real added value over the pattern documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('weekly State of Agent Services report') and enumerates the covered domains (coverage, probe results, payment networks, prices, purpose tags), which implicitly separates it from siblings like get_stats or get_changes. It never names a sibling explicitly, so it falls short of the 5 bar for full differentiation.
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 gives mode-selection guidance for the id parameter (omit for latest published, 'current' for provisional week-to-date), which is genuinely useful. However, it never states when to prefer this tool over alternatives such as get_stats or get_history, so selection versus siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full evidence and connection details for one service, plus a referral_id. Use the referral_id with report_outcome after you use the service (valid 7 days).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A service id from search_services, e.g. 'svc_...' or 'cand_...'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as non-read-only, non-idempotent and closed-world, and the description supplies the reason implicitly by revealing that a referral_id is minted and consumed by report_outcome. The 7-day expiry is useful behavioral context the annotations cannot express; it stops short of explaining what happens on expiry or re-calls.
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 short sentences, zero filler, with the return payload front-loaded and the follow-up action second. Every clause 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?
No output schema exists, and the description sketches the response contents (evidence, connection details, referral_id) plus the required next step, which is enough for a 1-param lookup. Minor gaps remain around failure modes when the id is unknown or the referral has expired.
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% and the single 'id' param already documents the 'svc_...'/'cand_...' formats, so the schema carries the load. The description adds no additional parameter meaning, which is the expected baseline when coverage is this high.
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 ('get_service' → full evidence and connection details for one service) and discloses an extra return element, the referral_id. It is clearly distinct from the search_services sibling referenced in the schema, though no sibling is named in the description itself.
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?
Gives explicit downstream workflow: take the referral_id to report_outcome after using the service, with a stated 7-day validity window. It does not explicitly state when to prefer this over get_report or get_history, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many services we track and how many checks ran in the last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact the annotations do not convey: the window is fixed at the last 24 hours, meaning the metric cannot be re-scoped. It does not say whether results are cached, when they refresh, or what the return shape looks like.
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?
A single sentence with no filler, and the time window is front-and-center rather than buried. It is efficient, though the noun-phrase phrasing (no leading verb) slightly softens the front-loading compared to a 'Returns X' construction.
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, read-only summary tool with annotations covering safety and no output schema, the description supplies the essential content: which two numbers come back and over what period. What remains absent — refresh/caching behavior and precision of the counts — is minor for a tool of this 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?
The tool takes zero parameters, so the baseline of 4 applies; there are no parameter semantics to explain or miss. The description correctly implies the tool is parameterless by presenting the figures as fixed facts rather than as queryable dimensions.
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 names the two concrete metrics returned — the count of tracked services and the count of checks in the last 24 hours — so an agent knows exactly what this tool produces. It is clearly distinct from get_service (single entity), get_history/get_changes (event streams), and get_report (reports), though it never explicitly names those siblings to draw the boundary.
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?
There is no when-to-use or when-not-to-use statement and no alternative is named. An agent must infer that this is the entry point for summary counts rather than consulting get_report or get_history, and nothing clarifies whether this is a good first call or a last resort.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The capability tree: what services do, as branches, leaves and leaves' children, each with a one-line description and the number of services in it (zeros included). Read it once (follow its guide), choose the most specific node that matches your task, then call search_services with branch set to its id, or up to three ids separated by commas when more than one fits. format "text" returns the same tree as plain text, one line per node: the cheapest to read. Keep it and pass since_revision later to get only what changed. IDs are permanent: an id that moved (listed under moved) still works as a branch filter.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json (default) or text: one line per node, about half the size of json. | |
| since_revision | No | The revision of a copy you hold: returns only the node changes since then (or unchanged: true) instead of the tree. Service counts are refreshed every hour and are not changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral context the annotations cannot — counts include zeros, counts refresh hourly and don't count as changes, and an id that moved still works as a branch filter. These are non-obvious traits that prevent misreading the output. It stops short of describing error behavior or what unchanged:true looks like in practice.
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?
Front-loaded with the resource and the follow-up action, and nearly every clause carries an actionable fact. It is dense to the point of being run-on, packing format, revision retention, and ID permanence into one long paragraph, which slightly hurts scannability.
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?
With no output schema, the description takes on the burden and discharges it by describing the returned tree's shape (branches, leaves, one-line descriptions, counts) and the text-format line-per-node layout. An agent has everything needed to call it and to interpret what comes back.
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; the description earns above that by explaining the tradeoff for format="text" ('about half the size', 'cheapest to read') and the retention pattern for since_revision ('keep it and pass later to get only what changed'). It still omits some nuance, e.g. what since_revision=0 means or the shape of the change payload.
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 concrete resource (the capability tree) and its structure — branches, leaves, leaves' children, one-line descriptions, service counts. It also distinguishes itself from the sibling search_services by defining the downstream relationship, so an agent knows this is the navigation layer rather than the search itself.
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?
Gives an explicit procedure: read once, follow the guide, pick the most specific matching node, then call search_services with branch set to its id (or up to three comma-separated ids). It also advises retaining the tree for later since_revision calls, which is a genuine when-to-use instruction rather than a restatement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
After using a service, report whether it worked. Requires a free API key (Authorization: Bearer asd_...; get one with POST https://agentservicedirectory.com/api/v1/keys). Quote the referral_id from get_service. Reports are stored as unverified claims and published only after moderation. Never include task data, secrets or personal information.
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| operation | No | Which operation, e.g. 'GET /v1/search'. | |
| service_id | No | If you have no referral_id. | |
| referral_id | No | From get_service. Preferred. | |
| failure_kind | No | ||
| task_category | No | Broad category only, e.g. 'web-search'. No task content. | |
| idempotency_key | Yes | Unique per report; retries with the same key are not counted twice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare idempotent/not-read-only; the description goes well beyond them by disclosing the free API key requirement with the exact Bearer scheme and key-provisioning endpoint, plus that reports are stored as unverified claims and only published after moderation, and a data-hygiene prohibition on task data, secrets and PII.
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?
Front-loads the purpose in the first clause, then layers prerequisites, provenance and prohibitions in a compact sequence of sentences. Auth endpoint detail is useful but slightly dense for the opening line.
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?
A write tool with no output schema is well covered on auth, idempotency and data handling. It could still say what a successful or rejected report returns, and whether moderation blocks the caller, but the preconditions an agent needs are all present.
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 71% and the enum values are self-documenting, so the baseline is 3. The description reinforces referral_id provenance and adds a hygiene rule relevant to task_category, but supplies no format or syntax detail the schema does not already carry.
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 with timing scoped to 'After using a service', so the agent knows exactly what is being recorded. It does not differentiate itself from the sibling send_feedback, which an agent could plausibly confuse with outcome reporting.
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?
Gives clear trigger context ('after using a service') and points at get_service as the source of the preferred identifier, so the agent knows the prerequisite flow. There is no explicit when-not guidance or comparison against send_feedback/get_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find services an agent can use, by what they do: remote MCP servers (with the tools each lists), local MCP servers (packages), pay-per-call APIs (x402, MPP), A2A agents and task marketplaces, with our checks for each. Search by words (query) or by capability tree node (branch); filter on type, access (none_asked, payment, credentials), max_price_usd and the evidence (passing, min_pass_rate); then call get_service for connection details. Results are compact; use limit/offset to page.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Purpose tag, e.g. 'web-search'. | |
| acts | No | What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| sort | No | Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; search/11: found without the request's payment, key, price and speed wording, such as "pay per call with USDC", unless nothing else names a place; search/12: of places named by the same words in another order, such as speech to text and text to speech, the one whose name the request has in order), and among them those breaking fewer of the conditions read from the request, then, when no covers filter names a place, those whose own text does not limit them to particular places (search/10: a stated country or region and not worldwide comes later; nothing is hidden), then those meeting more conditions (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last. | |
| tier | No | ||
| type | No | ||
| limit | No | Default 10, maximum 25. | |
| query | No | Text search (search/13) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as "pay per call" or "$0.01 a request") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); "an API key is fine" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'. | |
| scope | No | directory (default): services that meet the listing criteria (https://agentservicedirectory.com/methodology#directory); index: everything we watch. | |
| access | No | What the service asks of a caller (access/1): 'payment' (our plain request got HTTP 402), 'credentials' (HTTP 401, or its agent card or MCP Registry entry says so) or 'none_asked' (answered without asking for either, and nothing stated says credentials are needed). Services with no value are left out. | |
| branch | No | Capability tree id from get_tree, e.g. 'messaging/email/validation', 'places/weather' or 'places' (a node includes everything under it), or 'other'. Up to three ids separated by commas list services in any of them. | |
| covers | No | A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). | |
| format | No | A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| offset | No | ||
| network | No | Payment network, e.g. 'eip155:8453' (Base) or 'solana'. | |
| passing | No | true: latest check passed. | |
| audience | No | Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). | |
| currency | No | ISO 4217 code (USD so far): services whose payment terms, seen in their own HTTP 402 answers to our checks, are in this currency; a stablecoin counts as the currency it tracks (USDC as USD). Services whose currency we have not observed are left out. | |
| delivery | No | How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| language | No | A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| provider | No | Only endpoints from this provider (registrable domain, e.g. 'example.com'), as given in a result's provider field. | |
| freshness | No | How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| max_p95_ms | No | Over the last 30 days of our checks (response-times/1, measured from eastern North America; one operation per service, timeouts counted at the time limit); services with too few checks for the figure are left out. Maximum 95th-percentile response time in milliseconds. | |
| min_checks | No | Minimum checks in the last 30 days, to avoid judging on one check. | |
| min_payers | No | Minimum unique payers in 30 days, as reported by the registry. | |
| data_stored | No | Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| processed_in | No | A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). | |
| max_median_ms | No | Over the last 30 days of our checks (response-times/1, measured from eastern North America; one operation per service, timeouts counted at the time limit); services with too few checks for the figure are left out. Maximum median response time in milliseconds. | |
| max_price_usd | No | Maximum price per call in USD stablecoin, where the price is known. | |
| min_pass_rate | No | Share of checks passed in the last 30 days, 0 to 1. | |
| payment_model | No | 'per_call': it asked for payment for our request (HTTP 402). Services whose payment model is not known are left out. | |
| payment_method | No | A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now. | |
| one_per_provider | No | Return one endpoint per provider (registrable domain): the first under the chosen sort (by default, the evidence order: the share of checks passed, then how long we have watched it). | |
| max_terms_changes_90d | No | Only services whose observed x402 payment terms changed at most this many times in the last 90 days (0 = unchanged). Short histories are labelled limited. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-schema behavior: results are compact, limit maxes at 25, and use limit/offset to page, plus the explicit hand-off to get_service. It doesn't describe the result shape beyond 'compact', but with no output schema that gap is modest.
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?
Four front-loaded sentences: purpose and result kinds first, then search modes and filters, then the get_service hand-off, then paging. Efficient and appropriately sized for a 33-parameter tool, with no repetition of the verbose schema text.
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 33-parameter search tool with no output schema, the description covers purpose, search modes, key filters, and paging, which is the minimum viable set. It says only 'results are compact' about the return payload and never explains the ranking/evidence semantics that dominate the sort/query params, leaving that entirely to 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?
Schema description coverage is 91%, so the schema already carries nearly all parameter meaning, including the very detailed sort/query/access docs. The description only synthesizes the main filter axes (type, access, price, evidence) and the two search modes; it adds orientation but little that isn't in the schema. Baseline 3 applies.
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 ('Find services an agent can use') and enumerates the result kinds: remote/local MCP servers, x402/MPP APIs, A2A agents, task marketplaces. It also names the follow-up sibling get_service for connection details, so the tool is distinguishable from its siblings 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?
Gives clear selection guidance: search by 'query' words or by 'branch' capability node, filter on type/access/max_price_usd/evidence, then call get_service for details. It doesn't state explicit exclusions ('do not use when...') or contrast with get_tree/get_stats, which keeps it 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.
Tell us what is missing or wrong: a service or kind of service we don't list, a metric you need, a feature, wrong data or unclear docs. No key needed. We use it to decide where to look next; counts by kind are public on the roadmap, the messages are not. Never include task data, secrets or personal information.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| note | No | What you needed or what is wrong, in a sentence or two. | |
| about | No | A service id, host, or the kind of service, e.g. 'marine weather forecasts'. | |
| contact | No | Only if you want a reply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses genuinely useful behavior: no auth required, that counts by kind become public on the roadmap while messages stay private, and that sensitive data must never be included. This data-handling and visibility disclosure is real added value, though it says nothing about what a call returns or error 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?
A single tight paragraph: purpose first, then prerequisites, then data-handling caveats. Every sentence carries weight, with only mild redundancy between the enumerated kinds and the chained clauses.
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 4-parameter, one-required submission tool with no output schema, the description covers purpose, prerequisites, acceptable inputs, and privacy constraints. It leaves a small gap on what happens after submission (confirmation/return), but otherwise the agent has enough to call 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 coverage is 75% with self-documenting enum values for 'kind', and the description's category list maps closely to that enum without adding much beyond it. The note/about/contact parameters are explained in the schema itself, so the description neither compensates nor detracts; 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 opening clause states a specific action (submit feedback) and enumerates exactly what qualifies: missing services, metrics, features, wrong data, unclear docs. This is clearly a write/submission tool and cannot be confused with its read-only siblings (get_*, search_services). It stops short of explicitly naming any sibling, so it lands at 4 rather than 5.
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 key needed' and 'we use it to decide where to look next' tell the agent the context and prerequisites for calling it. The list of acceptable feedback kinds implicitly bounds when to use it, but no alternative or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give us the address of a paid API endpoint (one that answers with HTTP 402), a remote MCP server or an A2A agent card that we don't list yet. No key needed. We check it like a service from a registry: one unpaid request per scheduled interval, never a paid call, no tool called. It joins the directory if its checks meet our listing criteria. We keep only the address; returns the service id and page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The full https address, e.g. 'https://api.example.com/v1/forecast'. | |
| kind | No | paid_api, mcp_server or a2a_agent. Left out: worked out from the address. | |
| method | No | For a paid_api called with POST (we send no body). Default GET. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses probing behavior (one unpaid request per scheduled interval), safety constraints (never a paid call, no tool invoked), data retention ('we keep only the address'), and the return value (service id and page). This is consistent with readOnlyHint=false (it creates a directory entry) and idempotentHint=true (duplicate submissions converge on the same listing).
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 accepted inputs are front-loaded and every clause carries information (coverage policy, no-cost guarantee, retention, return value). Slightly compressed phrasing ('we check it like a service from a registry') costs a little readability but no waste.
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 three-parameter mutation tool with no output schema, the description supplies the missing return contract (service id and page), the acceptance criteria gating listing, and the no-cost guarantee. Nothing needed to call it correctly 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 description coverage is 100% and each parameter already carries an explanation, so the baseline is 3. The description corroborates that a bare address suffices and that 'no key needed', but adds no syntax or format detail 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?
Uses a specific verb ('submit') plus the exact resource types accepted (paid API endpoint answering HTTP 402, remote MCP server, A2A agent card) and scopes it to entries not yet listed. An agent can distinguish this from search_services/get_service without opening a 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?
The phrase 'that we don't list yet' clearly establishes the submission context, and 'no key needed' removes a common pre-flight question. It does not explicitly name search_services as the check-first alternative, so the when-not is implied rather than stated.
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.
search_services1 field changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/13) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/13) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."submit_servicesearch_services1 field changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/12) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/13) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."search_services10 fields changedInput schema / properties / acts / descriptionPrevious value: -"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / audience / descriptionPrevious value: -"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5)."Input schema / properties / covers / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4)."New value: +"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5)."Input schema / properties / data_stored / descriptionPrevious value: -"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / delivery / descriptionPrevious value: -"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / format / descriptionPrevious value: -"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / freshness / descriptionPrevious value: -"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / language / descriptionPrevious value: -"A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / payment_method / descriptionPrevious value: -"A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / processed_in / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4)."New value: +"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/5)."search_services2 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/11) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/12) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; search/11: found without the request's payment, key, price and speed wording, such as \"pay per call with USDC\", unless nothing else names a place), and among them those breaking fewer of the conditions read from the request, then, when no covers filter names a place, those whose own text does not limit them to particular places (search/10: a stated country or region and not worldwide comes later; nothing is hidden), then those meeting more conditions (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; search/11: found without the request's payment, key, price and speed wording, such as \"pay per call with USDC\", unless nothing else names a place; search/12: of places named by the same words in another order, such as speech to text and text to speech, the one whose name the request has in order), and among them those breaking fewer of the conditions read from the request, then, when no covers filter names a place, those whose own text does not limit them to particular places (search/10: a stated country or region and not worldwide comes later; nothing is hidden), then those meeting more conditions (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services2 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/10) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/11) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those breaking fewer of the conditions read from the request, then, when no covers filter names a place, those whose own text does not limit them to particular places (search/10: a stated country or region and not worldwide comes later; nothing is hidden), then those meeting more conditions (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; search/11: found without the request's payment, key, price and speed wording, such as \"pay per call with USDC\", unless nothing else names a place), and among them those breaking fewer of the conditions read from the request, then, when no covers filter names a place, those whose own text does not limit them to particular places (search/10: a stated country or region and not worldwide comes later; nothing is hidden), then those meeting more conditions (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services10 fields changedInput schema / properties / acts / descriptionPrevious value: -"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / audience / descriptionPrevious value: -"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / covers / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4)."Input schema / properties / data_stored / descriptionPrevious value: -"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / delivery / descriptionPrevious value: -"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / format / descriptionPrevious value: -"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / freshness / descriptionPrevious value: -"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / language / descriptionPrevious value: -"A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / payment_method / descriptionPrevious value: -"A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / processed_in / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."New value: +"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/4)."search_services10 fields changedInput schema / properties / acts / descriptionPrevious value: -"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / audience / descriptionPrevious value: -"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / covers / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / data_stored / descriptionPrevious value: -"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / delivery / descriptionPrevious value: -"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / format / descriptionPrevious value: -"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / freshness / descriptionPrevious value: -"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / language / descriptionPrevious value: -"A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / payment_method / descriptionPrevious value: -"A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."Input schema / properties / processed_in / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."New value: +"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/3). Not shown yet: this kind has not passed our checks, so the filter matches no service for now."search_services10 fields changedInput schema / properties / acts / descriptionPrevious value: -"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / audience / descriptionPrevious value: -"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / covers / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / data_stored / descriptionPrevious value: -"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / delivery / descriptionPrevious value: -"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / format / descriptionPrevious value: -"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / freshness / descriptionPrevious value: -"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."Input schema / properties / languageAdded value: +{
+ "description": "A language (ISO 639-1, e.g. de) the service's own text says its content or output is in. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / payment_methodAdded value: +{
+ "description": "A way to pay the service's own text names. Payment protocols (x402, MPP, L402) are observed from payment requests: see access.observed. Values: card, bank, invoice, crypto, stablecoin, paypal. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / processed_in / descriptionPrevious value: -"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1)."New value: +"A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/2)."search_services2 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/9) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/10) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those breaking fewer of the conditions read from the request, then those meeting more (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those breaking fewer of the conditions read from the request, then, when no covers filter names a place, those whose own text does not limit them to particular places (search/10: a stated country or region and not worldwide comes later; nothing is hidden), then those meeting more conditions (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services8 fields changedInput schema / properties / actsAdded value: +{
+ "description": "What the service's own text says it does in the world when called: read_only, or what it changes. Values: read_only, sends_messages, spends_money, books_or_orders, writes_data, deletes_data, posts_publicly, controls_devices. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / audienceAdded value: +{
+ "description": "Who the service's own text says it is for. Values: consumers, businesses, developers, agents. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / coversAdded value: +{
+ "description": "A country (ISO 3166-1 alpha-2, e.g. AT) the service's own text says its data or job is about; a service that states a region including it (EU, Europe) or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / data_storedAdded value: +{
+ "description": "Whether the service's own text says it keeps or logs what callers send. Values: true, false. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / deliveryAdded value: +{
+ "description": "How the service's own text says results come back. Values: sync, async, webhook, streaming, batch. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / formatAdded value: +{
+ "description": "A format the service's own text names for what it returns. Values: json, csv, xml, pdf, html, text, markdown, image, audio, video, geojson. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / freshnessAdded value: +{
+ "description": "How current the service's own text says its data is. Values: live, hourly, daily, weekly, periodic, static. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}Input schema / properties / processed_inAdded value: +{
+ "description": "A country (ISO 3166-1 alpha-2) where the service's own text says it processes or stores data; a stated region including it or worldwide matches too. Comma-separated values are alternatives. Strict: services whose own text states nothing on this are left out (stated-facts/1).",
+ "maxLength": 80,
+ "type": "string"
+}search_services1 field changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/7) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/9) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, no, key, ..., and the words of a payment phrase such as \"pay per call\" or \"$0.01 a request\") are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."search_services2 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/8) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/7) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; search/8: for a word at least 5 confirmed-placed services use, by how those services are spread across the tree, so a word used all over the tree weighs little and a word one place's services use names that place), and among them those breaking fewer of the conditions read from the request, then those meeting more (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those breaking fewer of the conditions read from the request, then those meeting more (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services2 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/7) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/8) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those breaking fewer of the conditions read from the request, then those meeting more (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; search/8: for a word at least 5 confirmed-placed services use, by how those services are spread across the tree, so a word used all over the tree weighs little and a word one place's services use names that place), and among them those breaking fewer of the conditions read from the request, then those meeting more (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services2 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/6) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/6): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. Services meeting more of the conditions read come first; query_conditions in the response says which were read and from which words, and a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."New value: +"Text search (search/7) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/7): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. For each service a condition is met by our observation, met by a statement (the operator's, a registry's, an OpenAPI description's), not known, or broken (observed or stated against it): services breaking fewer come first, then those meeting more, an observation counting twice a statement; one not known ranks below one met and above one broken. A condition in the same clause as preferably, ideally, if possible or would be nice is a preference: it orders only among services otherwise level. query_conditions in the response says which were read, from which words, and which are preferences; a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those meeting more of the conditions read from the request (search/6: pay per call, no API key, MCP, a price limit; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those breaking fewer of the conditions read from the request, then those meeting more (search/7: pay per call, no API key, MCP, a price limit; an observation counts twice a statement; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those meeting more of the preferences read, then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services1 field changedInput schema / properties / currencyAdded value: +{
+ "description": "ISO 4217 code (USD so far): services whose payment terms, seen in their own HTTP 402 answers to our checks, are in this currency; a stablecoin counts as the currency it tracks (USDC as USD). Services whose currency we have not observed are left out.",
+ "maxLength": 3,
+ "type": "string"
+}search_services3 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/5) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. E.g. 'weather' or 'translate'."New value: +"Text search (search/6) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. Conditions read from the request (search/6): a fixed table turns phrases into conditions that rank, never filter. Pay per call, per request, x402, MPP, L402, USDC, no account or no signup: asks for payment. No API key, without a key, no auth, keyless, no sign-in: does not ask for credentials (observed or stated); \"an API key is fine\" lifts it. MCP: an MCP server (remote, hosted or endpoint: a remote one; local, install or package: a local one). A2A or agent card: an A2A agent. Under, below, at most $X, or a cent or less: a price per call at or below X. Fastest or low latency: faster first. Services meeting more of the conditions read come first; query_conditions in the response says which were read and from which words, and a filter given explicitly always wins. E.g. 'weather', or 'send an SMS, pay per call, no account'."Input schema / properties / query / maxLengthPrevious value: -100New value: +300Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; places matching at least half the query's words, best first), then services matching more of the query's words (and, among those matching as many, the rarer words), then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it), and among them those meeting more of the conditions read from the request (search/6: pay per call, no API key, MCP, a price limit; see query_conditions), then the better-matched place, then services matching more of the query's words (and, among those matching as many, the rarer words), then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."search_services3 fields changedInput schema / properties / query / descriptionPrevious value: -"Text search (search/4) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two); more matched words rank first, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. E.g. 'weather' or 'translate'."New value: +"Text search (search/5) over names, hosts, URLs, operator names, the tool names an MCP server lists, and the name of a service's place in the capability tree when that place passed our three placement checks. Write it as words or a sentence: words about payment or shape rather than purpose (mcp, api, pay, per, call, no, key, ...) are set aside and numbers left out (use the filters for those), and the response's query_words says which words were used. A service matches at least half the words (one of one or two). Services in a place the query names (by the place's name, description or the words agents use for it) rank first; then more matched words, then words found at the start of a word (send in 'Send Email' before send inside 'Godsend'), then the rarer words. A word of three or more characters matches the start of a word, or anywhere inside a name, host or operator word; one of seven or more also matches by its first five characters; a shorter word matches a whole word. E.g. 'weather' or 'translate'."Input schema / properties / sort / descriptionPrevious value: -"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services matching more of the query's words (and, among those matching as many, the rarer words), then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."New value: +"Default: relevance when query is given, otherwise evidence. relevance (the default when q is given): first services in a place the query names (search/5, by the place's name, description or the words agents use for it; places matching at least half the query's words, best first), then services matching more of the query's words (and, among those matching as many, the rarer words), then those whose provider's domain starts with the first word used (its own site: q=stripe puts stripe.com first), then those whose name is, starts with or contains the words used, then the rest; within each group, the evidence order (evidence/2). evidence (evidence/2, the default without q): first services with at least 5 checks in 30 days, then by the share of those checks passed, then by how long we have watched them (longest first), then by payers as the registry reports them, as a tiebreak only. provider-mix/1: in every sort but name and recent, each provider's results after its first three come after every other provider's first three, so one provider cannot fill a page; provider= (or host=) lists one provider's services in plain order, and group=provider gives one per provider. median_ms and p95_ms: fastest first over 30 days, services without the figure last."Input schema / properties / type / enumPrevious value: -[
- "api_endpoint",
- "task_marketplace",
- "mcp_server",
- "mcp_local",
- "a2a_agent"
-]New value: +[
+ "api_endpoint",
+ "task_marketplace",
+ "mcp_server",
+ "mcp_local",
+ "a2a_agent",
+ "web_api"
+]Agent Embassy. https://aemb.pro Agents pay for work and prove what happened.
Check an agent's INAM reputation before trusting it, and sign a receipt when work is done.
Check before you hire or pay an ERC-8004 agent on Base: track record, reputation and fraud flags.
Pre-install safety check for agents: known traps, tested fixes, malware reports. No account.
Add one secure layer between your agents and this server.
