FastCAC

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds non-obvious context the annotations cannot: the figures are statutory government fees rather than the vendor's own pricing, and it discloses the ₦1,000,000 default share capital that the schema does not declare.

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 and the entity list front-loaded. The closing disclaimer earns its place by preventing a specific misreading of the numbers.

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 only two parameters and an output schema to explain the return shape, this is close to complete. The minor gap is that it never says what happens to share_capital when entity is ngo or business_name, leaving the agent to infer it from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% and the description supplies the missing default (₦1,000,000) plus the fact that share capital applies only to the company branch. That is real added meaning, but the mapping of 'ngo' to Incorporated Trustees is the only light shed on the entity enum, keeping it at the baseline-plus level.

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 ("CAC's official registration fees, line by line") and enumerates the three entity scopes it covers, including the share-capital branch. No sibling tool in the list computes fees, so the boundary is unambiguous 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?

"Use it for any question about what CAC charges to register" gives an explicit positive trigger, and "These are government fees, not FastCAC's price" excludes a plausible mis-invocation. It stops short of naming an alternative for a related question, but the surrounding scope is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds real context: the result is derived purely from the registration date, and the charge figure is an estimate rather than an authoritative amount. It also implies no BN-based lookup is performed here, which explains why the date parameter is mandatory.

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 scope and outputs, with no filler. The fastcac.com aside is slightly tangential but earns its place as a genuine fallback for a missing required input.

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 an output schema present, the description needn't spell out return values, yet its enumeration is a helpful preview rather than padding. For a single-input, read-only computation, nothing essential about selecting or invoking it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single parameter already documents the YYYY-MM-DD format, so the schema does the heavy lifting. The description adds the provenance hint ('it's on the certificate'), which is useful but minor; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific computation and enumerates its outputs: returns due from the registration date, which are overdue, CAC's estimated charge, and the next due date. This is clearly distinct from siblings like calculate_cac_fees or search_cac_register, which handle fee math and register lookup rather than annual-return status.

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 states the prerequisite (registration date, found on the certificate) and gives a fallback path when that date is unavailable — the fastcac.com checker resolves it by BN number. It does not explicitly say when to prefer a sibling tool, so it falls just short of full alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds material context beyond them: the call is slower, rate limited, and reaches an external authority ('CAC's own') rather than local data. It also discloses that low-similarity results come with CAC's suggested alternatives, which shapes how the agent should interpret a failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the action, then the return shape, then the cost/usage caveat. Every clause carries information; nothing is redundant with the title or annotations.

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 an output schema available the return format need not be restated, and the description still summarizes the meaningful outputs (scores plus suggested alternatives). The remaining gap is input-side: for a required picklist-constrained parameter at 50% schema coverage, it never explains where a valid value comes from.

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 50%; the schema documents line_of_business as an exact picklist entry and the description reinforces that with 'its exact CAC line of business'. However, it adds no guidance on how to obtain a valid picklist value (the sibling search_line_of_business) or what happens when a non-exact value is supplied, so the ambiguity in that required parameter is not resolved.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Run') and resource ('a proposed business name and its exact CAC line of business through CAC's own compliance and similarity checker'), and the phrases 'CAC's own' and 'similarity checker' differentiate it from the sibling check_name_availability. An agent can tell which check to call without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit use condition: 'use it for a name the user is seriously considering', backed by the cost rationale 'Slower and rate limited'. It stops short of naming the cheaper alternative (check_name_availability) as the fallback for casual lookups, leaving that routing to inference from siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnlyHint and openWorldHint, it discloses that active and inactive registrations matter, that any close match puts the name at risk, that other_matches only share generic words, and that empty close_matches is not definitive because CAC makes the final call. This is meaningful behavioral context for interpreting results, with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core search scope, and each subsequent sentence clarifies match categories or the availability caveat. It is dense but every sentence earns its place, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with an output schema and annotations, the description covers the search domain, result interpretation, and the key availability caveat. It could be more complete by explicitly distinguishing sibling register-search tools, but nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter is fully described in the schema, so the baseline is 3. The description reinforces that the name is matched for similarity rather than exact equality, but it adds no format or syntax guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (search/check) and resource (CAC public registry names) and scopes it across every registration type. It does not explicitly name or contrast with the sibling search_cac_register tool, so it is clear but not fully sibling-differentiated.

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 implies the use case, pre-registration availability checking, through the CAC rejection rule and explains how to interpret close_matches and other_matches. It gives no explicit when-to-use guidance versus search_cac_register or check_business_name_compliance, and no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already cover read-only and open-world behavior, but the description adds useful context: names are pre-checked against CAC's registry, availability values are enumerated, and unchecked results can occur when CAC search is busy. It does not discuss latency or rate limits, but the key behavioral caveat is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences with no wasted wording. The core action and the most important output caveat are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, has full schema coverage, an output schema, and relevant annotations. The description goes further by explaining the availability result semantics, which is the main non-obvious behavior an agent needs to know.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines both parameters. The description reinforces the `idea` input but does not add meaning for `line_of_business` beyond what the schema provides, making the baseline score appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: brainstorm CAC-registrable business names for an idea. It also distinguishes the output from a plain name search by explaining that returned names are already checked against CAC's registry.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear: use this when brainstorming names for a business idea. However, it does not explicitly route agents away from siblings such as check_name_availability or explain when not to use generation versus checking an existing name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the outcome shape and the 'not_found' error case, which is genuinely useful behavioral context. It does not discuss rate limits, latency, or whether the lookup can be partially stale, but the key call-time behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with purpose, then input provenance, then return/error behavior. No filler or restated title.

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 an output schema, annotations, and fully documented parameters, the remaining burden is workflow context and failure modes, both of which the description supplies. An agent can chain it after search_cac_register and handle the not-found case without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and each field already states it comes 'from search_cac_register', so the description's provenance note largely repeats the schema. Baseline 3 applies since the schema carries parameter meaning.

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 Tax ID (TIN)') and scopes it to what 'CAC's public search shows for a registered business'. The mention that inputs come 'from a search_cac_register result' makes it distinguishable from the sibling search_cac_register, which is the discovery step.

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?

