ukintel.uk — UK company, tender and grant intelligence

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

With no annotations provided, the description fully discloses behavioral traits: cost ($0.02 USDC per call), the exact return structure (`result.fca` with fields `checked, regulated, frn, firm_name, status, permissions_summary, warnings[], note`), error handling ('never a 500', register unavailable leads to `checked=false` with a reason), and that it is a separate call from the verdict. No contractions exist.

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 concise and well-structured: it opens with the core question, then lists returns, cost, and error behavior. Every sentence adds value without extraneous text. It is front-loaded with purpose and efficiently organized.

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 tool with one parameter, no output schema, and no annotations, the description is fully complete. It covers purpose, return shape, error case, cost, and differentiation from sibling. The agent has all necessary information to invoke the tool 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 100% for the only parameter (`number`), with a clear pattern and description. The description does not add additional semantics about the parameter beyond what the schema provides, so the baseline score of 3 is appropriate. No repetition or contradiction.

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

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

The description clearly states the tool's purpose: checking if a UK company is FCA-regulated and returning register status, permissions summary, and warnings. It uses a specific verb ('returns') and identifies the resource (FCA register), and explicitly distinguishes from the sibling tool `uk_company_verdict` by noting it is 'sold separately from the full verdict'.

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 provides clear context by noting 'fintech-vetting agents often want only this', implying the tool is for quick FCA checks without the full verdict. It hints at the alternative (the verdict tool) by mentioning 'sold separately', but does not explicitly state when not to use this tool or name the alternative directly. Still, the guidance is effective.

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?

No annotations are provided, so the description bears full burden. It clearly states the tool is paid ($0.02 USDC per call) and provides the exact return shape. It doesn't disclose any destructive behaviors or side effects, but as a read-only data retrieval tool, the key behaviors (live source, cost, structured output) are 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 description is two paragraphs: first explaining purpose and output, second stating cost and explicit return structure. It's front-loaded with the core purpose and key details. The repetition of 'returns' could be trimmed, but overall it's efficient.

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

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

Given the simplicity (only 2 params, no output schema), the description covers the main points: what data is returned, cost, and the effect of the detail param. It doesn't explain pagination, error handling, or rate limits, but for a single-company profile tool with clear schema, this is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'detail' parameter's effect (adds filing history, lifts token cap) and the 'number' parameter's pattern (prefixes for Scotland, NI, LLP). This goes beyond the schema's terse pattern and enum descriptions.

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

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

The description clearly states it returns structured JSON data for one UK company, enumerating fields like status, incorporation date, type, SIC codes, etc. It differentiates from siblings by specifying the source (Companies House) and the structured output format, which is distinct from search or other UK tools.

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 mentions it costs $0.02 USDC per call, which signals when to use frugally. It doesn't explicitly contrast with siblings like uk_company_search or uk_company_verdict, but the focus on detailed profile data versus searching or verifying implies its use case. No explicit when-not-to-use guidance is provided.

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?

With no annotations, the description fully discloses the tool's behavior: it is a read-only search, returns up to 5 results, costs $0.005 per call, and lists output fields (results array with specific properties). It does not mention rate limits or authentication, but for a simple, non-destructive search this is adequate transparency.

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 concise at two short paragraphs, each focused on a single aspect: purpose and output, then cost and return structure. It is well-structured and front-loaded with key information. Minor extra detail ('x402, Base mainnet') could be trimmed but does not harm clarity.

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

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

Given no output schema, the description provides the output structure explicitly (results[] with fields). It covers both parameters (via schema), cost, and purpose. It does not mention pagination or whether total_matches is accurate, but for a simple top-5 search with limited parameters, it is fairly complete.

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%, with both parameters (q and limit) having descriptions. The tool description adds little beyond what the schema already says, only reinforcing the 'top 5 matches' concept. It does not provide examples or extra usage nuance, so it adds marginal value over 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 clearly states the tool finds UK companies by name and returns top 5 matches with company number, name, status, and incorporation date. It mentions 'Taster tier' and contrasts with full profile/verdict, hinting at differentiation from sibling tools like uk_company_profile and uk_company_verdict, though not explicitly naming them. This is clear enough but stops short of explicit sibling differentiation.

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

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

The description advises use as a quick, cheap search before paying for full profile or verdict, providing clear context for when to use this tool. It implies alternatives (profile/verdict tools) but does not explicitly state when not to use or list alternative names. The guidance is sufficient for basic understanding of its role.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the verdict is deterministic, published, auditable, re-weightable, and 'Never model-scored', which is crucial trust-related context. It also discloses the $0.10 USDC x402 cost and the exact response structure, going well beyond a generic summary.

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

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

