Token-bounded (< 1.5 KB / ~300 tokens) public data refinery for AI agents. Delivers sub-5ms corporate filings (US SEC EDGAR, UK Companies House, France INPI), beneficial ownership graphs, public procurement tenders (Spain PLACSP, EU TED), and automated corporate risk scoring. Cuts LLM context waste by ~95%.
Performs automated forensic solvency and credit distress analysis across UK or US companies (< 1.5 KB). Explicitly separates objective statutory facts (delinquent accounts filing dates, director resignation counts, active mortgages, insolvency history) from transparent heuristic model weighting (+35 pts, +25 pts) to provide explainable 0–100 risk audits and credit recommendations (APPROVE, CAUTION, REJECT).
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| identifier | Yes | Company identifier (UK 8-digit company number or US ticker/CIK). | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| jurisdiction | Yes | Jurisdiction code ('UK' for United Kingdom or 'US' for United States). |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds useful behavioral context by disclosing that the analysis separates objective statutory facts from transparent heuristic weighting (+35 pts, +25 pts), explains the 0–100 scoring, and notes the <1.5 KB response size. It does not reveal rate limits or auth requirements, but the annotation set already addresses the main safety profile.
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 a single dense sentence with no filler. It front-loads the core action and scope, then adds concrete examples of statutory facts and heuristic weights, and finishes with the output format. Every clause adds value.
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 rich annotations, fully described input schema, and presence of an output schema, the agent has everything needed to invoke this tool correctly. The description covers the analytical approach, output categories, and response size, while cache and spend-control behavior are fully documented in the parameter 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 the schema already documents all four parameters, including jurisdiction, identifier, maxAgeHours, and forceFresh. The description adds only the general scope of UK/US companies and does not elaborate on parameter meaning, so the baseline score of 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 starts with a specific verb and resource: 'Performs automated forensic solvency and credit distress analysis across UK or US companies.' It also names the concrete output, 0–100 risk audits with APPROVE/CAUTION/REJECT recommendations, which clearly distinguishes it from sibling tools focused on filings, officers, tenders, or sanctions.
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 establishes when this tool applies: when an agent needs a solvency or credit-distress audit for a UK or US company. It does not explicitly name alternative tools or define exclusions, but the distinct output type and jurisdiction scope make selection unambiguous against the listed sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Maps cross-border corporate parent-subsidiary relationships, multinational public tender wins, common directors, and historical state mutations across US, UK, France, Spain, and EU (< 2 KB).
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| identifier | Yes | Company name, ticker, French SIREN, UK company number, or tender contractor name. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat those. The description adds the response size constraint (<2 KB) and hints at temporal coverage through 'historical state mutations,' but does not describe caching, rate limits, or data freshness beyond what the parameter schema already covers.
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 a single well-structured sentence that front-loads the action and resource, lists the key relationship types, and tucks the size note at the end. Every phrase earns its place with no repetition or 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?
The description covers the tool's scope, the types of relationships mapped, the geographic coverage, and even response size. With an output schema present, parameter schema at 100% coverage, and annotations covering safety and idempotency, nothing needed for correct invocation 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 description coverage is 100%, and each parameter (identifier, forceFresh, maxAgeHours) already has detailed semantic documentation. The tool description itself adds no additional parameter-level meaning, so a baseline score of 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 begins with the specific verb 'Maps' and clearly identifies the resource: cross-border corporate parent-subsidiary relationships, tender wins, common directors, and historical state mutations. The geographic scope (US, UK, France, Spain, EU) and the graph-oriented output differentiate it from siblings like get_uk_corporate_network or get_eu_public_tender.
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 a clear use case: any request needing cross-border corporate relationships or multinational tender context. It does not explicitly name alternatives or state when not to use this tool, but the 'cross-border' and jurisdiction scope provide clear context that distinguishes it from country-specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a verified, token-optimized statutory public sector procurement tender from Spain's aggregated PLACSP syndication feed (CODICE XML) by expediente identifier (< 1.5 KB). Returns contracting authority, tender title, budget valuation in EUR, contract type, CPV code, awarded contractor, and award date. Note: PLACSP has no live single-tender lookup API, so this serves from Distil's continuously-synced data moat — use search_es_tenders first if you don't already have the exact expediente ID, and expect 'not found' for tenders outside the aggregated feed's recent window.
| Name | Required | Description | Default |
|---|---|---|---|
| tenderId | Yes | Official Spanish public tender folder identifier or PLACSP expediente reference (e.g. '2024/00123'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses the underlying data source is a syndicated feed with no live single-tender API, that it serves from a continuously-synced cache, and that it may return not-found for older tenders. This gives the agent essential expectations not captured in structured metadata.
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 informative, front-loading the core function and return fields before the context note. It is slightly verbose with phrases like 'Distil's continuously-synced data moat,' but every sentence contributes actionable context.
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 has an output schema and comprehensive annotations, and the description fills the remaining gaps: data provenance, freshness limitations, alternative tool routing, and expected not-found behavior. Together this fully equips an agent to use 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 description coverage is 100%, with each parameter already documented with details such as examples and defaults. The description reinforces tenderId as the lookup key but adds no new semantic meaning beyond the schema, so 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 uses a specific verb ('fetches') with a clear resource: Spain's PLACSP syndication feed by expediente identifier. It distinguishes itself from siblings by naming the specific country, data feed, and identifier type, and even references the sibling search_es_tenders, making the tool's purpose 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?
Explicitly tells the agent to use search_es_tenders first if the exact expediente ID is not known, and warns about 'not found' results outside the recent feed window. It also explains the lack of a live API, providing clear context for when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches condensed, token-optimized public procurement tender notice across the 27 EU member states from TED (< 1.5 KB). Returns contracting public authority, notice status, estimated budget in EUR, CPV classification code, and awarded suppliers.
| Name | Required | Description | Default |
|---|---|---|---|
| noticeId | Yes | The European Union TED publication notice identifier (e.g. '2026-OJS-FR-CYBER-001'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds useful behavioral context: it returns condensed, token-optimized data under 1.5 KB and lists the key fields included, which helps an agent understand response characteristics without needing to open the output schema.
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 a single front-loaded sentence that states the operation, scope, size constraint, and return contents with no filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only annotations, a well-documented schema, and an output schema present, the description is nearly sufficient for correct invocation. The only notable gap is the lack of explicit routing guidance against sibling tools, but an agent with a noticeId can confidently select this 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%, and the schema itself provides rich explanations for noticeId, forceFresh, and maxAgeHours, including caching and surcharge semantics. The main description adds no parameter-specific meaning beyond the schema, so the baseline score of 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 begins with a specific verb and resource: 'Fetches ... public procurement tender notice across the 27 EU member states from TED.' It also lists the returned data fields, making it clear this is a single-notice retrieval tool and distinguishing it from sibling search and country-specific tender 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 intended use is implied: an agent should call this when it has a specific noticeId and needs a concise EU TED tender notice. However, the description never explicitly states when to prefer this over siblings like search_eu_tenders or get_es_public_tender, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches verified French statutory enterprise dossier from INPI / SIRENE by 9-digit SIREN (< 1.5 KB). Returns official INSEE legal form (SA, SAS, SARL, SE), NAF/APE activity codes, active establishment count, registered headquarters address, and statutory officers/directeurs généraux.
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| sirenOrQuery | Yes | 9-digit French SIREN enterprise number (e.g. '552032534' for L'Oréal, '855200887' for Michelin). |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds useful context beyond annotations: 'verified', official statutory source (INPI / SIRENE), response size cap (<1.5 KB), and the specific official data elements returned.
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 information-dense sentences with the action and scope front-loaded. The return-field list and response-size note are compact and add value; there is no filler or 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?
Given the full annotations, complete parameter schema, and existing output schema, the description sufficiently covers source, country, identifier format, and return content. It is nearly complete but does not explicitly mention alternative sibling tools for search or other countries, so it stops just short of maximal completeness.
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 all three parameters documented in detail and examples, so the baseline is 3. The description adds little parameter-level meaning beyond restating the 9-digit SIREN format; forceFresh and maxAgeHours are only explained in 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?
States an exact action ('Fetches verified French statutory enterprise dossier'), named sources (INPI / SIRENE), required identifier format (9-digit SIREN), and enumerates returned fields. The French scope and SIREN input clearly distinguish it from sibling country-filing and search 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 implies lookup of a specific French company filing when a SIREN is known, but it does not explicitly say when to prefer this over search_fr_companies or the UK/US filing equivalents, nor does it state exclusions. The intended context is clear but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screens corporate entities, contractors, and individuals against US OFAC (SDN), the UK Sanctions List (FCDO), EU Financial Sanctions Files, and the UN Security Council Consolidated List (< 1.2 KB). Uses fuzzy Jaccard string distance to catch spelling variations and aliases, returning immediate compliance verdicts and risk scores. Screens sanctions designations only, not PEP status.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Target company name, director name, or entity identifier to screen for statutory sanctions (e.g. 'Sberbank', 'Gazprombank'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| fullResults | No | Default false returns only the highest-confidence matches (token-bound, capped, fits this tool's advertised <1.2KB budget) with the true total match count always disclosed. Set true to receive every match found instead — for a compliance screening use case, some callers need the complete picture, not a capped subset; the response discloses total match count either way so the caller always knows whether they're seeing the whole list. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| jurisdiction | No | Optional jurisdiction filter ('US', 'UK', 'EU', 'UN'). |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the bar for additional behavior disclosure is lower. The description adds genuinely useful behavioral context: fuzzy Jaccard matching to catch spelling variations/aliases, immediate verdict/risk-score output, and the explicit exclusion of PEP screening. It does not mention caching, refresh behavior, or spend controls, but those are covered in schema parameter descriptions.
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 only three sentences, front-loads the primary purpose, and avoids filler. The phrase '< 1.2 KB' is awkwardly attached to the UN list and reads ambiguously—likely referring to the response budget rather than the list itself. The overall structure is still efficient and well-ordered.
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 rich input schema descriptions, annotations, and an output schema, the description does not need to explain return values or every parameter. It covers the screening subject, the sanctions lists queried, the matching approach, and the output nature. The missing piece is consistency with the tool's 'PEP' name/title, and the ambiguous size constraint, which slightly undermines completeness.
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 rich descriptions for all five parameters, including forceFresh, fullResults, maxAgeHours, jurisdiction, and query. The tool description does not add new parameter-level semantics beyond indicating the subject types (corporate entities, contractors, individuals), so the baseline score of 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 clearly states the tool's specific verb and resource: it screens corporate entities, contractors, and individuals against US OFAC, UK FCDO, EU, and UN sanctions lists, returning compliance verdicts and risk scores. It explicitly clarifies that it screens sanctions designations only, not PEP status, which helps differentiate it from sibling tools. However, the tool name and title both prominently include 'PEP', while the description says the opposite, creating avoidable confusion.
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 a clear use case—statutory sanctions screening—and explicitly carves out PEP status as out of scope. It does not name alternative sibling tools or state when another tool should be used instead, such as get_corporate_risk_score. The usage guidance is therefore adequate but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes statistical pricing intelligence, winning bidder concentration, and recommended RFP bid discount windows across public procurement tenders in Spain (PLACSP) and the European Union (TED) (< 1.5 KB). Accepts a tender notice ID (e.g. '2026-OJS-FR-CYBERSEC-001', '2024/00123'), a CPV code (e.g. '72000000', '30200000'), or a sector keyword query (e.g. 'cybersecurity', 'cloud infrastructure', 'limpieza'). Returns average/median budgets, winning contractor market shares, historical discount rates, and benchmark reference contracts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keyword, sector name, or project title (e.g. 'cybersecurity', 'cloud', 'limpieza', 'software'). | |
| country | No | Two-letter country code filter for EU tenders (e.g. 'FR', 'DE', 'ES', 'IT', 'NL'). | |
| cpvCode | No | Common Procurement Vocabulary code prefix (e.g. '72000000', '30200000') OR tender notice ID. | |
| noticeId | No | Alias for tenderId (e.g. '2026-OJS-FR-CYBERSEC-001'). | |
| tenderId | No | Specific tender identifier or EU TED notice ID (e.g. '2026-OJS-FR-CYBERSEC-001', '2024/00123') to benchmark against its sector. | |
| authority | No | Contracting public authority name filter (e.g. 'Ministerio de Hacienda', 'ENISA'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| contractType | No | Contract type classification filter (e.g. 'SERVICES', 'SUMINISTROS', 'SERVICIOS', 'WORKS'). | |
| jurisdiction | No | Jurisdiction scope: 'ALL' (default, covers EU TED + Spain PLACSP), 'ES' (Spain), 'EU' (European Union TED), or country code ('FR', 'DE', 'ES', etc.). | ALL |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the data sources (PLACSP and TED), the scope (Spain/EU), and the computed nature of outputs, which goes beyond the safety profile. It does not disclose failure modes or caching behavior, but the bar is lowered by 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 description is a single, focused paragraph with no redundant sentences. It front-loads the core purpose, then lists accepted inputs and outputs efficiently. The mention of '< 1.5 KB' is a minor oddity but does not detract from 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?
The tool has 10 optional parameters, and the description does not explain parameter precedence or how they combine (e.g., if both tenderId and query are provided). While output schema exists, the interaction logic is missing. For a complex tool, this gap could lead to incorrect invocation. However, the schema descriptions and examples partially compensate.
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 descriptions cover all 10 parameters (100% coverage), so the schema already explains each parameter. The description merely reiterates that the tool accepts tender ID, CPV code, or keyword, but adds no new semantic detail about parameter usage, interactions, or valid formats beyond the schema. Baseline 3 is warranted.
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 ('Computes'), a clear resource ('statistical pricing intelligence ... across public procurement tenders in Spain (PLACSP) and the European Union (TED)'), and explicit output types ('average/median budgets, winning contractor market shares, historical discount rates, and benchmark reference contracts'). This distinguishes it from sibling retrieval tools like get_es_public_tender or search_eu_tenders, which focus on single tenders or search results.
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 clarifies that the tool accepts a tender ID, CPV code, or sector keyword, implying its analytical use case. However, it does not explicitly state when to prefer this over alternatives (e.g., 'Use this instead of get_eu_public_tender when you need pricing intelligence'). The context is clear but lacks direct exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves official statutory corporate registration record from UK Companies House. Returns active status, incorporation date, SIC industry codes, registered office address, registered charges/mortgages count, statutory annual accounts filing health, and next confirmation statement due date in token-optimized Markdown-KV (< 1 KB). Call this during UK vendor due diligence, credit risk audits, and corporate KYB screening.
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| companyNumber | Yes | The 8-character UK Companies House company number (e.g. '00445790' for Tesco PLC, '00002065' for Lloyds Bank). |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond that: it is an 'official statutory' record, token-optimized Markdown-KV under 1 KB, and includes specific data-health signals like filing health and confirmation statement due date.
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, no filler. The first identifies the action and source; the second packs in return content, output format, and use cases efficiently. 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?
Given the rich input schema, strong annotations, and output schema presence, the description covers the essentials: what it returns, why to call it, and the context. Nothing critical is missing for a UK company filing 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?
Schema description coverage is 100%, including spend-control semantics and an example company number. The tool description itself adds no parameter-level meaning beyond pointing to the data source, so 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 ('Retrieves'), a clear resource ('official statutory corporate registration record from UK Companies House'), and lists concrete return fields. It is easily distinguished from sibling tools like get_fr_company_filing or get_uk_company_officers.
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 explicitly names target contexts: 'UK vendor due diligence, credit risk audits, and corporate KYB screening.' It does not mention exclusions or alternatives, but the use cases are clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves complete statutory board of directors, corporate secretaries, and officers from UK Companies House. Returns full active and resigned rosters, official appointment/resignation dates, nationalities, and roles (< 2 KB). Call this for director background checks, executive vetting, and PEP conflict audits.
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| companyNumber | Yes | The 8-character UK Companies House company number (e.g. '00445790', '00041424'). |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context by specifying that it returns complete active and resigned rosters, official dates, nationalities, roles, and a small payload size (<2 KB). No contradiction with 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?
Three short sentences, each earning its place: what the tool retrieves, what it returns, and when to call it. The most important information is front-loaded and there is no filler or repetition.
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 description covers source, return content, and practical use cases, while annotations and the rich schema cover safety and parameter behavior. It is complete enough for a competent agent to select and invoke the tool, though it could offer explicit alternative routing among UK siblings.
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 each parameter already documented, including companyNumber format and forceFresh/maxAgeHours caching behavior. The tool description itself does not add parameter-level semantics, so the baseline score of 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 clearly states the verb 'Retrieves' and the resource: statutory board of directors, corporate secretaries, and officers from UK Companies House. This is a distinct purpose from sibling tools like get_uk_company_filing or get_uk_corporate_network, so an agent can disambiguate 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?
The description explicitly says 'Call this for director background checks, executive vetting, and PEP conflict audits,' which gives clear contexts for use. It does not explicitly name alternatives or say when not to use it, but the stated use cases are practical and specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Maps UK corporate group hierarchies, Persons with Significant Control (PSC / UBO), ultimate beneficial ownership chains, parent companies, and director interlocks (< 2 KB). Computes board resignation turnover ratio and offshore control risk flags. Call this for anti-money laundering (AML) and ultimate beneficial ownership compliance.
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. | |
| companyNumber | Yes | The 8-character UK Companies House company number (e.g. '00445790'). |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by revealing that the tool doesn't just fetch data but computes derived analytics (turnover ratio, risk flags) and gives a response size hint (<2 KB). No contradiction with 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?
Two tightly packed sentences with zero waste: the first lists capabilities and derived metrics, the second states the use case. The most important information (what it does) is front-loaded, and no filler is present.
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 doesn't need to explain return values. It covers the core purpose, derived analytics, and use case. It omits details on cache behavior and surcharges, but those are fully documented in the parameter descriptions, so the description is adequately complete for an agent to decide when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters (including spend-control semantics for forceFresh and maxAgeHours). The description adds no parameter-specific information beyond the schema, so 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 clearly states the tool maps UK corporate group hierarchies, PSC/UBO, ownership chains, parent companies, and director interlocks, and computes derived metrics (board resignation turnover, offshore risk flags). This is specific and distinct from siblings like get_uk_company_filing and get_uk_company_officers, which focus on filings and officers respectively.
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 directs usage for AML and UBO compliance ('Call this for...'), giving clear context. It does not name alternatives or state when not to use it, but the purpose is sufficiently scoped that an agent can infer it's the specialized tool for corporate network analysis among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves authentic US SEC EDGAR statutory filings (Form 10-K annual reports, 10-Q quarterly reports, 8-K material events) by stock ticker symbol or 10-digit CIK (< 1.5 KB). Returns SIC classification code, state of incorporation, fiscal year end, and recent filing accession numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| identifier | Yes | US company stock ticker symbol (e.g. 'AAPL', 'MSFT', 'TSLA') or 10-digit SEC CIK number. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive profile, so the description need not repeat that. It adds behavioral context by asserting the data is 'authentic' SEC EDGAR statutory data, specifying the forms, and noting that returned accession numbers are 'recent' rather than a full history. No contradiction with 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?
Two sentences with no filler; the first sentence front-loads the core action and scope, and the second lists output highlights. The parenthetical '<1.5 KB' is slightly cryptic and the phrase 'Retrieves ... filings' is loose because the tool actually returns metadata/accession numbers, but overall the definition is compact.
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 read-only retrieval tool with 100% schema coverage, an output schema, and rich annotations, the description is nearly complete: it gives jurisdiction, accepted identifiers, form types, and a sense of the returned fields. The only minor gap is ambiguity about whether it returns full filing text vs. metadata, and the meaning of '<1.5 KB' is unexplained.
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 documents identifier, forceFresh, and maxAgeHours fully, including spend-control behavior. The description's 'by stock ticker symbol or 10-digit CIK' merely echoes the identifier property and adds no new parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieves') with a precise resource ('US SEC EDGAR statutory filings'), and enumerates the forms covered (10-K, 10-Q, 8-K). It also names the input as ticker or 10-digit CIK, which clearly separates it from siblings like get_uk_company_filing and get_eu_public_tender.
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 establishes clear jurisdictional context ('US SEC EDGAR') that tells an agent when to select this tool over UK/EU/French filing tools, but it does not explicitly state when not to use it or name an alternative. Sibling names provide enough contrast, so this is clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches Spain's aggregated PLACSP public sector procurement tenders (excludes minor contracts) by keyword, CPV code, contracting authority, or budget range — continuously synced from the official syndication feed into Distil's data moat.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of search results to return (default 5, max 20). | |
| query | No | Free-text search query, project title keyword, or contracting authority. | |
| maxBudget | No | Maximum budget threshold in EUR. | |
| minBudget | No | Minimum budget threshold in EUR. | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not restate safety. It adds valuable behavioral context: the data is aggregated from PLACSP, excludes minor contracts, and is continuously synced from the official syndication feed. It does not detail pagination or return behavior, but the output schema likely covers that.
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 a single, front-loaded sentence that begins with the action and resource, then enumerates the search dimensions and data source. Every clause contributes meaning, and there is no filler or redundant restating of the tool name.
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 six optional parameters, fully described schema, explicit annotations, and an output schema, the description is largely sufficient. It captures scope, exclusions, and data freshness/source. The only notable gap is the lack of explicit routing between this tool and closely related siblings like get_es_public_tender or search_eu_tenders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description's phrase 'by keyword, CPV code, contracting authority, or budget range' groups the parameters semantically, but it adds little beyond the schema text. This matches the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Searches Spain's aggregated PLACSP public sector procurement tenders', and it adds concrete search dimensions (keyword, CPV code, contracting authority, budget range). It distinguishes from siblings such as get_es_public_tender implicitly through the verb 'searches' and plural 'tenders', but it never explicitly names or contrasts that sibling.
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 explicit when-to-use guidance or mention of alternatives. An agent must infer that this tool is for broad search while get_es_public_tender is for retrieving a specific tender. The described scope and filter-by dimensions imply usage context, but the description does not 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.
Searches across European Union TED public procurement tenders by keyword, CPV sector, and member state country code.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tender notices to return (default 5, max 20). | |
| query | Yes | Procurement search keyword, project name, or sector term (e.g. 'Cybersecurity', 'Cloud'). | |
| country | No | Two-letter ISO country code filter (e.g. 'FR', 'DE', 'IT', 'ES', 'NL'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description does not go further to disclose list size, pagination, source freshness, or cost behavior, but it aligns with annotations and adds the registry scope. With annotations carrying the burden, this is adequate but not rich.
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?
Single sentence with no filler; the verb and main resource come first, followed by filter dimensions. Every word carries meaning and no schema content is repeated unnecessarily.
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?
Between the detailed input schema, output schema, and annotations, most invocation concerns are covered. The main gap is the lack of routing guidance among sibling search/get tender tools, but the description plus name make the tool's role recognizable.
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 baseline is 3; the schema already documents query, limit, country, forceFresh, and maxAgeHours precisely. The description adds the 'CPV sector' interpretation of query and the country-code filter, which slightly reinforces but does not significantly expand on 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?
States a specific verb ('Searches'), a specific resource (EU TED public procurement tenders), and the filtering axes (keyword, CPV sector, country code). This clearly distinguishes it from sibling getters like get_eu_public_tender and country-specific search_es_tenders, even without naming them.
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?
No guidance is given on when to choose this tool over siblings such as get_eu_public_tender or search_es_tenders, and no prerequisites or exclusions are mentioned. The intended use must be inferred from the tool name and resource description rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches French enterprises across the INPI / SIRENE National Enterprise Register by corporate name or commercial trade label.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of French companies to return (default 5, max 20). | |
| query | Yes | French company name, commercial trade name, or SIREN number. | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds registry-scope context (INPI / SIRENE), but does not disclose additional behavioral aspects such as caching, freshness behavior, latency, or return characteristics; those are largely delegated to parameter descriptions and the output schema.
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, front-loaded sentence states the action, target, registry, and searchable fields without redundancy. Every phrase contributes to understanding what the tool does.
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 read-only search tool with a rich input schema, comprehensive annotations, and an output schema, this description is complete enough. The registry scope and query intent are clear, and all parameter semantics, spend-control behavior, and safety traits are available in the structured fields.
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 all four parameters are already documented. The description reinforces that query is for company name or trade label, but adds no meaning beyond the schema for limit, forceFresh, or maxAgeHours.
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 the specific verb ('Searches'), resource ('French enterprises'), and authoritative data source ('INPI / SIRENE National Enterprise Register'), and specifies search mode ('by corporate name or commercial trade label'). This clearly distinguishes it from country-specific siblings like search_uk_companies and search_us_companies.
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 its intended use clear: querying French corporate entities by name or trade label. It does not explicitly state when not to use it or name alternative tools for other countries, though the sibling list and country scope make the context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches across official UK registered companies by legal entity name or trade name with live Companies House registry fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching companies to return (default 5, max 20). | |
| query | Yes | Company name, trade name, or partial search term (e.g. 'Barclays', 'Tesco'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, covering the safety profile. The description adds 'live Companies House registry fallback,' which hints at a caching/fallback mechanism but does not explain the dual-mode behavior (cache vs. live) or the associated surcharge. Since annotations carry the safety burden, the added context is minimal but not contradictory.
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 a single, compact sentence that front-loads the core purpose and includes the differentiator (live fallback). It contains no filler or redundant phrases and is well-structured for quick comprehension.
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 output schema and parameter descriptions cover return values and spend-control behavior. The tool description, while concise, conveys the essential purpose and fallback behavior. It could hint more explicitly at the caching/performance trade-off, but that is already captured in the parameter schema, so the description is sufficiently complete for a 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 all parameters (query, limit, forceFresh, maxAgeHours) are fully documented in the schema. The tool description repeats that the search is by legal entity or trade name, which mirrors the query parameter description but adds no new semantic detail. With full schema coverage, the baseline of 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 states a clear verb ('searches'), a specific resource ('official UK registered companies'), and the search basis ('by legal entity name or trade name'). It also mentions a live registry fallback, which differentiates it from similar tools for other countries (e.g., search_us_companies) and from specific getter tools like get_uk_company_filing. The purpose is unmistakable and distinct among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and scope—it is clearly for finding UK companies by name. However, there is no explicit guidance on when to prefer this over alternative search tools (e.g., search_fr_companies) or when to use get_uk_company_filing instead. No exclusions or conditions are stated, so the agent must infer selection from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches US public corporations by stock ticker symbol or company name against official SEC EDGAR submissions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of search results to return (default 5, max 20). | |
| query | Yes | US ticker symbol or partial company name (e.g. 'Tesla', 'NVDA', 'Pfizer'). | |
| forceFresh | No | Spend Control: When true, bypasses Edge KV cache and forces a real-time statutory primary registry call (applies 2.5x Freshness Inconvenience Surcharge). Default: false. | |
| maxAgeHours | No | Spend Control: Maximum acceptable data age in hours (e.g. 48 for 2 days tolerance). If cache satisfies this, delivers sub-5ms at standard 1.0x Economy rate. Set to 0 to force live primary fetch. |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| isError | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is handled elsewhere. The description adds the useful context that the search targets official SEC EDGAR data, but it does not disclose other behavioral traits like pagination, result ordering, or cache/spend behavior beyond what the schema already exposes.
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, front-loaded sentence conveys the essential purpose without any wasted words. It is appropriately sized for a search tool and does not repeat schema or annotation details.
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 low complexity, fully documented schema, rich safety annotations, and existing output schema, the description provides enough context for an agent to select and invoke the tool correctly. It could be marginally stronger by explicitly directing filing-specific requests to get_us_sec_filing, but that is covered by the sibling naming and overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters, including query, limit, forceFresh, and maxAgeHours. The description restates the core query semantics but adds no new meaning beyond the structured 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 uses a specific verb ('Searches'), names the resource ('US public corporations'), and specifies the query dimensions ('stock ticker symbol or company name') against 'official SEC EDGAR submissions.' It clearly distinguishes this search tool from filing-retrieval and non-US siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an agent needs to find US public companies by ticker or name, and the sibling names reinforce that this is the US company search. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as get_us_sec_filing for retrieving specific filings.
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. Dates show when Glama detected each change.
get_corporate_risk_scoreget_cross_border_entity_graphget_es_public_tenderget_eu_public_tenderget_fr_company_filingget_sanctions_and_pep_screeningget_tender_intelligenceget_uk_company_filingget_uk_company_officersget_uk_corporate_networkget_us_sec_filingsearch_es_tenderssearch_eu_tenderssearch_fr_companiessearch_uk_companiessearch_us_companiesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool maps to a distinct data product: country-specific filings, tender records/search, risk scoring, sanctions screening, and entity graphs. The search/get split cleanly separates discovery from retrieval, and even similar country-specific tools are clearly qualified by region and entity type.
All tools use a consistent snake_case verb_noun pattern: get_* for retrieval and search_* for discovery, with country or region qualifiers where applicable. Cross-cutting tools like get_corporate_risk_score and get_tender_intelligence fit the same pattern without feeling out of place.
At 16 tools, the server is slightly above the ideal 3-15 range, but the multi-country, multi-domain scope justifies nearly every tool. The set is heavier than a tightly focused server, yet no tool feels redundant.
The set covers the core read-only workflow well: search to find entities or tenders, get to retrieve records, plus analytical tools for risk, sanctions, and tender intelligence. Minor gaps exist, such as no Spanish company registry access and no UK tender search, but these are workable and do not block primary due-diligence workflows.