find_dataDescribe the data you need in plain language (e.g. 'Apple risk factors 2023', 'is this token a honeypot', 'is this email deliverable', 'read this page'). Searches this server's datasets first, then the whole Professor Sausages catalog, and returns matching endpoints with method, URL, price, and how to call them. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | What you're trying to find or do, in your own words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that it searches local datasets first, then the broader catalog, and returns endpoints with method, URL, price, and call instructions. Also notes the tool is free—useful context not in the 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?
Two sentences with a clear flow and practical examples. Dense but not bloated; every sentence adds value. The examples are numerous but the overall length is appropriate for a discovery tool.
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 no output schema, so the description must explain return value. It fully covers what is returned (matching endpoints with method, URL, price, call instructions), the search order, and pricing. Complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'task' parameter, but the description enriches semantics by framing it as a plain-language request and giving examples. This goes beyond the schema's basic 'in your own words' 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?
Purpose is explicit: find data sources by describing the need in plain language. The description clearly states it searches datasets then the catalog and returns matching endpoints, distinguishing it from sibling tools that perform specific checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides multiple concrete examples of when to use it (e.g., 'Apple risk factors', 'is this token a honeypot') and explains the search scope. It does not explicitly state when not to use it, but the use case is clear enough.
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.
Each tool targets a distinct resource or action: sanctions screening for names, addresses, and vessels; verification for domains, emails, IBANs, phones, and URLs; plus clearly separate meta-tools for discovery, pricing, and requests. Even the closely related sanctions_screen and sanctions_entity have clear separation (search vs. detailed record).
Most tools follow a [noun]_[verb] pattern (address_screen, email_check, url_screen), but there are deviations: domain_intel and sanctions_entity are noun_noun, find_data and request_data are verb_noun, and pricing is a single word. The mixed conventions are still readable but not fully consistent.
With 12 tools, the server is well-scoped for its trust and verification purpose. It covers a broad range of verification types without becoming unwieldy, and the inclusion of meta-tools (pricing, find_data, request_data) adds valuable functionality without bloat.
The surface appears complete for the stated domain: sanctions screening (name, address, vessel), domain intelligence, email/IBAN/phone/URL checks, and supporting discovery/pricing/feedback tools. The request_data tool also provides a mechanism to fill future gaps, making the set comprehensive.