WhiteIntel's price list + the exact machine flow for buying access: one-off dossiers (Standard €39 / Premium €99), packs, subscriptions and the metered API. Returns how_an_agent_buys — buy_dossier opens a Stripe Checkout, claim_dossier mints the token, get_dossier with that token returns the unlocked report. Static, no network — check it before recommending a purchase.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it is 'Static, no network' and reveals the returned flow structure ('how_an_agent_buys' with sub-steps). This goes beyond the annotations, providing meaningful behavioral context about what the tool returns and its execution characteristics.
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 compact—two sentences—with the primary purpose front-loaded. The first sentence states exactly what the tool provides, and the second adds context about its behavior and usage timing. No filler words or redundant 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?
For a tool with no parameters and no output schema, the description covers the return content (pricing and the buying flow) and when to use it. It names the key sub-actions (buy_dossier, claim_dossier, get_dossier) to set expectations. A minor gap is that it doesn't list the exact price figures, but that's not necessary for the agent to decide to call the 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 tool has 0 parameters, so the schema is trivially complete (coverage 100%). The description doesn't need to explain parameters but adds value by describing the output content (price list, flow, and the buy/claim/get sequence). This exceeds the baseline expected for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('WhiteIntel's price list') and a specific action ('the exact machine flow for buying access'), and clarifies its scope by mentioning the purchase flow components (buy_dossier, claim_dossier, get_dossier). This distinguishes it from sibling tools that perform actions on entities or search, making the purpose 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 states when to use it: 'check it before recommending a purchase.' It also notes the tool is 'Static, no network' which implies it's safe and cheap to call. While it doesn't name alternatives or exclusions, the usage context is clear given the tool's unique role as a pricing/flow reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes (search, lookup, get details, graph traversal, coverage maps, payment). Some overlap exists between lookup_company and lookup_by_identifier (both resolve identifiers, though one is UK-specific), and between get_entity vs get_company_details, but descriptions clarify distinctions. find_similar and semantic_search both find similar entities but different mechanisms.
Uses a mix of verb_noun and noun_phrases: buy_dossier, claim_dossier, check_offshore_exposure, find_similar, get_pricing, get_pulse, graph_neighbourhood, list_asset_coverage, lookup_by_identifier, search_entities, trace_ownership_path. While most use underscores and verbs like get/lookup/search/list, there are inconsistencies like 'graph_neighbourhood' (noun start) vs 'trace_ownership_path' (verb start). Overall readable but not perfectly consistent.
23 tools is at the high end but justifiable for a comprehensive intelligence server covering search, lookup, graph, coverage, payments, and entity details. 'buy_dossier' is considered one of the tools and adds bulk but not excessive. It is appropriate for the scope.
Covers a wide range: search (search_entities, search_companies, semantic_search), identifier lookup (lookup_by_identifier, lookup_company), entity details (get_entity, get_company_details, get_financials), graph (graph_neighbourhood, graph_path, trace_ownership_path), coverage maps (list_jurisdictions, list_asset_coverage), sanctions (get_sanctions, check_offshore_exposure), plus payment flow (get_pricing, buy_dossier, claim_dossier, get_payment_link). Missing perhaps a 'get_relationships' separate tool but get_entity includes direct relationships. Also no explicit 'list_entities' but search covers it. Minor gaps like no bulk operations besides resolve.