The description is dense but front-loaded: the verdict concept, rule transparency, cost, and return contract are all covered in a compact space. The rule list is somewhat long, and the 'Returns' content partially repeats the earlier verdict description, but every section is informative and none is 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?

There is no output schema, so the description must define the return contract, and it does thoroughly: score range, band enum, flags with code/detail, fca object, narrative, and profile data. It also covers pricing, the deterministic rule engine, and the effect of `detail=full` on the response cap. Error cases are not covered, but the tool is simple enough that this is a minor 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 100%, so the baseline is 3 even without additional parameter detail. The description does not enrich the meaning of `number` or `detail` beyond the schema, though it does imply profile-related data and the response-cap impact of `detail=full`. No deduction is needed since the schema already fully documents parameters.

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

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

The description opens with a direct question, 'Should an agent trust this UK company?', and immediately defines the tool's output as a 0-100 verdict plus a low_risk/caution/high_risk band. It also distinguishes itself from the sibling uk_company_profile by stating it returns 'Everything the profile returns, plus verdict', making its role as the scoring layer unmistakable.

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

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

The description clearly frames the tool as a decision aid for whether to trust a UK company, and mentions deterministic/published rules and a per-call cost, which signal a deliberate scoring use case. However, it does not explicitly contrast this tool with uk_company_profile, uk_company_fca, or uk_company_search, nor does it state when not to use it.

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

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

With no annotations, the description carries full burden. It discloses data source (360Giving), licence handling (share-alike excluded, each award carries licence), cost ($0.20 USDC per call), and return structure. It does not mention limitations like data freshness or rate limits, but the disclosed details are substantial.

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 fairly long but well-structured, front-loading the purpose and listing key output fields. It includes cost and return format. Minor redundancy could be trimmed, but overall it is organized and informative.

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

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

Given the complexity of the tool (multiple data fields) and no output schema, the description provides a detailed return structure. It covers giving stats, recent awards, and live grants. However, it omits explanations for 'match_quality' and 'coverage' fields, leaving some 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?

The input schema has 100% description coverage for the single parameter 'name', with examples. The tool description does not add additional meaning beyond the schema examples. Baseline is 3 as schema coverage is high and description adds no extra value.

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

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

The description clearly states the tool aggregates a UK funder's giving history from the 360Giving corpus, including grants made, typical award, size distribution, yearly pattern, recent awards, and live grant schemes. It distinguishes itself from sibling tools by focusing on funder-level data rather than grant search or company profiles.

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 does not provide explicit guidance on when to use this tool versus alternatives like uk_grants_search or uk_grants_match. It hints at a use case ('Who actually funds things like yours') but lacks clear when-to-use/when-not-to-use instructions or prerequisites.

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 description explains that criteria are parsed once at ingest and not guessed at request time, and that if not fully parsed, it uses Find a Grant's listing fields with PARTIAL_CRITERIA flag. It also mentions cost and what returns. Annotations are not provided, so the description carries the full burden and does it well, though it could mention if the call is read-only or has side effects.

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

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

The description is dense with information but slightly long due to the detailed output structure. It is front-loaded with the tool's core purpose and key behaviors. Could be slightly more concise by trimming the output example, but every sentence serves a purpose.

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

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

Given the tool's complexity (4 parameters, nested objects, cost, and eligibility logic), the description covers purpose, input semantics, behavioral caveats, and cost. With no output schema, it details return values. It misses explicit guidance on error handling or prerequisites (e.g., grant must exist), but is largely complete.

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 input schema already covers all parameters with descriptions (100% coverage), but the description adds value by explaining how 'declare' works ('a first call tells you what to declare on the second') and that 'id' is the Find a Grant slug or alias. It enhances understanding beyond the schema without redundancy.

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

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

The description clearly states the tool provides a deterministic eligibility verdict for one grant and one project, with specific outputs like a full criteria table, missing information, and indicative funding. It distinguishes itself from siblings by focusing on grant eligibility rather than company profiles or tender scoring.

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 use for determining grant eligibility with a single grant and project, and notes that it costs $0.15 per call, which guides cost-conscious usage. However, it does not explicitly indicate when to use this tool versus alternatives like uk_grants_match or uk_tenders_fit_score, though the focus on eligibility is clear enough.

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 description provides extensive behavioral transparency: it uses deterministic rules (no LLM on verdicts), excludes ineligible grants, costs $0.15 USDC per call, and returns a specific result shape. No annotations exist, so the description carries the full burden and delivers rich, critical details about behavior, costs, and ethics (ineligible grants never dressed up as options).

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 main purpose and provides a clear, detailed overview in two substantive paragraphs. Every sentence adds value (cost, determinism, result structure). It is slightly longer than necessary but still efficient. A very minor deduction for density—could be split into briefer chunks, but overall it is well-structured.

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

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

