Directory of APIs, merchants, and tools AI agents can actually use.
Scored across 7 tools
Each tool targets a distinct resource: check_site analyzes external sites, get_featured returns ads, get_protocol_stats covers protocols, get_service is a single-slug lookup, list_categories and search_services handle browsing, and submit_service handles publishing. The only mild overlap is get_featured vs search_services (both return service listings), but descriptions clarify the ads distinction.
All names use a consistent snake_case verb_noun pattern (check_site, get_featured, get_protocol_stats, get_service, list_categories, search_services, submit_service). Verbs are chosen predictably for their action type.
Seven tools is well-scoped for a directory/discovery server, covering browsing, lookup, stats, submission, plus one bonus site-analysis tool. Nothing feels padded or missing at the count level.
Covers discovery (list_categories, search_services, get_service), metadata (get_protocol_stats, get_featured), and submission (submit_service), plus a unique check_site diagnostic. However, there is no way to update, edit, or delete an existing listing, which are plausible lifecycle gaps.
Score how bot-friendly a website is (0-100). Fetches the site the way an agent would — no JavaScript, no cookies — and checks access (reachability, HTTPS, robots.txt, AI crawlers allowed, real 404s), content without JavaScript (H1, 500+ chars of raw text, metadata, JSON-LD), and machine discovery (llms.txt, sitemap, OpenAPI spec or ai-plugin.json), with evidence and fix advice per check. Set format to 'prompt' to instead get a ready-to-paste coding-agent prompt that fixes every failed finding. Rate limited to 6 checks per minute per caller; each check takes a few seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Site to check (scheme optional, https assumed; public sites only) | |
| format | No | json (default) returns the full scored report; prompt returns a markdown prompt for a coding agent covering every failed or partial finding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and it discloses key operational traits: it fetches without JavaScript or cookies, is rate-limited to 6 checks per minute, each check takes a few seconds, and can return either a scored report or a readiness prompt. It also promises evidence and fix advice per check, making outputs and side effects predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place: it covers purpose, how the site is fetched, what is evalued, what the output includes, the alternative format, and operational limits. It front-loads the core action and avoids filler.
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 and no annotations, the description covers the essentials: input restrictions, the full set of checks, scoring scale, evidence/fix output, the prompt alternative, and rate limits. An agent can correctly decide whether to call the tool and can plan for latency and throughput.
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%; both parameters already have meaningful descriptions in the input schema, including 'scheme optional, https assumed' and the json/prompt enum behavior. The description reinforces the prompt formatting mode but does not add new parameter-level detail beyond what the schema provides.
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 opens with a specific verb and measurable outcome ('Score how bot-friendly a website is (0-100)') and then enumerates the exact checks performed, making it unmistakable from sibling catalog/service tools. It names concrete resources such as robots.txt, llms.txt, sitemap, and OpenAPI, so an agent knows precisely what is evaluated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool as a bot-access audit and explains the format='prompt' conditional, which gives the agent context for choosing a mode. It does not explicitly name when-not-to-use or an alternative tool, but the sibling tools are unrelated, so the omission is minor and the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get site-wide featured/promoted services (max 3). These are paid placements clearly marked as ads.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the max-3 cap and that results are paid placements marked as ads, which is material for an agent deciding whether to surface them. It does not cover return format or error behavior, but for a simple zero-parameter read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler: the core action and limit come first, followed by a clarifying disclosure about the ad nature. Every clause earns its place and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation, simple list tool, the description is complete: it tells the agent what is returned (featured services), the scope (site-wide), the count cap (max 3), and the key semantic detail (paid placements marked as ads). No essential information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already fully covers everything and the baseline is 4. The description adds useful context about scope and result nature (site-wide, max 3, paid ads), which reinforces what an agent should expect without needing parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieve site-wide featured/promoted services. The qualifiers 'site-wide' and 'max 3' clearly differentiate it from siblings like get_service (single service) and search_services (search all), so an agent can select it without ambiguity.
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 context of paid placements and the max-3 limit implies when to call it (when the agent needs featured/promoted services), but it does not explicitly say when to prefer an alternative or mention exclusion criteria. It gives enough context to infer usage, though without direct alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get every protocol on botfriendly.xyz/protocols with adoption stats: how agents call a service and prove who sent them (MCP, OpenAPI, A2A, XAA) and the agent payment, authorization, and commerce protocols (x402, mpp, l402, ap2, tap, agent-pay, ace, acp, ucp, actp, icc). Each entry carries its sponsor, layer, spec URL, and count — how many listed services support it, or null for protocols that aren't a listing attribute (A2A, XAA).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden, and it does disclose meaningful return semantics that nothing else would: entries carry sponsor/layer/spec URL, and count is null for protocols that aren't a listing attribute (A2A, XAA). It does not mention auth requirements, rate limits, or result size, but for a zero-parameter read-only getter the disclosure of return shape and null semantics is solid.
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 verb and resource, and two sentences cover both the protocol set and the entry shape. The long parenthetical acronym list (MCP, OpenAPI, A2A, XAA / x402, mpp, l402, ...) is dense but genuinely informs the agent what 'protocol' means here, so it mostly earns its space.
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 must describe returns, and it does: the entry fields, the count field's meaning, and the null case. For a parameterless read tool with no annotations this is close to complete, though pagination/size or auth context would seal it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so per the rubric the baseline is 4 and there is no argument semantics the description needs to compensate for. Nothing in the description misleads about inputs.
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 every protocol on botfriendly.xyz/protocols with adoption stats') and enumerates exactly what a protocol entry contains: sponsor, layer, spec URL, and count. The subject matter is narrow and clearly disjoint from siblings like get_service or list_categories, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool returns but never says when to call it, when not to, or what the alternative would be. There is no guidance such as 'use this instead of get_service when you need protocol-level adoption data,' leaving selection entirely to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific service by its slug, including all protocol support, URLs, auth method, billing, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Service slug (e.g. browserbase, anthropic-claude-api, firecrawl) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does disclose that the tool returns details such as protocol support, URLs, auth method, billing, and metadata, which conveys a read-only lookup. However, it does not address error behavior, not-found cases, rate limits, or any authentication requirements for calling the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the core purpose and then lists the useful output categories. Every clause earns its place, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup with no output schema, the description provides a solid summary of what will be returned and when to use the tool. It could be slightly more complete by noting the exact response shape or what happens when a slug does not exist, but the essential information for selecting and invoking the tool is 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 100%, and the single slug parameter is already well-documented with examples in the schema. The description only adds that lookup is by slug, which adds marginal value beyond the structured input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full details for a specific service by slug, listing the included information types. This distinguishes it from siblings like search_services (searching) and list_categories (listing), making the tool's purpose unambiguous.
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 clear context: use this tool when you already have a specific service slug and need complete details. It does not explicitly name alternatives or exclusion criteria, but the 'by its slug' phrasing implies it is not for discovery or searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every BotFriendly category with its id (the search_services category value), human label, aliases (older slugs still accepted), description and service count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses all returned fields and adds meaningful nuance by explaining that aliases are older slugs still accepted, which clarifies legacy input behavior. It does not mention ordering, pagination, or auth, but for a simple list operation the behavioral portrait is quite complete.
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 dense sentence with no wasted words. The action and resource are front-loaded, and the field list is efficient while still adding important context about aliases and the search_services relationship.
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 listing with no output schema, the description provides enough to know what data will come back. The exact return structure (array of objects) and ordering are not stated, but they are reasonably inferable from 'List every ... with its ...'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description adds no parameter-specific detail because there are none; it correctly focuses on the output shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('every BotFriendly category'), and enumerates exactly what is returned: id, human label, aliases, description, and service count. It also ties the id to the sibling search_services category value, helping distinguish this tool from the service-level siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the place to get the category values used by search_services, giving an agent context for when to call it. It does not explicitly name alternatives or state when not to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the BotFriendly directory for bot-friendly services, APIs, and tools that AI agents can use. Filter by category, payment/commerce protocol support (x402, MPP, L402, AP2, TAP, Agent Pay, ACE, ACP, UCP, ACTP, ICC), auth method, and more. Results may start with up to 3 promoted listings (paid ads) pinned to the top — site-wide ads on unfiltered searches, category ads on category searches — clearly marked with promoted:true and ad:true. Use promoted=false to exclude ads.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| sort | No | Sort order (default: score) | |
| query | No | Keyword search (Postgres websearch semantics: multiple words are ANDed, so a single distinctive keyword like 'scraping' matches more than a phrase like 'web scraping') | |
| has_mcp | No | Only services with MCP servers | |
| category | No | Category id: think (Models), see (Vision), hear-speak (Speech), create (Media), remember (Memory), search (Search), browse (Browsers), communicate (Messaging), execute (Compute), pay (Payments), shop (Merchants), markets (Markets), platforms (Platforms), identify (Identity), monitor (Observability), other (Other). Merged categories also accept their old slugs (trade, bet, connect, automate, locate, book, sign, hire). | |
| no_human | No | Only services an agent can start using with no human setting up a key: probe-backed — its own (non-documentation) MCP server lists its tools to an unauthenticated client and the service needs no key (no auth, or a wallet), or one of its interfaces answers HTTP 402 to be paid per request | |
| promoted | No | Filter by promoted status: true for promoted only, false for organic only | |
| protocol | No | Only services supporting ALL of these agent payment/commerce protocols. x402 (x402, Coinbase, x402 Foundation); mpp (Machine Payments Protocol, Stripe, Tempo); l402 (L402, Lightning Labs); ap2 (Agent Payments Protocol, Google); tap (Trusted Agent Protocol, Visa); agent-pay (Mastercard Agent Pay, Mastercard); ace (Agentic Commerce Experiences, American Express); acp (Agentic Commerce Protocol, OpenAI, Stripe); ucp (Universal Commerce Protocol, Google, Shopify); actp (Agentic Commerce Trust Protocol, Alibaba, Ant International); icc (Intelligent Commerce Connect, Visa) | |
| min_score | No | Minimum bot-friendly score (1-5) | |
| accepts_mpp | No | Only services accepting MPP payments | |
| auth_method | No | Filter by auth method | |
| accepts_x402 | No | Only services accepting x402 payments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses a genuinely non-obvious behavior: up to 3 paid promoted listings are pinned to the top and flagged with promoted:true/ad:true, with special rules for unfiltered vs category searches. It omits rate limits, auth requirements, and pagination/result-size 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?
Four sentences, front-loaded with the core purpose and filtering capability. Every sentence contributes (scope, filters, ad disclosure, ad exclusion), though the protocol acronym list in the description partially duplicates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, no-output-schema, no-annotation search tool, the description covers scope, filter dimensions, and the important ad-injection behavior plus its result markers. It could say more about result shape/pagination, but the critical selection cues are 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 description coverage is 100%, so the schema already documents all 12 parameters (including protocol meanings and query semantics). The description adds only marginal guidance on the promoted filter, so the baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (the BotFriendly directory of bot-friendly services, APIs, and tools) with clear scope. It is readily distinguishable from sibling tools like get_service (single lookup) and submit_service (write).
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 enumerates available filter dimensions and gives one actionable instruction ('Use promoted=false to exclude ads'), which implies how to use the tool. However, it never states when to reach for this tool versus siblings such as get_service or get_featured, and gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a service to the BotFriendly directory. There is no review queue: each interface URL must be on the service's own domain, or linked from the service's own site, and is fetched during the call; the listing publishes immediately if its MCP server, OpenAPI spec or API completes a handshake — one of has_mcp_server, has_openapi_spec or has_api is required; llms.txt, skill files and feeds only add badges. The url must be the product, not an article (/blog/, /news/ and similar are rejected), and a domain can add at most 2 listings a day and 3 in total. Every listing needs an icon — pass icon_url, or leave it out and the service's own site is checked for one.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Service URL | |
| name | Yes | Service name | |
| tags | No | ||
| api_url | No | Required when has_api is true: the API's base URL (api.example.com, or a path under /api or /v1). It must answer in JSON. On the service's own domain, or linked from its site. | |
| has_api | No | ||
| category | Yes | Category id (see list_categories) | |
| icon_url | No | Link to the service's icon (PNG, JPEG, SVG or WebP, under 1MB). Fetched and re-hosted, downscaled to 512px. Omit it and the service's site is checked for one. | |
| accepts_mpp | No | ||
| auth_method | No | Auth method | |
| description | Yes | Short description (max 120 chars) | |
| icon_base64 | No | Alternative to icon_url: the image inline, as a data: URI or bare base64. | |
| accepts_x402 | No | ||
| billing_model | No | ||
| contact_email | No | Contact email for verification | |
| has_mcp_server | No | ||
| mcp_server_url | No | Required when has_mcp_server is true. On the service's own domain, or linked from its site. | |
| has_openapi_spec | No | ||
| openapi_spec_url | No | Required when has_openapi_spec is true. On the service's own domain, or linked from its site. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: no review queue, immediate publication on handshake completion, URLs fetched during the call, own-domain/linked-from-site constraints, and explicit rate limits (2/day, 3 total per domain). It also discloses rejection rules for article-like paths and the icon fallback behavior — unusually complete for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then packs validation rules, requirements and limits into one dense paragraph with essentially no filler. It would read better as short bullets given the number of distinct constraints, but every sentence carries information.
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 an 18-parameter submission tool with no annotations and no output schema, the description covers the rules an agent needs to construct a valid call: required capability flag, URL legitimacy, domain limits and icon handling. It stops short of describing failure modes or the response after a rejected/held submission, but the essential pre-call knowledge is 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 61%, above the baseline threshold, and the description adds real meaning on the parameters that matter: the url must be the product not an article, the three capability booleans gate listing success, api_url must answer JSON, and icon_url vs omission triggers a site lookup. Secondary fields (tags, accepts_mpp, accepts_x402, billing_model, auth_method, contact_email) are left to 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?
Opens with a specific verb+resource ('Submit a service to the BotFriendly directory') and immediately scopes it to a directory-listing write action, which is clearly distinct from read-oriented siblings like get_service, search_services and list_categories. No sibling does submission, and the description makes the tool's identity unmistakable.
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 rich conditional guidance: at least one of has_mcp_server/has_openapi_spec/has_api is required, api_url/mcp_server_url/openapi_spec_url become mandatory with the corresponding boolean, and icon_url may be omitted. It does not name a competing sibling or an explicit 'use this instead of X' routing, but no sibling overlaps, so the omission is minor.
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 / no_humanAdded value: +{
+ "description": "Only services an agent can start using with no human setting up a key: probe-backed — its own (non-documentation) MCP server lists its tools to an unauthenticated client and the service needs no key (no auth, or a wallet), or one of its interfaces answers HTTP 402 to be paid per request",
+ "type": "boolean"
+}submit_service4 fields changedInput schema / properties / api_urlAdded value: +{
+ "description": "Required when has_api is true: the API's base URL (api.example.com, or a path under /api or /v1). It must answer in JSON. On the service's own domain, or linked from its site.",
+ "type": "string"
+}Input schema / properties / has_apiAdded value: +{
+ "type": "boolean"
+}Input schema / properties / mcp_server_url / descriptionPrevious value: -"Required when has_mcp_server is true, and must be on the service's own domain."New value: +"Required when has_mcp_server is true. On the service's own domain, or linked from its site."Input schema / properties / openapi_spec_url / descriptionPrevious value: -"Required when has_openapi_spec is true, and must be on the service's own domain."New value: +"Required when has_openapi_spec is true. On the service's own domain, or linked from its site."search_services2 fields changedInput schema / properties / category / descriptionPrevious value: -"Category slug: think, see, hear-speak, create, remember, search, locate, browse, communicate, execute, pay, shop, book, hire, trade, bet, sign, identify, connect, automate, monitor, other"New value: +"Category id: think (Models), see (Vision), hear-speak (Speech), create (Media), remember (Memory), search (Search), browse (Browsers), communicate (Messaging), execute (Compute), pay (Payments), shop (Merchants), markets (Markets), platforms (Platforms), identify (Identity), monitor (Observability), other (Other). Merged categories also accept their old slugs (trade, bet, connect, automate, locate, book, sign, hire)."Input schema / properties / category / enumPrevious value: -[
- "think",
- "see",
- "hear-speak",
- "create",
- "remember",
- "search",
- "locate",
- "browse",
- "communicate",
- "execute",
- "pay",
- "shop",
- "book",
- "hire",
- "trade",
- "bet",
- "sign",
- "identify",
- "connect",
- "automate",
- "monitor",
- "other"
-]New value: +[
+ "think",
+ "see",
+ "hear-speak",
+ "create",
+ "remember",
+ "search",
+ "browse",
+ "communicate",
+ "execute",
+ "pay",
+ "shop",
+ "markets",
+ "platforms",
+ "identify",
+ "monitor",
+ "other",
+ "locate",
+ "book",
+ "hire",
+ "sign",
+ "trade",
+ "bet",
+ "connect",
+ "automate"
+]submit_service2 fields changedInput schema / properties / category / descriptionPrevious value: -"Category slug"New value: +"Category id (see list_categories)"Input schema / properties / category / enumAdded value: +[
+ "think",
+ "see",
+ "hear-speak",
+ "create",
+ "remember",
+ "search",
+ "browse",
+ "communicate",
+ "execute",
+ "pay",
+ "shop",
+ "markets",
+ "platforms",
+ "identify",
+ "monitor",
+ "other",
+ "locate",
+ "book",
+ "hire",
+ "sign",
+ "trade",
+ "bet",
+ "connect",
+ "automate"
+]check_siteget_featuredget_protocol_statsget_servicelist_categoriessearch_servicessubmit_serviceVerified, pay-per-use API tools for AI agents through one authenticated connection.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
AI service marketplace — agents discover, call, and pay for API services automatically.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Add one secure layer between your agents and this server.
