Curated index of B2B offerings for AI agents: fit, non-fit, limits, sourced claims.
Scored across 10 tools
Most tools have clearly distinct purposes: listing lifecycle tools vs offering discovery tools. However, search_offerings, discover_offerings, and evaluate_situation all serve to find offerings, and while descriptions distinguish them, an agent could still misselect without careful reading.
All tool names use snake_case with a consistent verb_noun pattern (e.g., approve_listing, get_offering, request_listing). The few compound names (get_listing_status, verify_listing_domain) still follow the same convention.
10 tools is well-scoped for a directory and listing management server. Each tool covers a distinct step or resource, and there is no redundant or trivial tool.
The set covers search, detail retrieval, structured evaluation, and the full listing lifecycle: request, verify, status, update, approve, and removal. Minor gaps exist, such as no explicit way to cancel a draft listing or list a company's own submissions before publication.
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). 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: the distinct state branches (domain proof vs. draft vs. accepted terms vs. published URL, including the in-flight update case) and the contents of the revision digest (facts, company statements, what ACI verified, open questions). It stops short of documenting pagination, error states, or the fact that the token must come from a prior request.
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 core purpose, and every clause carries content — the state enumeration and the approval instruction are both useful. It is, however, a single heavily nested sentence with stacked parentheticals that costs the reader some parse time.
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 usefully covers what comes back and gives the downstream user-facing step, which is most of the burden for a read tool. The remaining gap is the input side: three required, undocumented parameters leave the agent guessing how to construct a valid call, which for a 3-required-param tool is a meaningful shortfall.
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% and all three parameters (reference, listing_token, schema_version) are required with no descriptions anywhere. The description never explains what 'reference' identifies, whether listing_token is single-use, or what schema_version must be, so an agent has no help beyond the bare field names.
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 enumerates the distinct states it can return, which separates it cleanly from approve_listing, request_listing, and verify_listing_domain. An agent can tell this is the polling/inspection tool for the listing workflow 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 implies when the tool fits ('and what to do next', plus the instruction to show the draft and Listing Terms before asking for approval), which is real workflow guidance. However, it never names an alternative sibling or an exclusion condition (e.g., use get_offering for the offering itself, verify_listing_domain for the proof step), so relative routing 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.
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. 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 declare readOnly/idempotent/non-destructive and closed-world, but the description adds behavioral detail the annotations cannot: the ranking algorithm (word-overlap first, then name), the low-relevance cutoff (dropped if matching fewer than half the best match's words), and explicit non-inputs (payment, client status, operator ownership), plus the statement that no scores or paid positions exist. That is substantive transparency beyond 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 use case, then the result behavior and ordering rules, then the follow-up. The ordering sentence is dense but earns its place as behavioral disclosure; a small amount of the ranking detail could be trimmed without loss.
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 ('returns matching offerings with the terms they matched') along with ordering and a follow-up route. It leaves the limit's default/behavior and any pagination semantics unexplained, which is a modest gap.
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 33%, and `limit` carries no description in either the schema or the description. The description partly compensates for `query` by showing realistic query strings and framing it as plain-language, but it adds nothing about the limit or the ordering impact of narrowing results.
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 concrete verb and resource ('Plain-language search over the Agent Company Index') and scopes the domain (B2B software products, service providers, agencies). It also routes the agent forward to get_offering. However, it does not distinguish itself from the similarly-named sibling discover_offerings, so sibling differentiation is only partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening clause 'Use when a user is looking for...' plus two concrete example queries gives clear situational context for invocation. There are no explicit exclusions or named alternatives (e.g. when to prefer discover_offerings instead), so it stops 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.
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.
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.
Directory of APIs, merchants, and tools AI agents can actually use.
Add one secure layer between your agents and this server.