Given the tool's moderate complexity (nested input, no output schema), the description is comprehensive. It specifies cost, deterministic behavior, and the exact output format (matches with eligibility table, excluded counts). Despite no output schema, the description fully explains return values. The richness compensates for the lack of annotations and partially weak schema coverage.

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%, with 'top' well-defined by schema (type, default, min/max) and 'project' described but with nested properties lacking descriptions (e.g., 'keywords' and 'description' only have empty descriptions). The description adds value by explaining the overall usage (send project profile with 'what it is, who you are, where, how much you need'), which helps agents understand how to populate the nested object. The description partially compensates for the schema gap, but detailed parameter semantics for nested fields remain thin.

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

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

The description clearly states the tool's purpose: matching a project profile to eligible UK grants and returning ranked results. It distinguishes itself from siblings like 'uk_grants_search' by emphasizing eligibility-based matching with a per-criterion pass/fail table, not just a search. The verb 'Match' and resource 'project profile to eligible UK grants' are specific and unambiguous.

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

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

The description explicitly explains when to use this tool: when you need to find grants a project could actually get. It contrasts with 'uk_grants_search' implicitly by stating it returns ranked eligible-first matches with pass/fail details. However, it does not explicitly say when NOT to use it (e.g., if only a simple search is needed) or name alternative sibling tools for specific use cases. The guidance is clear but lacks 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It clearly states the tool costs $0.10 USDC per call, is indexed daily from the official listing (no API of its own), and provides a detailed return structure without caveats about strictness or accuracy. This is thorough and upfront about limitations and costs.

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 relatively concise but front-loads the purpose and result structure clearly. The first sentence covers the core functionality; the second adds filtering and update frequency; the third provides pricing and return format. It is well-organized but slightly verbose when describing the nested return fields—could be tighter without losing clarity.

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

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

Given the moderate schema richness (100% coverage, 6 parameters, no output schema, no annotations), the description is complete enough. It explains the source, pricing, update cadence, and return fields in detail. However, it does not describe pagination or rate limits, and since no output schema is provided, some agents might need more clarity on the exact structure of the returned grants (e.g., format of dates, nested objects). Still, the overview is sufficient for a typical search tool.

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 baseline is 3. The description adds value by summarizing the purpose of each parameter in practical terms (e.g., 'Applicant type: individual, business, charity...'), and the enum values for open_now are clearly listed. However, the description does not add nuance beyond what the schema already explains, so a slight bonus is given for clarity but not for adding new semantic depth.

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

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

The description clearly states that the tool searches live UK government grants from GOV.UK Find a Grant, listing specific fields returned (name, funder, amount range, dates, etc.) and filtering options. This distinguishes it well from sibling tools like uk_tenders_search, which cover different procurement data.

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

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

The description explains when to use the tool (for live UK government grants) and mentions that it is updated daily and provides a machine-readable version since the official source has no API. It does not explicitly exclude competing sibling tools like uk_grants_match or uk_grant_eligibility, but the purpose is clear enough for an agent to infer the correct use case.

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 description discloses return fields (status, version, network, upstreams, rules_version, warnings) and states it is free. No annotations exist, so the description carries the full burden; it adequately describes the behavior for a simple read-only health check.

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 extremely concise with two sentences, front-loading the purpose and then listing return fields. Every word is meaningful with no redundancy.

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

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

For a zero-parameter health check tool with no output schema, the description comprehensively lists all expected return fields. No additional context is needed.

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

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

The tool has no parameters, so the baseline is 4. The description adds value by listing the output fields, compensating for the lack of an output 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 explicitly states 'Liveness and upstream health', which clearly identifies the tool as a health check. It distinguishes from sibling tools that focus on company data, grants, and tenders.

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 notes 'Free, because frameworks probe before they route money', implying this is intended for automated health probes. It provides clear context for when to use it, though it doesn't explicitly exclude other use cases or name alternatives.

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?

No annotations exist, so the description carries the full burden. It discloses that the tool is free, returns a rotating daily sample, and that the envelope structure (query, result, verdict, etc.) is identical to paid endpoints. This is appropriate for a non-destructive preview tool, though rate limits or authentication requirements are not mentioned.

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 concise (~100 words) and well-structured. It front-loads the purpose in the first sentence, then details options, return envelope, and free status. Every sentence earns its place with no redundancy or fluff.

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

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

