Bizfile MCP

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

With no annotations provided, the description carries full burden and delivers substantial behavioral context. It discloses billing details (GBP 0.15/check Pro, GBP 0.125/check Enterprise), API requirements (Paid API key required), data sources (OpenSanctions covering 328 global lists), update frequency (updated daily), privacy policy (We do not log your query content), and legal disclaimers (Results do not constitute a legal determination). However, it doesn't explicitly 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 appropriately front-loaded with core functionality, but it includes extensive ancillary details (billing, legal notices, API terms) that, while informative, could be streamlined. Every sentence adds value, but the overall length might be excessive for quick comprehension, slightly reducing efficiency.

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 (sanctions screening with legal implications), no annotations, and no output schema, the description is highly complete. It covers purpose, usage, behavioral traits (costs, updates, sources), parameter guidance, and output details (returns BLOCK/ENHANCED_DUE_DILIGENCE/PROCEED verdicts with specific sanction programs). This compensates well for the lack of 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 the baseline is 3. The description adds meaningful context beyond the schema: it explains that the 'officers' parameter should be 'the officers array from validate_counterparty directly into this call to screen every director in one go,' providing practical integration guidance. It also implies the 'company_name' parameter is for the company to screen, which aligns with but slightly expands on the schema's description.

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 the tool's purpose: 'screen the company AND all its directors against 328 global sanctions lists simultaneously.' It distinguishes from its sibling tool 'validate_counterparty' by specifying this tool should be called after that one and focuses on sanctions screening rather than validation. The verb 'screen' is specific and the resource 'company and directors' is clearly identified.

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 explicit when-to-use guidance: 'Call this tool after validate_counterparty,' 'Use before issuing any Letter of Credit, processing any payment, signing any contract, or approving any new vendor,' and 'Also use monthly for ongoing monitoring of active counterparties.' It also specifies when-not-to-use by emphasizing that a 'clean company registration means nothing if the beneficial owner is on a sanctions list,' indicating this tool is essential for catching that risk.

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 and does an excellent job disclosing behavioral traits. It explains data sources (UK Companies House, Singapore ACRA, US SEC EDGAR), mentions AI analysis powered by Claude, includes legal notices about informational-only results, and specifies free tier limits (first 20 calls/month, no API key needed). It doesn't mention rate limits or authentication requirements beyond the free tier.

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 comprehensive but verbose and repetitive (e.g., 'NOT a simple database lookup' appears twice, 'AI-powered analysis' is repeated). It includes legal disclaimers and marketing language that could be streamlined. However, the core information is front-loaded with the tool's purpose and usage guidelines appearing early.

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 no annotations and no output schema, the description does an excellent job explaining what the tool returns by listing all return values. It covers data sources, limitations, and usage context thoroughly. The main gap is the lack of an output schema, but the description compensates well by detailing the return structure.

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 doesn't add specific parameter semantics beyond what's already in the schema. While it mentions the tool validates companies, it doesn't provide additional guidance on parameter usage beyond what the schema descriptions already state.

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 the tool's purpose: 'returns a complete counterparty validation package' with specific components like registry lookup, KYC confidence rating, and AI-powered risk score. It clearly distinguishes from sibling 'screen_counterparty' by emphasizing this is NOT a simple database lookup but includes AI analysis for detecting shell companies and high-risk entities.

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 explicit guidance on when to use this tool: 'before your agent onboards any vendor, processes any payment, signs any contract, or begins any business relationship with a company' and 'as the first step in any B2B workflow.' It also includes a strong warning about consequences of not using it: 'every unverified counterparty is a potential fraudster, sanctioned entity, or criminal vehicle.'

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?

Discloses behavior beyond annotations (none provided): no AI call, no officers fetch, no sanctions note, uses UK Companies House, returns specific fields, speed under 1 sec, 60% lower cost, legal notice. No contradictions.

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

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

Front-loaded with purpose and key constraints. Well-structured with bullet-like readability. Slightly long but every sentence adds value. Could be trimmed slightly (legal terms link) but overall 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?

Completely covers what the tool does, when to use, outputs, data source, speed, cost, legal restrictions. No output schema but description lists all return fields. Adequate for a simple registry lookup 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 coverage is 100% with descriptions already explaining parameters. Description adds little extra meaning beyond confirming usage as registry lookup. Baseline 3 is appropriate given schema does the heavy lifting.

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

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

Description specifies verb ('validate'), resource ('counterparty'), and mode ('lite' = registry-only). Clearly distinguishes from sibling 'validate_counterparty' by stating no AI call, no officers fetch, no sanctions note. Lists exact outputs: company status, registration number, KYC confidence, agent_action.

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 states when to use: budget-constrained (<500 tokens), confirming existence before heavier workflow, high-volume pipeline. Also states when not to: not a substitute for full due diligence. Suggests follow-up with validate_counterparty and screen_counterparty if agent_action is PROCEED.

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