Establishes the prerequisite workflow clearly: this tool is called after search_cac_register, using values from that result. It also names the failure condition ('not_found' when CAC has none). It stops short of explicit exclusions such as when to skip the lookup or which sibling to use instead for related checks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover readOnlyHint and openWorldHint, so the description carries the substantive burden and does well: it enumerates the exact status vocabulary and declares a privacy boundary (NIN and personal details are never returned). It stops short of covering polling cadence, handle lifetime, or authorization requirements, so not 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 short sentences, front-loaded with the status question, then the privacy constraint. The inline status enum is dense but earns its place by telling the agent exactly what values to expect; minor cost is that it crowds the opening sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-field explanation isn't strictly required, yet the description usefully previews the status/next_step/products shape and adds the privacy guarantee. For a single-parameter read tool this is close to complete; only retry/polling behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description's only parameter-related signal repeats the schema's own note that the handle comes 'From start_nin_request.' Baseline 3 applies since the schema already does the work.

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 ('Where a request from start_nin_request stands') and ties itself explicitly to the sibling tool that created the request, so an agent can distinguish it from start_nin_request and the other CAC siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the usage condition clear: this is the follow-up check on a request previously created via start_nin_request, and the handle must come from there. It doesn't state any exclusions or what to do if the handle is unknown/expired, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only and open-world characteristics, and the description adds genuine behavioral context on top: it distinguishes existence from availability and warns that an error response is not evidence of no match. It does not disclose result caps or pagination behavior, which matter for an open-world search, so it falls 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?

Front-loaded purpose, then return shape, then routing distinction — nothing is buried. However, enumerating all seven returned fields is largely redundant given an output schema exists and crowds out more useful details such as result limits.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only search with full schema coverage, an output schema, and annotations, the description is essentially complete: purpose, routing, and error semantics are all covered. The remaining gap is operational — no guidance on result caps or how to narrow a broad open-world search — which is minor but real.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters and the enum are already documented in the schema; the description only echoes the name-or-RC/BN query modes. The `entity_type` filter is not mentioned at all in the description, so it adds little beyond the structured fields and the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ("search the CAC public register for businesses already registered in Nigeria") and the two ways to query (by name or RC/BN number). It explicitly separates itself from check_name_availability and check_business_name_compliance, so an agent can route correctly without opening sibling 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?

It gives both the when-to-use case (listing what already exists) and the when-not case, naming the two alternative tools that perform availability/compliance checks. The closing caveat that an `error` never means there's no match is exactly the kind of exclusion guidance an agent needs to avoid false conclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds genuine behavioral context by saying matches are 'exact' against a fixed picklist, implying no fuzzy results and possibly empty responses, but it says nothing about how many entries come back or how close a description must be to match.

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?

One front-loaded sentence with no filler; the key qualifier 'exact' appears early. It is efficient, though so terse that it borders on under-specified rather than merely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. However, for a lookup whose input is an untyped free-text 'query' with 0% schema coverage, the description leaves the agent guessing about input phrasing and match behavior, which is a meaningful 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 coverage is 0% for the single 'query' parameter, so the description must carry the load. 'Matching what the business does' usefully indicates the query is a natural-language description of business activity rather than a code or ID, but it gives no examples, length guidance, or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Find') and resource ('CAC's line-of-business picklist') and qualifies the match as 'exact', which distinguishes it from broader siblings like search_cac_register or check_business_name_compliance. It stops short of saying what a line of business is used for, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this instead of siblings such as search_cac_register or calculate_cac_fees, nor any prerequisite or follow-up context. The phrase 'matching what the business does' hints at the input style but does not state when this lookup is the right call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the whole downstream flow: the person must complete a live face check and pay on fastcac.com, the exact prices (₦1,000 slip, ₦500 NIN, ₦1,200 bundled), that results go only to the person, and that starting is free and charges nothing. This resolves the key ambiguity created by readOnlyHint=false paired with 'charges nothing'.

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 action and destination, then scoped per enum value, then the return values. The single long sentence with nested semicolons and parentheticals is dense, but each clause (costs, who pays, free to start) carries real decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need little explanation, and the description still names the person-facing link and the agent-facing request_handle. For a one-parameter tool it covers flow, costs and outcome routing well; only the handoff to get_nin_request_status and any expiry/duplicate-request behavior are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the enum descriptions already define both values. The prose largely restates them, adding only the small detail that the phone lookup uses the number registered with NIMC, which the schema already hints at. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a concrete verb and resource ('Start a paid request on fastcac.com') and precisely enumerates the two enum modes: 'slip' produces a PDF/print-ready NIN slip from a known NIN, 'phone' finds the NIN via the NIMC-registered phone number. It does not explicitly differentiate itself from the sibling get_nin_request_status, which is the natural follow-up tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear selection criteria between the two kinds, plus an explicit exclusion: for 'phone' the person can only add the slip on fastcac.com, and 'you can't request it here'. It stops short of naming get_nin_request_status as the tool for tracking an already-started request.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.