Given the tool's simplicity (1 optional parameter, no output schema, no annotations), the description is quite complete. It explains the response envelope, how to select different wings, and the free/rotating nature. It does not cover error scenarios or limits, but for a preview tool these are not critical omissions.

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% with one enum parameter 'wing' described. The description adds significant value beyond the schema: it explains the default value (company), gives concrete examples (?wing=tenders, ?wing=grants), and notes that all options rotate daily. This enriches the agent's understanding of parameter usage.

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

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

The description clearly states this tool provides a genuine, freshly-computed sample response from one of three product families (company, tenders, grants) for free. It distinguishes itself from sibling tools like uk_company_verdict, uk_tender_brief, and uk_grant_eligibility by being a preview endpoint with rotating daily content.

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

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

The description explains how to use the tool with different 'wing' query parameters and defaults to company. It mentions it is free and returns the same envelope as paid endpoints, implying it is for testing/preview before spending. While it does not explicitly state when not to use it or compare to siblings, the context is clear and actionable.

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?

With no annotations provided, the description carries full burden. It discloses the cost ($0.10 USDC per call), the policy on CPV codes ('we report the register, we never guess'), and the return structure. No side effects or destructive behavior is relevant as it is a read operation. However, it could mention rate limits or error handling.

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 moderately concise for the amount of information it conveys (fields, cost, policy). It is front-loaded with the core purpose. Some could be trimmed, but it is overall well-structured and readable.

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

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

Given the tool has only one parameter, no output schema, and no annotations, the description is fairly complete. It explains the return fields in detail, mentions cost and a data handling caveat. It does not cover error scenarios or rate limits, but it is adequate for a simple retrieval tool.

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 schema already fully describes the 'ocid' parameter with pattern and example (100% coverage). The description adds value by stating 'Exactly as returned by /v1/tenders/search', which provides context on how to obtain the correct OCID, going 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 clearly states it provides a 'full agent-ready dossier' for one tender, listing the structured fields. It differentiates from sibling tools like 'uk_tenders_search' by emphasizing 'one tender' vs search results, and the detail level is high.

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 implicitly indicates use when a full dossier on a single tender is needed, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the sibling tools.

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?

With no annotations, the description carries the full disclosure burden and does so well. It reveals that scoring is deterministic and rule-based, not model-based, that each call costs $0.20 USDC, that per-factor numerators/denominators are returned for client-side re-weighting, and it details the result structure.

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

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

The description is dense and information-rich, with useful details like cost, determinism, and output shape. It is longer than strictly necessary due to the nested result structure, but every major sentence adds value and the core purpose is front-loaded.

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

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

For a complex tool with no output schema and no annotations, the description is remarkably complete. It explains what results look like, how scoring works, what factors are included, and even monetization. An agent has enough context to invoke it and interpret the response.

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%, so the baseline is 3. The description lists profile fields like keywords, regions, value band, and certifications, but adds little meaning beyond their names. It does not explain top or filters any further than the schema already does.

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

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

The description clearly states the action: send a supplier profile and receive best-fitting live UK tenders scored 0-100. It is distinct from a generic search tool by emphasizing profile-based matching, but it does not explicitly name a sibling alternative such as uk_tenders_search.

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 intended use case clear: matching a supplier profile to live tenders. It does not explicitly state when not to use it or name alternatives, but the profile-driven scoring context is sufficient to guide selection.

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?

No annotations provided, so description carries full burden. It discloses: 6-hourly refresh rate, top 10 results, honest null for CPV, cost per call ($0.05 USDC on Base mainnet). Could add: whether results are paginated, sorting order, rate limits, or any destructive effects. Acceptable but not exhaustive.

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 focused sentences plus one cost line—every sentence serves a purpose. Front-loaded with core action and data sources, then details return format and filters. 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?

Given 7 params with 100% schema coverage, no nested objects, and no output schema requirement, the description fully covers key behavioral aspects (refresh, cost, honest null, excluded notices). Return value format is summarized adequately without needing an output 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 100%, so baseline is 3. Description adds value by clarifying synonym expansion for 'q', honest null CPV behavior, and that cpv/region/value/deadline filters may exclude notices (tracked in excluded{}). Slightly above baseline.

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?

Description clearly states the verb ('search'), resource ('live UK public-sector tenders'), and data sources ('Find a Tender and Contracts Finder'). Returns top 10 matching notices as plain-English briefs. Diverges from siblings that focus on companies, grants, or health, as shown in sibling-tools list.

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?

Provides clear context: indexes two portals with no signup needed, lists filter parameters explicitly. Could improve by explicitly stating when not to use (e.g., for non-UK tenders or non-public-sector searches) and naming specific sibling alternatives.

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