Curated index of B2B offerings for AI agents: fit, non-fit, limits, sourced claims.
Scored across 10 tools
The set separates offering discovery (discover/search/evaluate), record retrieval (get_offering), and listing lifecycle actions (request, verify, status, update, approve, remove). The three discovery tools overlap at a high level, but their descriptions make the intended entry point reasonably clear; an agent could still pause between discover_offerings and search_offerings.
All names use snake_case and follow a predictable verb-object pattern tied to the action or resource (approve_listing, search_offerings, get_offering). No mixed conventions appear; request_listing_removal is longer but still consistent with the pattern.
Ten tools is within a well-scoped range for an index with both buyer-facing discovery and supplier-facing listing workflows. Discovery/evaluation and listing lifecycle each have a small coherent set, with no obvious filler tools.
The set covers offering discovery, evaluation, retrieval, and the full listing lifecycle from request through verification, status, updates, approval, and removal. Minor gaps remain, such as no dedicated comparison tool or company-level profile lookup beyond individual offerings, but agents can work around these with existing calls.
Approve publication of the exact draft revision on behalf of the company and accept the Listing Terms (LT-2, https://agentcompanyindex.com/legal/listing-terms/lt-2) for it. Requires a verified domain. Before calling: show the user the draft, then the listing_terms summary and link from get_listing_status, and ask whether they may act for the company, approve this exact revision and accept the Listing Terms on the company's behalf. Call only after an explicit yes from that person; never on your own. Pass the approver's full name, role and the company's legal name. When the domain was confirmed with a DNS record or a file, also pass approver_email (an address on the company domain the approver reads): ACI mails it a confirmation link and publication waits for it. The approved revision is then published automatically, usually within minutes; the approver gets an email record of the approval and the terms. When the domain was confirmed with the emailed code, ACI sends a free monthly report (which AI assistants and systems retrieved the profile) to that address; set monthly_report to false if the user does not want it. Every report has an unsubscribe link.
| Name | Required | Description | Default |
|---|---|---|---|
| revision | Yes | ||
| reference | Yes | ||
| approver_name | Yes | Full name of the person approving for the company. | |
| approver_role | Yes | ||
| listing_token | Yes | ||
| approver_email | No | Required when the domain was confirmed with a DNS record or a file: an address on the company domain the approver reads. Ignored when the domain was confirmed with the emailed code (that address is recorded). | |
| monthly_report | No | Send the monthly report to the confirmed work address (default true). | |
| schema_version | Yes | ||
| user_confirmation | No | Optional: the user's reply agreeing to approve and to the Listing Terms, quoted word for word. | |
| company_legal_name | Yes | The company's legal name (e.g. from its imprint), the party accepting the Listing Terms. | |
| accept_listing_terms | Yes | Set to "LT-2" only after the user explicitly accepted the Listing Terms (https://agentcompanyindex.com/legal/listing-terms/lt-2) on behalf of the company. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint, idempotentHint, openWorldHint) it discloses the domain-verification prerequisite, the conditional approver_email requirement when verification used DNS/file, that publication waits on the emailed confirmation link, that publication follows automatically within minutes, and that approval/report emails are sent. This is materially more than the structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long, but front-loaded with the core action and legal acceptance before the procedural guidance, and nearly every sentence carries a distinct constraint (verified domain, explicit consent, email confirmation, report opt-out). The paragraph form is dense; a short break between consent flow and post-call behavior would aid scanning.
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 11-parameter, destructive, open-world tool with no output schema, the description covers preconditions, consent requirements, conditional parameters, and post-call outcomes (automatic publication, confirmation email, monthly report). An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 55%, and the description compensates: it explains the approver_email condition (required for DNS/file verification, ignored for emailed-code verification), the monthly_report toggle and its unsubscribe link, and which identity fields to supply (full name, role, legal name). It says nothing about revision, reference, listing_token or schema_version, but those are largely self-evident or schema-constrained.
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 precise verb and object — approve publication of the exact draft revision and accept Listing Terms LT-2 — with the scope ('the exact draft revision') that separates it from get_listing_status, request_listing and update_listing_answers. An agent can identify the action without opening the 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 explicit preconditions and sequencing: requires a verified domain, show the user the draft and the listing_terms summary/link, confirm authority to act for the company, and call only after an explicit yes — 'never on your own.' It also names which fields to pass, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse every published offering in the Agent Company Index (B2B software and services, sourced facts, explicit limitations), in stable alphabetical order. Prefer search_offerings when the user describes a need; use this to page through the whole index.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description adds a real behavioral trait beyond structured data: stable alphabetical ordering, which tells the agent pagination is deterministic. It doesn't address rate limits or page-size behavior, keeping it short of a 5.
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, zero filler, with the scope statement front-loaded and the alternative-routing sentence last. 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, so the description could have described the return shape (items plus next cursor) but does not. Combined with 0% parameter coverage, an agent knows what the tool is for but not how to iterate pages correctly. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters and does not. It never explains limit bounds, how cursor is obtained/advanced for the next page, or the meaning of the required schema_version constant, even though 'page through the whole index' implies pagination.
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 (browse) and resource (every published offering in the Agent Company Index), plus the data scope (B2B software/services, sourced facts, explicit limitations). An agent can immediately distinguish it from sibling search_offerings and get_offering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'Prefer search_offerings when the user describes a need; use this to page through the whole index.' Names the alternative and the condition selecting each, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a structured buyer situation (category, company size, country, requirements) against every published offering and get each offering's fit or exclusion with reasons, limitations and unknowns. Each result states its group: fit (fit_state strong_contextual_fit), possible fit (possible_fit), insufficient information (insufficient_information) or excluded (eligibility excluded, with the reason). The list is ordered by more documented fit reasons first, then fewer cautions, then fewer unknowns, then offering id; it is not sorted by group, so group the results by those fields when presenting them. Payment, client status and ownership by ACI's operator are not inputs to the order. ACI publishes no scores and no paid positions. Use when the situation maps to the schema categories; for plain-language needs use search_offerings. free_text is accepted but not interpreted: only the structured fields decide fit.
| Name | Required | Description | Default |
|---|---|---|---|
| situation | Yes | The one shape for a matching situation, used both as the POST /api/v1/match request body and, once extracted from free text or guided answers, as the 'interpreted_situation' echoed back in match-response.schema.json. SEARCH_AND_MATCHING.md §2: all fields are optional, but an incomplete situation must be surfaced, not silently assumed. | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantive behavior beyond them: result ordering rules, that the list is not sorted by group, that payment/client status/ownership do not influence order, that no scores or paid positions exist, and that free_text is accepted but not interpreted.
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?
Content is front-loaded: purpose first, then result shape, then ordering, then usage rule. It is dense but nearly every sentence adds operative detail; only minor length in the ordering recital costs it a point.
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 compensates by describing the return payload in detail: fit groups, reasons, limitations, unknowns, and ordering. Combined with the schema's nested situation definition, an agent has enough to call and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description carries extra weight, and it does clarify the key semantic that free_text 'is accepted but not interpreted: only the structured fields decide fit.' It also enumerates the situation dimensions (category, company size, country, requirements), though it does not cover the nested fields like unknown_policy or excluded_conditions.
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 ('check a structured buyer situation ... against every published offering') and names the exact artifact returned ('each offering's fit or exclusion with reasons, limitations and unknowns'). It also names the sibling it is not (search_offerings), so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing rule: 'Use when the situation maps to the schema categories; for plain-language needs use search_offerings.' This gives both the when-to-use condition and the alternative for the other case, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the state of a listing request and what to do next: the domain-proof options, the prepared draft with its revision digest (facts, which of them are company statements, what ACI checked itself, open questions), the Listing Terms the company accepts with its approval (listing_terms: version, url, sha256, summary), or the public URL once published (also while an update of it is being prepared). While ACI itself is working the answer carries poll_after_seconds: wait that long before asking again. Show the user the draft and the Listing Terms summary with its link before asking for approval.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | ||
| listing_token | Yes | ||
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive; the description adds real value beyond that by disclosing the polling contract (poll_after_seconds), the shape of the draft payload including revision digest and what ACI self-verified, and the Listing Terms fields (version, url, sha256). Error states, token expiry, and what happens if the token is stale are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the opening sentence is a long run-on with deeply nested parentheticals that make it hard to scan. The operational instructions in the following sentences are useful and earn their place, but the payload enumeration could be split or trimmed.
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, so the description must describe return values — and it does so thoroughly for four distinct response branches plus the polling field, which is the main risk for an agent here. The gap is on the input side: no explanation of the three required parameters or of failure modes when a token or reference is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across all three required parameters. The description explains the response thoroughly but never defines 'reference' (what entity it identifies, 20-char limit), 'listing_token' (provenance, 200-char limit), or 'schema_version' (a fixed const). With no schema documentation to lean on, this is a material gap for correct invocation.
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 — 'Read the state of a listing request' — and then enumerates the distinct states it can return (domain-proof options, prepared draft with revision digest, Listing Terms, published URL). This lets an agent distinguish it from write-side siblings like approve_listing or update_listing_answers, though no sibling is named explicitly.
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 concrete operational guidance: poll again after poll_after_seconds while ACI is working, and present the draft plus Listing Terms summary/link before requesting approval. It does not explicitly say when to prefer this over siblings such as evaluate_situation or get_offering, so the routing guidance is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full sourced record of one offering by slug: who it is for and not for, limitations, prerequisites, data residency, pricing visibility, contract terms, open questions, the company's relationship to ACI's operator, and a source with checked date for every claim. Use before recommending or comparing a provider.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: every claim carries a source with a checked date, and the record discloses the company's relationship to ACI's operator (a conflict-of-interest signal). It does not cover lookup failure or missing-slug behavior, so it stops short of a 5.
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 verb and resource; the long field enumeration in sentence one is dense but each item is informative for an agent deciding whether this is the right fetch tool. The usage directive is correctly placed at the end as the takeaway.
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?
There is no output schema, so the description carries the burden of describing return content, and it does so thoroughly by listing the record's sections (eligibility, limitations, prerequisites, residency, pricing, contract terms, open questions, operator relationship, sourcing). Combined with annotations covering the safety profile, an agent has everything needed 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 description coverage is 0% for both parameters. The description compensates for 'slug' by saying the record is fetched 'by slug', confirming the identifier role, but says nothing about 'schema_version' or its format/constraint. Baseline 3 is appropriate given the partial compensation.
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 the full sourced record of one offering by slug') and enumerates the record's contents, so an agent knows exactly what it retrieves. It distinguishes itself implicitly from the list-style siblings (search_offerings, discover_offerings) by fetching a single record keyed by slug, but no sibling is named explicitly.
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?
'Use before recommending or comparing a provider' gives a clear positive usage context and a workflow slot. It does not state when not to use it or name an alternative (e.g., search_offerings for lightweight lookups), so the guidance is contextual rather than exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List one offering of the company you act for in the Agent Company Index. Listing is free. Before calling, fill answers from the company's website and ask the user for the rest: what problem the offering solves (primary_problem), who it fits best (positive_fit) and who not (negative_fit), two to four use_cases, the countries it serves (market_country), support_languages and pricing_model. Leave out anything you cannot confirm; unanswered fields stay visible on the profile as open questions. Returns a reference and a private listing token: tell the user to keep both, the token is shown only once. work_email must be an address on the company's own domain that the user reads (info@example.com); a free-mail or other-domain address is refused at once, because the approval is recorded for a mailbox on the domain (a company without one writes to ACI). Domain control: ACI mails that address an 8-digit code that the user gives back to you (verify_listing_domain email_code); where no code can be sent, a DNS TXT record or a file. Show the user the returned option word for word. ACI then drafts the profile from the website in a few minutes (get_listing_status). Once a person who may act for the company approves one exact revision and accepts the Listing Terms (approve_listing), it is published automatically. Payment never changes fit or order.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| answers | No | Optional structured company answers for the draft. Each becomes a company statement on the profile, shown with its date. Unanswered fields stay open questions. | |
| website | Yes | The company's own domain, e.g. example.com. | |
| work_email | Yes | An address on the company's own domain (e.g. info@example.com) that the user can read: ACI mails it a code that confirms the domain without DNS changes. A free-mail address (Gmail, GMX, web.de, Outlook …) or an address on another domain is refused. | |
| schema_version | Yes | ||
| target_customers | Yes | Who it is for and in which countries. | |
| product_or_service | Yes | The one offering to list first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly=false, destructive=false, idempotent=false, openWorld=true) by disclosing non-obvious outcomes: the listing token is shown only once and must be kept, unanswered fields stay visible as open questions, approval triggers automatic publication, and payment never affects fit or order. The domain-control options (code, DNS TXT, file) are also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose and the free-listing fact, and virtually every sentence carries operational value (email rule, token warning, approval flow). It is a dense run-on paragraph, though, and would scan better broken into short grouped lines.
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, yet the description explains the return payload (reference plus private listing token) and the downstream lifecycle, which is what an agent needs. Against a 7-parameter tool with a 25+ property nested answers object, it guides the high-value fields but is not a full field-by-field reference.
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%, so the schema carries much of the load, but the description adds real meaning: which fields to derive from the website vs ask the user (primary_problem, positive_fit, negative_fit, use_cases, market_country, support_languages, pricing_model) and the 'leave out anything you cannot confirm' rule. It does not cover the remaining ~29% of undocumented nested fields such as limitations, prerequisites, or certifications.
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 ('List one offering of the company you act for in the Agent Company Index'), plus the scope constraint (one offering, the company's own). It is immediately distinguishable from siblings like request_listing_removal, update_listing_answers, and approve_listing 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?
Explicitly sequences the workflow: fill what you can from the website, ask the user for the rest, then hand off to verify_listing_domain, get_listing_status, and approve_listing. It also states a hard pre-condition (work_email must be on the company's own domain, free-mail refused) and a fallback (a company without one writes to ACI).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a company from the Agent Company Index on behalf of that company. Give the company's domain and a work email address on exactly that domain (ask the user for it). ACI emails a private confirmation link to that address; once someone there opens it and presses Remove, every published profile of the domain goes offline within a few minutes and the company gets an email. Nothing changes without that confirmation. Profiles under an agreement with ACI's owner are checked by a person first.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The company's own domain, e.g. example.com | |
| work_email | Yes | An address on exactly that domain; the confirmation link goes there. | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true, openWorld=true and idempotent=false, and the description adds substantial context beyond them: a two-step email confirmation gate ('Nothing changes without that confirmation'), the downstream effect (all published profiles go offline within a few minutes plus a company email), and a human-review exception. This is unusually rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action, then the mechanism and its consequences in a logical order. Five sentences, all carrying real information, though the 'ask the user for it' aside and the repetition of the domain constraint are marginally redundant with 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?
No output schema exists, but the description explains the entire lifecycle an agent needs: inputs, the confirmation handshake, the resulting offline timing, the notification email, and the human-review edge case. Nothing material 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?
Schema coverage is 67% and the two functional parameters (domain, work_email) are already documented in the schema, including the 'exactly that domain' constraint. The description reinforces those meanings but adds no new syntax or format guidance, and schema_version remains undocumented in both places. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: 'Remove a company from the Agent Company Index on behalf of that company.' An agent can distinguish this from request_listing, get_listing_status, and approve_listing without opening any sibling 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 operating context (act on the company's behalf, ask the user for domain and work email on exactly that domain) and flags a conditional branch (profiles under an agreement with ACI's owner are checked by a person first). It does not explicitly contrast itself with siblings like request_listing or approve_listing, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when a user is looking for a B2B software product, service provider or agency (e.g. "website maintenance for a small company in Germany", "time tracking with DATEV export") and wants options backed by sourced facts and stated limitations rather than marketing. Plain-language search over the Agent Company Index; returns matching offerings with the terms they matched. Order: offerings matching more of the query's words come first, then by name; offerings matching fewer than half as many words as the best match are left out. Country and language words (e.g. Germany, German) are shown as matched but do not count when the query also names the need. Payment, client status and ownership by ACI's operator are not inputs to the order. ACI publishes no scores and no paid positions. Follow up with get_offering for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | The need in plain words, any language; English matches best. | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds substantial behavior beyond them: ranking order (more matched words first, then name), a cutoff rule dropping offerings matching under half the best match, treatment of country/language words in scoring, and the assurance that payment/ownership play no role. That is exactly the non-obvious ranking and filtering behavior an agent cannot get from structured fields.
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 trigger condition, then behavior, then the follow-up pointer — good ordering. A few clauses (the 'no scores and no paid positions' assurance) are trust-building rather than operational, so it runs slightly long, but every sentence is readable and mostly 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?
With no output schema, the description still describes the return reasonably ('returns matching offerings with the terms they matched') and routes to get_offering for full records. Missing details are the limit default and whether results are paginated or how many are returned by default.
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 only 33%, so the description should carry more weight; it adds real semantics for query (country/language words are matched but not weighted, plain-language phrasing) but says nothing about limit (default value, effect on results) or schema_version. The query guidance is valuable, the remaining parameters are left entirely to the sparse 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 and resource — 'Plain-language search over the Agent Company Index' — and names the follow-up tool get_offering. It does not, however, distinguish itself from the sibling discover_offerings, leaving the agent to infer which search is appropriate.
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 triggering context ('Use when a user is looking for a B2B software product, service provider or agency') with two concrete example queries, which is strong. It stops short of an exclusion rule naming when to prefer discover_offerings or evaluate_situation instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send or correct the company's structured answers (the complete set; it replaces the previous one). Once a draft exists this requests changes: ACI prepares a new revision from the answers within a few minutes, and any earlier approval no longer counts. After publication the same call updates the published profile: ACI reads the website again and prepares a new revision (unchanged answers are fine); the public profile stays as it is until the company approves that revision and it passes the automated check. Put every fact you want changed into answers; a free-text note is kept with the request, is not published and does not change the draft by itself.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| answers | Yes | The complete set of answers; it replaces the previous set. | |
| reference | Yes | ||
| listing_token | Yes | ||
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm destructiveHint=true and idempotentHint=true, and the description substantiates those: it replaces the prior set, an earlier approval 'no longer counts', and the public profile is unaffected until the company approves the new revision and it passes the automated check. It also clarifies that the free-text note is kept but not published and does not change the draft. This is rich lifecycle and side-effect disclosure beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core operation and its replacement semantics are front-loaded in the first sentence, and each subsequent sentence covers a distinct lifecycle stage. Some sentences are long and dense, but the information is non-redundant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, nested-object mutation with no output schema, the description supplies the full draft-vs-published workflow, the replacement behavior, the approval invalidation, and the revision cadence. An agent has everything needed to invoke it correctly without guessing at side effects.
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 only 20%, so many parameters (reference, listing_token, schema_version, and most answer fields) rely on their names alone. The description does add real value for 'answers' (complete set, full replacement) and 'note' (stored with the request, unpublished, does not modify the draft), but it does not compensate for the broad coverage gap across the nested answer object.
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 – sending/correcting the company's structured answers as a complete replacement set – and the parenthetical 'it replaces the previous one' pins down the exact write semantics. An agent can tell this apart from siblings like approve_listing or request_listing without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly delineates the two usage contexts: once a draft exists it requests changes, and after publication the same call updates the published profile while the public profile stays as it is until approval. It explains when each flow applies but never names alternative sibling tools or states when NOT to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prove control of the company domain for a listing request: pass email_code with the code the user received at the company address, or call without it after the DNS TXT record or the /.well-known/aci-verification.txt file is in place.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | ||
| email_code | No | The 8-digit code from the email Agent Company Index sent to the work address on the company domain. | |
| listing_token | Yes | ||
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the bar is lower; the description still adds genuine behavioral context by disclosing the two verification mechanisms and their prerequisites. It does not state what happens on success/failure or whether a previously verified domain can be re-verified, which keeps it short of a 5.
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 the core action front-loaded and no filler; the trailing DNS/well-known clause is dense but informative. It is slightly run-on but 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?
For a mutation tool with no output schema and a 25%-covered 4-parameter schema, the description covers the verification flow but leaves the identity parameters (reference, listing_token) and the outcome of a successful verification unspecified. Adequate but with clear gaps.
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 only 25% — only email_code is documented. The description usefully clarifies that email_code is optional depending on the verification path, but reference, listing_token, and schema_version are unexplained in both schema and description, leaving three of four parameters opaque.
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+resource: 'Prove control of the company domain for a listing request', which is distinct from sibling tools like request_listing, approve_listing, or get_listing_status. It doesn't explicitly name a sibling to route against, but the domain-verification action is unambiguous on its own.
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 clearly states the two invocation conditions: pass email_code with the received code, or call without it once the DNS TXT record or /.well-known/aci-verification.txt file is in place. That is real when-to-use guidance, though it offers no exclusions or comparison to alternatives.
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.
request_listing1 field changedInput schema / properties / work_email / descriptionPrevious value: -"An address on the company's own domain (e.g. info@example.com) that the user can read: ACI mails it a code that confirms the domain without DNS changes. Another address works but then needs a DNS record or file."New value: +"An address on the company's own domain (e.g. info@example.com) that the user can read: ACI mails it a code that confirms the domain without DNS changes. A free-mail address (Gmail, GMX, web.de, Outlook …) or an address on another domain is refused."approve_listing2 fields changedInput schema / properties / accept_listing_terms / constPrevious value: -"LT-1"New value: +"LT-2"Input schema / properties / accept_listing_terms / descriptionPrevious value: -"Set to \"LT-1\" only after the user explicitly accepted the Listing Terms (https://agentcompanyindex.com/legal/listing-terms/lt-1) on behalf of the company."New value: +"Set to \"LT-2\" only after the user explicitly accepted the Listing Terms (https://agentcompanyindex.com/legal/listing-terms/lt-2) on behalf of the company."approve_listing7 fields changedInput schema / properties / accept_listing_termsAdded value: +{
+ "const": "LT-1",
+ "description": "Set to \"LT-1\" only after the user explicitly accepted the Listing Terms (https://agentcompanyindex.com/legal/listing-terms/lt-1) on behalf of the company."
+}Input schema / properties / approver_emailAdded value: +{
+ "description": "Required when the domain was confirmed with a DNS record or a file: an address on the company domain the approver reads. Ignored when the domain was confirmed with the emailed code (that address is recorded).",
+ "maxLength": 320,
+ "type": "string"
+}Input schema / properties / approver_nameAdded value: +{
+ "description": "Full name of the person approving for the company.",
+ "maxLength": 200,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / company_legal_nameAdded value: +{
+ "description": "The company's legal name (e.g. from its imprint), the party accepting the Listing Terms.",
+ "maxLength": 200,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / monthly_reportAdded value: +{
+ "default": true,
+ "description": "Send the monthly report to the confirmed work address (default true).",
+ "type": "boolean"
+}Input schema / properties / user_confirmationAdded value: +{
+ "description": "Optional: the user's reply agreeing to approve and to the Listing Terms, quoted word for word.",
+ "maxLength": 500,
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "schema_version",
- "reference",
- "listing_token",
- "revision",
- "approver_role"
-]New value: +[
+ "schema_version",
+ "reference",
+ "listing_token",
+ "revision",
+ "approver_role",
+ "approver_name",
+ "company_legal_name",
+ "accept_listing_terms"
+]request_listing_removalrequest_listing1 field changedInput schema / properties / work_email / descriptionPrevious value: -"Where ACI replies."New value: +"An address on the company's own domain (e.g. info@example.com) that the user can read: ACI mails it a code that confirms the domain without DNS changes. Another address works but then needs a DNS record or file."verify_listing_domain1 field changedInput schema / properties / email_codeAdded value: +{
+ "description": "The 8-digit code from the email Agent Company Index sent to the work address on the company domain.",
+ "maxLength": 20,
+ "type": "string"
+}search_offeringsrequest_listing1 field changedInput schema / properties / answersAdded value: +{
+ "additionalProperties": false,
+ "description": "Optional structured company answers for the draft. Each becomes a company statement on the profile, shown with its date. Unanswered fields stay open questions.",
+ "properties": {
+ "certifications": {
+ "description": "Certifications held by the company itself, not by its hosting provider.",
+ "items": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "company_name": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "company_size_bands": {
+ "description": "Size of the company itself.",
+ "items": {
+ "enum": [
+ "micro",
+ "small",
+ "medium",
+ "large",
+ "enterprise"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data_export": {
+ "description": "How customers get their data out.",
+ "maxLength": 500,
+ "type": "string"
+ },
+ "data_residency": {
+ "description": "Where customer data is stored.",
+ "enum": [
+ "DE",
+ "EU",
+ "US",
+ "mixed"
+ ],
+ "type": "string"
+ },
+ "deployment_model": {
+ "enum": [
+ "cloud",
+ "on_premises",
+ "both",
+ "not_applicable"
+ ],
+ "type": "string"
+ },
+ "description": {
+ "maxLength": 500,
+ "minLength": 20,
+ "type": "string"
+ },
+ "headquarters_country": {
+ "pattern": "^[A-Z]{2}$",
+ "type": "string"
+ },
+ "limitations": {
+ "items": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "market_country": {
+ "pattern": "^[A-Z]{2}$",
+ "type": "string"
+ },
+ "minimum_contract_term": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "negative_fit": {
+ "items": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "offering_name": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "offering_status": {
+ "enum": [
+ "active",
+ "beta",
+ "discontinued",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "offering_type": {
+ "enum": [
+ "software",
+ "service",
+ "physical_product",
+ "platform",
+ "other"
+ ],
+ "type": "string"
+ },
+ "organization_status": {
+ "enum": [
+ "active",
+ "inactive",
+ "acquired",
+ "closed",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "positive_fit": {
+ "items": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "prerequisites": {
+ "description": "What a customer needs in place before using the offering.",
+ "items": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "pricing_model": {
+ "maxLength": 300,
+ "type": "string"
+ },
+ "pricing_visibility": {
+ "enum": [
+ "public",
+ "quote_required",
+ "undisclosed",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "primary_problem": {
+ "maxLength": 300,
+ "type": "string"
+ },
+ "sub_processors": {
+ "items": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "support_languages": {
+ "items": {
+ "pattern": "^[a-z]{2,3}(-[A-Z]{2})?$",
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target_customers": {
+ "items": {
+ "maxLength": 500,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target_size_bands": {
+ "description": "Size of the customer organizations the offering is for.",
+ "items": {
+ "enum": [
+ "micro",
+ "small",
+ "medium",
+ "large",
+ "enterprise"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "use_cases": {
+ "items": {
+ "maxLength": 300,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "website_url": {
+ "description": "Company-confirmed primary website URL: https, on the company domain or a subdomain. Use when the root moves visitors elsewhere client-side.",
+ "maxLength": 2048,
+ "type": "string"
+ }
+ },
+ "type": "object"
+}update_listing_answersapprove_listingdiscover_offeringsevaluate_situationget_listing_statusget_offeringrequest_listingverify_listing_domainAgent-callable B2B SaaS directory: capability-structured, continuously verified listings.
Dated picks, sourced pricing, and rescue/eval tools across 305 AI agent infrastructure providers.
Agent-native security, trust, reliability, data and procurement tools for AI workflows.
Market intelligence for the AI agent economy: rankings, trust signals, liveness. 13 tools.
Add one secure layer between your agents and this server.
