31 pay-per-result web data tools: LinkedIn, Google Maps, SEC, real estate, jobs, leads, gov data.
Scored across 31 tools
Most tools target distinct data sources or actions (e.g., scrape_reddit vs search_arxiv), but the lead-generation cluster (find_b2b_leads, find_linkedin_candidates, search_linkedin_employees, find_website_contacts) has overlapping purposes that could confuse an agent choosing the right tool.
All 31 tools use a consistent snake_case verb_noun pattern (e.g., search_zillow, get_linkedin_profiles, verify_emails), with no mixing of camelCase or vague verbs.
31 tools is above the 25-tool threshold for 'too many'; while each tool is a distinct data source, the set is heavy and could overwhelm an agent without a clear grouping or routing mechanism.
The server covers many data-mining verticals (company registries, real estate, jobs, academic, government, social), but lacks a general web search tool and some popular social sources (e.g., X/Twitter, Facebook), leaving minor gaps agents can work around.
Metadata for public GitHub repositories: stars, forks, language breakdown, topics, license, README content, contributor count, latest release, and commit recency. Use to see what a company or project is building. No GitHub token needed.
| Name | Required | Description | Default |
|---|---|---|---|
| repos | Yes | Repos as "owner/name" or full GitHub URLs (e.g. ["anthropics/claude-code"]) | |
| includeReadme | No | Include full README text (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses "No GitHub token needed" and what data is returned, but is silent on rate limits, how invalid/private repos are handled, and any cap on the number of repos per call.
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 tight sentences: the field inventory first, then the use case, then the auth note. The field list is long but each item is meaningful; nothing is padded.
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 no output schema, the description correctly compensates by enumerating returned fields, and both input parameters are covered by the schema. Only edge-case behavior (invalid repos, batch limits) is missing for what is a simple two-parameter read 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%, so both parameters (repos, includeReadme) are already documented in the schema. The description mentions README content among returned fields, loosely implying includeReadme, but adds no syntax or constraint detail beyond the schema. Baseline 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 names the exact resource (public GitHub repositories) and enumerates the concrete data returned: stars, forks, language breakdown, topics, license, README, contributor count, releases, commit recency. No sibling tool touches GitHub, so distinctness is inherent, though the description uses a noun phrase rather than an explicit verb, leaving the action slightly implicit.
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?
"Use to see what a company or project is building" gives a clear situational context for invoking the tool, and the absence of any GitHub-adjacent sibling means there is no alternative to exclude. It stops short of stating when-not-to-use (e.g. private repos, orgs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find B2B leads at target companies: LinkedIn profiles, job titles, and likely business emails. No API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Company names or domains (e.g. ["stripe.com", "notion.so"]) | |
| jobTitles | No | Job title filters (e.g. ["CEO", "Head of Marketing"]) | |
| maxLeadsPerCompany | No | Max leads per company (default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that no API key is required and hedges emails as 'likely' rather than verified, which signals output reliability. It says nothing about rate limits, quotas, cost, data freshness, or what happens with unmatched companies, so the disclosure is partial.
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 short sentences, front-loaded with the core capability and followed by the auth constraint. No filler, no restatement of the tool name, and every clause adds information.
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 3-parameter tool with no output schema and no annotations, the description covers purpose, return contents, and auth requirements at a high level. It omits practical details an agent would want, such as how company names are matched, whether there are caps on the number of companies, and how confident the email guesses are.
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 examples for companies and jobTitles and the default for maxLeadsPerCompany, so the schema fully documents all three parameters. The description adds no syntax, matching behavior, or interpretation guidance beyond the schema, which is the expected baseline when the 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?
States a specific verb and resource (find B2B leads) and enumerates the payload it returns: LinkedIn profiles, job titles, and likely business emails. That is far more concrete than a generic 'find leads'. It does not, however, distinguish itself from close siblings such as find_linkedin_candidates, search_linkedin_employees, or find_website_contacts, so an agent cannot route between them from the description alone.
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 when-to-use guidance, no exclusions, and no named alternative. With several near-identical sibling tools (find_linkedin_candidates, find_website_contacts, verify_emails), the description leaves the agent to guess which tool fits the request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recruiter sourcing: find LinkedIn profiles matching a role, skills, location, experience band, and optional target companies. Returns name, headline, current title and company, profile URL, matched skills, and a match-confidence score. No login needed.
| Name | Required | Description | Default |
|---|---|---|---|
| skills | No | Required skills (e.g. ["Python", "PyTorch"]) | |
| location | No | Location filter (e.g. "Bangalore", "Remote") | |
| maxYears | No | Maximum years of experience | |
| minYears | No | Minimum years of experience | |
| roleTitle | Yes | Role to source for (e.g. "Senior Machine Learning Engineer") | |
| maxResults | No | Max candidates (default 25) | |
| targetCompanies | No | Only return candidates currently at these companies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose 'No login needed' (auth context) and enumerates the returned fields. However, it omits rate limits, result freshness/caching, scraping behavior, and whether results are de-duplicated or how the match-confidence score is derived.
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 tightly packed sentences, front-loaded with the use case and followed by criteria then return values. Little waste, though the return-field enumeration is slightly verbose.
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?
No output schema exists, but the description lists the return fields, and parameters are fully documented in the schema. Auth behavior is noted; the only real gaps are edge-case behavior and match-score semantics, which are minor for a filtered-search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all seven parameters with examples and defaults. The description restates the same criteria without adding syntax or format detail beyond what the schema provides, so baseline 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?
States a specific verb (find) plus resource (LinkedIn profiles) and frames the use case as recruiter sourcing, enumerating the matching criteria (role, skills, location, experience band, target companies). It does not, however, explicitly distinguish itself from close siblings like get_linkedin_profiles or search_linkedin_employees, leaving the agent to infer the difference.
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 opening 'Recruiter sourcing' label implies the scenario but gives no explicit when-to-use or when-not guidance, nor does it point to an alternative sibling. Usage is only loosely implied by the framing and criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl a list of domains and extract business emails, phone numbers, and social profile links (LinkedIn, X, Facebook, Instagram, YouTube) from homepages, contact and about pages. No API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | Domains or URLs to crawl (e.g. ["stripe.com", "notion.so"]) | |
| maxPagesPerSite | No | Pages to crawl per domain (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the crawl scope (homepages, contact and about pages) and the absence of an API-key requirement, which lowers setup friction. However, it says nothing about rate limits, latency, failure modes, or whether the crawl is best-effort, leaving meaningful behavioral gaps.
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 tight sentences that are front-loaded with the core action and scope. Every clause earns its place: the extraction targets and the source page types are exactly the information an agent needs, and nothing is redundant.
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 two-parameter tool with no output schema and no annotations, the description does substantial work by naming the exact fields returned and the page types crawled, effectively standing in for a missing output schema. It falls short only on failure behavior and result volume, which are less critical here.
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 both parameters are already documented in the schema, including the default of 5 pages per site. The description adds no syntax, format, or constraint details beyond that, so the 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 gives a specific verb (crawl) and resource (list of domains), and enumerates the extracted outputs: business emails, phone numbers, and social profile links across five named platforms. It is clear about what the tool does, though it never contrasts itself with sibling lead-generation tools such as find_b2b_leads or verify_emails.
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 statement of when this tool should be preferred over alternatives. The only routing hint is the operational note 'No API key needed,' which speaks to accessibility rather than tool selection. An agent must infer usage purely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get LinkedIn company details: employee count, industry, website, follower count, headquarters, and description. Accepts LinkedIn company URLs, or plain company names (resolved best-effort to a linkedin.com/company slug).
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | LinkedIn company URLs, or company names (e.g. ["https://www.linkedin.com/company/openai", "stripe"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'resolved best-effort' but does not detail rate limits, authentication requirements, error handling, or whether results are read-only. The behavioral transparency is insufficient given the lack of 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 two sentences long, front-loads the key output fields, then explains input format. Every word adds value; 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?
For a simple tool with one parameter and no output schema, the description covers return fields and input formats. It could mention limitations like batch size or error behavior, but the tool has low complexity, so it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema description coverage. The description reinforces the schema by mentioning both URL and name formats. However, it adds minimal new meaning beyond the schema—'resolved best-effort' is a minor addition. 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 gets LinkedIn company details and lists specific fields (employee count, industry, website, etc.). It also indicates accepted input types (URLs or names), distinguishing it from sibling tools like get_linkedin_profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains acceptable inputs but does not provide explicit guidance on when to use this tool versus alternatives (e.g., search_linkedin_employees for employee lists). No when-not-to-use or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full LinkedIn profile details by profile URL: experience, education, skills, headline, and location. No login or cookies needed.
| Name | Required | Description | Default |
|---|---|---|---|
| profileUrls | Yes | LinkedIn profile URLs (e.g. ["https://www.linkedin.com/in/satyanadella"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the auth profile ('No login or cookies needed'), which is the key operational trait for a scraper, but says nothing about rate limits, per-call URL caps for the array input, failure/partial-result behavior, or latency for a batch scrape.
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 no filler. The verb+resource leads, the returned fields follow, and the auth caveat is placed last where it belongs.
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 no output schema, the description compensates by enumerating the returned profile fields, and it covers auth, which is the main operational unknown. It stops short of explaining batch limits for the URL array or error/partial-success behavior, so it is strong but not exhaustive.
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% and the schema already includes a worked URL example, so the parameters are fully documented structurally. The description adds only the phrase 'by profile URL', which restates the schema rather than adding format or constraint detail. Baseline 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?
States a specific verb (Fetch) and resource (full LinkedIn profile details) and enumerates the returned sections: experience, education, skills, headline, location. It also pins the input mode ('by profile URL'), which implicitly separates it from search-based siblings like search_linkedin_employees or find_linkedin_candidates, though no sibling is named outright.
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 rather than stated: an agent can infer this is for retrieving details when it already has profile URLs. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative (e.g. search_linkedin_employees for finding profiles first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect the results of a previously started actor run. Use this when another tool returned status "pending" with a run_id: wait a few seconds, then call this with that run_id. Repeat until it returns results.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | The run_id returned by a tool whose status was "pending" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals that the tool may return a pending status and that results may not be immediate, requiring repeated calls. However, it does not mention error handling, failure scenarios, or rate limits, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the purpose, the second provides usage instructions. It is front-loaded and contains no extraneous words. Every sentence 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 simplicity of the tool (one parameter, polling behavior), the description covers basic purpose and usage. However, it lacks information about the return format or status codes when results are not ready. Since there is no output schema, this gap reduces 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 coverage is 100% and the parameter description already explains it is a run_id from a pending tool. The description adds value by explaining the usage pattern (polling), which enhances the semantic context beyond the schema. The agent learns that the parameter is used in a loop.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Collect the results of a previously started actor run.' It uses a specific verb (Collect) and resource (results of actor run), and distinguishes from sibling tools which are primarily data gathering tools, making it clear this is a result retrieval/polling tool.
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 instructions: 'Use this when another tool returned status "pending" with a run_id.' It also gives a clear procedure: wait a few seconds, call with run_id, repeat until results. This fully guides the agent on how to employ the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Zillow property data from listing URLs or ZPIDs: price history, tax history, school ratings, HOA fee, year built, Zestimate, rent Zestimate, and photos. Chains off search_zillow output.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | Zillow property URLs or raw ZPIDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the accepted input forms (listing URLs or raw ZPIDs) and the returned data set, which is useful, but says nothing about rate limits, batching of multiple URLs, error behavior on bad ZPIDs, or authentication. Adequate but clearly incomplete for a no-annotation tool.
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 capability and its returned fields come first, and the chaining relationship to search_zillow is placed last as the routing cue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description usefully enumerates the returned fields in its place, and it names the upstream tool. It stops short of covering rate limits or failure modes, but for a one-parameter read tool the core information an agent needs is present.
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 single parameter is already documented as "Zillow property URLs or raw ZPIDs"; the description's "from listing URLs or ZPIDs" merely restates it. No added syntax, format examples, or batch-limit guidance, so the baseline 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?
States a specific verb (Fetch) and resource (Zillow property data) and enumerates the exact payload an agent gets back: price history, tax history, school ratings, HOA fee, year built, Zestimates, photos. It also distinguishes itself from the sibling search_zillow by declaring that it chains off that tool's output, so an agent can route correctly without opening either schema.
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?
"Chains off search_zillow output" gives clear usage context: call this after search_zillow to expand a listing into full details. What is missing is any when-not guidance (e.g. don't call with non-Zillow URLs, batching expectations), but the positive routing signal is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a company Legal Entity Identifier (LEI) in the official GLEIF registry by legal name. Returns LEI code, registration status, legal address, and entity status. The authoritative source for checking that a company legally exists.
| Name | Required | Description | Default |
|---|---|---|---|
| legalNames | Yes | Company legal names (e.g. ["Apple Inc."]) | |
| matchesPerName | No | Max matches per name (default 3) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the external source (GLEIF registry) and the returned fields, which is helpful, but says nothing about read-only semantics, rate limits, auth needs, or not-found behavior.
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 tight sentences, front-loaded with the verb+resource and then the return fields. Efficient, though the final value-statement sentence is somewhat promotional.
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 no output schema, the description steps in to name the returned fields (LEI code, status, address), which is what an agent needs. Minor gaps around failure modes and result limits, but adequate for a two-param read lookup.
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 both parameters are already documented in the schema. The description only restates the lookup key ('by legal name') and adds no extra meaning for legalNames or matchesPerName, making the baseline 3 correct.
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 (look up) and resource (LEI in the official GLEIF registry) plus the lookup key (legal name). It is clearly distinguishable from siblings like resolve_company_identity or search_companies_house_uk, which target different registries.
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 line 'The authoritative source for checking that a company legally exists' gives an implied use case, but there is no explicit when-not guidance and no routing to alternatives such as resolve_company_identity. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a company name to its identifiers across registries in one call: GLEIF LEI, legal name, country, entity status, and SEC EDGAR CIK plus last filing date. Use to ground company facts before trusting them.
| Name | Required | Description | Default |
|---|---|---|---|
| companies | Yes | Company names (e.g. ["Apple Inc", "Lockheed Martin"]) | |
| countryCode | No | Optional ISO country code filter (e.g. "US") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It helpfully discloses the returned field set, which is valuable because there is no output schema, and the word 'Resolve' implies a read-only lookup. But it omits batch semantics for the array input (one result per name or merged?), behavior on unmatched names, and any auth or rate-limit constraints.
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 tight sentences: the capability and covered registries come first, the intended usage follows. No filler, no restatement 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 no annotations and no output schema, the description compensates well by enumerating the resolved fields. The remaining gap is batch behavior for the array input, which an agent would need to know before passing multiple company names.
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 both 'companies' (with examples) and the optional ISO 'countryCode' filter. The description's field list describes outputs rather than adding parameter meaning, and says nothing about how countryCode narrows or biases the resolution. 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?
States a specific verb ('Resolve') and resource ('company name') and enumerates exactly what comes back: GLEIF LEI, legal name, country, entity status, SEC EDGAR CIK, last filing date. This clearly separates it from narrower siblings such as lookup_lei (LEI only) or search_sec_filings, so an agent can pick it without opening a schema.
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 second sentence, 'Use to ground company facts before trusting them,' gives genuine usage context for the resolution step. However, it names no alternatives or exclusions, so an agent cannot tell when to prefer this over lookup_lei or search_companies_house_uk, which both address overlapping registry data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape job listings from company ATS boards: Greenhouse, Lever, Workday, and Ashby. Reads their public job APIs, so no login is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company slug as used in their ATS URL (e.g. "stripe" for boards.greenhouse.io/stripe) | |
| platform | No | ATS platform (default: auto-detect) | |
| maxResults | No | Max jobs (default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the auth profile ('reads their public job APIs, so no login is needed'), which is real added value, but says nothing about rate limits, failure behavior, pagination, or what the scrape returns.
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 tight sentences with the core purpose front-loaded and the useful no-login constraint appended. 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?
For a no-annotation, no-output-schema scraper, the description covers purpose, platforms, and auth but omits return shape and operational limits that an agent calling a scraping tool would benefit from. It is adequate but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents company slug format, the platform enum, and maxResults default. The description adds nothing about parameter semantics (e.g., how 'auto' detection resolves), so the baseline 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?
States a specific verb (scrape) and resource (job listings from company ATS boards) and enumerates the four supported platforms, which implicitly distinguishes it from generic job-search siblings like search_linkedin_jobs. It lacks an explicit contrast against those siblings, keeping it just below a 5.
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 platform list and the note that no login is needed, so an agent can infer this is for pulling a specific company's postings without auth. However, there is no explicit when-to-use vs. alternatives guidance (e.g., versus search_linkedin_jobs) and no when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape Reddit posts and comments by subreddit, keyword search, or post URL. Returns full post data with comment trees.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Scrape mode | |
| query | No | Search query (for search mode) | |
| postUrl | No | Reddit post URL (for post mode) | |
| username | No | Reddit username (for user mode) | |
| subreddit | No | Subreddit name without r/ prefix (for subreddit mode) | |
| maxResults | No | Max posts (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it returns 'full post data with comment trees', but omits behavioral details like rate limits, authentication requirements, error handling, or whether it respects Reddit's API policies.
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 concise, front-loaded sentences. Every word adds value. No redundancy 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?
Given complexity (6 params, 4 modes) and no output schema, the description is minimally adequate. It states return type but lacks guidance on usage context, error scenarios, or edge cases. Could benefit from mentioning output structure or limitations.
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 no parameter-specific information beyond what the schema already provides. The enum for mode is described in schema, and description only restates some modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scrape Reddit posts and comments by various modes. It specifies the verb ('scrape'), resource ('Reddit posts and comments'), and methods ('subreddit, keyword search, or post URL'), distinguishing it from sibling tools which focus on other platforms.
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 explicit guidance on when to use this tool versus alternatives (e.g., when to use scrape_reddit vs search or other scraping tools). The different modes are implied but not explained in terms of use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape Trustpilot reviews for any company. Returns reviewer name, star rating, review title, body, date, and verified status.
| Name | Required | Description | Default |
|---|---|---|---|
| companyUrl | Yes | Company domain (e.g. "stripe.com") or its Trustpilot URL (e.g. "https://www.trustpilot.com/review/stripe.com") | |
| maxResults | No | Max reviews (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It explains what is scraped but omits details like rate limiting, authentication requirements, IP blocking risks, or pagination behavior. The listed return fields are helpful but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with action and resource, then immediately lists output fields. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately lists return fields. However, it lacks usage guidelines and behavioral context. For a scraping tool, missing information on reliability, source, and constraints reduces 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 coverage is 100% and parameters are well-described in the schema. Description does not add significant meaning beyond what the schema provides for 'companyUrl' and 'maxResults'. The mention of return fields is about output, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'scrape', resource 'Trustpilot reviews', and explicitly lists returned fields ('reviewer name, star rating, review title, body, date, and verified status'). It distinguishes from siblings like 'scrape_reddit' and 'scrape_ats_jobs' by specifying the target platform.
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 on when to use this tool versus alternatives. The description only says 'for any company' without context on prerequisites, limitations, or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arXiv preprints by keyword or category. Returns title, abstract, authors, and PDF link. Best for AI, CS, physics, and biology research.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword or phrase | |
| category | No | arXiv category (e.g. "cs.LG", "cs.AI", "cs.CL", "quant-ph", "q-bio.GN") | |
| maxResults | No | Max papers (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only describes the function and output, but does not disclose any behavioral traits such as rate limits, authentication requirements, or impact on data sources.
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 consists of two concise, front-loaded sentences with no unnecessary words. Every sentence adds value: the first states the action and returns, the second provides context for use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description adequately covers the purpose, return content, and best-use domains. It lacks details on pagination, sorting, or error handling, but the core information is sufficient for basic usage.
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 three parameters. The description adds minimal extra meaning beyond the schema, mainly repeating the keyword/category concept. 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 action ('Search arXiv preprints') and the resource ('arXiv preprints'), specifies the returned fields (title, abstract, authors, PDF link), and distinguishes from sibling tools by mentioning the domains it is best for (AI, CS, physics, biology).
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 usage context ('Best for AI, CS, physics, and biology research'), helping the agent decide when to use this tool. However, it does not explicitly mention when not to use it or suggest alternative tools for other domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search or look up UK companies on the official Companies House register: status, type, incorporation date, registered office address, SIC codes, and optionally the full officer roster. Needs your own free Companies House API key.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Company name/keyword search. Use this OR companyNumbers. | |
| apiKey | Yes | Your free Companies House REST API key. Register an application at developer.company-information.service.gov.uk. | |
| maxResults | No | Max companies to return (default 50) | |
| companyNumbers | No | Exact UK company numbers for direct lookup (e.g. ["09446231"]) | |
| includeOfficers | No | Fetch the officer roster (directors, secretaries) for each company (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implies a read-only lookup and discloses the API-key requirement plus the data shape, but omits rate limits, pagination behavior beyond maxResults, and error conditions (e.g., invalid key). Adequate but with clear gaps for an unannotated tool.
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 compact sentences with no waste, and the core purpose and returned fields are front-loaded before the API-key note. Efficient, though the field enumeration slightly crowds the leading sentence.
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 5-parameter search tool with no output schema and no annotations, the description covers purpose, key prerequisite, and the shape of returned data. It would be stronger with sibling routing or rate-limit context, but nothing essential to invoking it correctly 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%, so the schema already documents every parameter including the query/companyNumbers choice and includeOfficers. The description only restates the officer roster option, adding no syntax or format detail beyond the schema, which is the correct baseline when the 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?
States a specific verb (search/look up) and resource (UK companies on the official Companies House register), and enumerates the data fields returned. It is distinguishable from siblings in spirit, but it never explicitly names alternatives like lookup_lei or resolve_company_identity, so differentiation is implicit rather than stated.
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 supplies a concrete prerequisite ("Needs your own free Companies House API key"), which is genuine usage context. However, it gives no when-to-use vs when-not guidance and does not point to any of the many sibling lookup tools, so an agent must infer the appropriate case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search US federal campaign finance via the official OpenFEC API: candidates by name, committees and PACs by name, or itemized Schedule A contributions for one committee.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | candidates/committees search by name; contributions pulls itemized donations for one committee | |
| query | No | Name to search for candidates/committees modes (e.g. "Warren") | |
| apiKey | No | Your free api.data.gov key. Falls back to FEC's public DEMO_KEY (rate-limited) if omitted. | |
| maxResults | No | Max rows to return (default 25) | |
| committeeId | No | FEC committee ID (e.g. "C00401224"), required for contributions mode. Find it via committees mode first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It mentions the official OpenFEC API as the source, which is useful, but omits any disclosure of read-only nature, rate limits, authentication requirements, or pagination behavior. The schema covers API key details, but the description adds little beyond the data source.
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 sentence, front-loaded with the core purpose and efficiently enumerating the three modes. No wasted words.
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 (5 parameters, one enum, no output schema, no annotations), the description covers the essentials but leaves gaps. It does not mention the prerequisite for contributions mode (committeeId) or the API key fallback, though the schema handles those. It could better prepare an agent for edge cases.
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 are already well documented. The description restates the mode meanings but adds no new syntactic or semantic detail beyond what the schema provides. 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 states a specific verb ('Search') and resource ('US federal campaign finance') and then clarifies the three distinct modes with concrete examples. It is immediately clear what the tool does, and no sibling tool overlaps in domain.
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 domain-specific purpose—use it when seeking federal campaign finance data—but there is no explicit when-to-use, when-not, or alternatives guidance. The mode descriptions offer some context but do not tell the agent when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Google Maps business listings by keyword and location. Returns name, category, address, phone, website, rating, review count, opening hours, and coordinates. No login, no Google Maps API key. Usually returns pending first; collect with get_run_results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for (e.g. "dentists", "coffee shops") | |
| location | No | Where to search (e.g. "Austin, TX", "Bangalore") | |
| maxResults | No | Max listings (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the auth model (no login, no Google Maps API key), the asynchronous/pending-first behavior, and the exact output fields. It omits rate limits, pagination beyond maxResults, and any failure/empty-result semantics, keeping it short of a 5.
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 tight sentences: purpose and scope first, then output fields, then the async/polling caveat. No filler, no repetition of the tool name, and the operational warning is placed where an agent will see it before invoking.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by listing every returned field (name, category, address, phone, website, rating, review count, hours, coordinates). Combined with the async hand-off to get_run_results and the no-auth note, an agent has everything needed to call and collect results 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%, so query, location, and maxResults are already fully documented with examples and a default. The description's phrase 'by keyword and location' adds no syntax or format meaning beyond the schema, so the baseline 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?
States a specific verb ('Search') and resource ('Google Maps business listings') scoped by keyword and location, which cleanly separates it from siblings like search_zillow, search_realtor, and search_indiamart_suppliers. The return-field list further confirms what kind of data this tool produces.
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 the preconditions (no login, no API key) and the follow-up workflow ('Usually returns pending first; collect with get_run_results'), naming the sibling to use. It stops short of stating when NOT to use this tool versus other business-listing searches, so it is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Google Trends interest data for up to 5 keywords. Returns interest over time, geographic breakdown, and related queries.
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | Country code (e.g. "US", "IN", "GB"). Leave empty for worldwide. | |
| keywords | Yes | Keywords to compare (1-5 terms) | |
| timeRange | No | Time range: "today 3-m", "today 12-m", "today 5-y" | today 12-m |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description bears full responsibility for behavioral transparency. It describes outputs (interest over time, geographic breakdown, related queries) but does not disclose performance characteristics, rate limits, data freshness, or any potential limitations beyond the parameter constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the core action and immediately state the key outputs. Every word serves a purpose, with no extraneous information.
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 three parameters and no output schema or annotations. The description adequately outlines the tool's purpose and high-level output categories, but lacks detail on how to interpret the returned data or any examples. It is sufficient for simple use cases but could be more complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, achieving 100% coverage. The description adds minimal extra meaning by restating the keyword limit (up to 5) and listing what data is returned, but does not elaborate on parameter usage beyond what the schema provides. Per guidelines, 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's function: 'Get Google Trends interest data for up to 5 keywords.' It specifies the resource (Google Trends) and the action (get data), and distinguishes itself from sibling search tools by focusing on Google Trends specifically.
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 no guidance on when to use this tool versus alternatives like search_google_maps or search_crunchbase. It does not mention when to use or avoid this tool, nor does it compare with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search IndiaMART for B2B suppliers and manufacturers in India. Returns company name, products, location, contact details, and ratings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Product or supplier search query (e.g. "stainless steel pipes manufacturer") | |
| maxResults | No | Max suppliers (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states return values but does not mention read-only nature, authentication needs, rate limits, or error handling. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists return fields. No redundancy, highly 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?
For a simple search tool with 2 well-documented parameters and no output schema, the description covers the core purpose and return data. Missing context like authentication or rate limits, but sufficiently complete given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about return fields but does not clarify parameter details beyond the schema. Adequate but not enhanced.
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 searches IndiaMART for B2B suppliers and manufacturers in India, specifying the resource and scope. It also lists return fields (company name, products, location, contact details, ratings), distinguishing it from siblings that search other platforms.
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 no guidance on when to use this tool versus alternatives like find_b2b_leads or other platform-specific searches. No explicit when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find employees at a company on LinkedIn. Returns name, headline, location, and profile URL. Uses Google's index, so no LinkedIn login or cookies are needed.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name (e.g. "Stripe", "Notion") | |
| jobTitle | No | Optional job title filter (e.g. "Head of Marketing", "CTO") | |
| maxResults | No | Max profiles to return (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the mechanism ('Uses Google's index, so no LinkedIn login or cookies are needed'), which is real value for an agent assessing auth requirements and reliability. It stops short of covering result quality, rate limits, pagination, or failure behavior.
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, front-loaded with the core action, then return fields, then the auth/data-source caveat. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, listing the return fields (name, headline, location, profile URL) is a genuine and necessary addition, and the auth note covers a common concern. Still missing pagination/truncation behavior and sibling disambiguation for a tool in a crowded LinkedIn namespace.
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 three parameters (company, jobTitle, maxResults) are already documented in the schema. The description adds no format or syntax meaning beyond that, making the baseline 3 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?
States a specific verb and resource ('Find employees at a company on LinkedIn'), which is clear and actionable. However, it does not distinguish itself from close siblings like find_linkedin_candidates or get_linkedin_profiles, leaving the agent to guess which LinkedIn people-search tool applies.
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 on when to use this tool versus alternatives. The description never mentions find_linkedin_candidates or get_linkedin_profiles, nor any conditions, prerequisites, or exclusions, so selection between the several LinkedIn tools is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LinkedIn job listings by keyword and location. Returns job title, company, location, seniority, and applicant count. No login needed.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Job title or skill (e.g. "machine learning engineer") | |
| location | No | Location filter (e.g. "San Francisco", "Remote", "India") | |
| maxResults | No | Max listings (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses return fields (title, company, location, seniority, applicant count) and that no authentication is required, but says nothing about rate limits, pagination, or result freshness.
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 compact sentences, front-loaded with the action and scope, then return fields, then the auth note. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter search with no output schema, the description covers the action, filter axes, return fields, and the no-login precondition. It is largely self-sufficient, though pagination and result-count behavior go unmentioned.
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 three parameters are already documented with examples. The description only echoes 'by keyword and location' and adds no format, defaulting, or filtering nuance beyond what the schema provides; baseline 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?
States a specific verb (Search) and resource (LinkedIn job listings) with the filtering axes named. It is clearly distinct from siblings like search_linkedin_employees or search_linkedin_posts, but it never explicitly distinguishes itself from other job sources such as search_naukri_jobs or scrape_ats_jobs.
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 when-to-use or when-not-to-use guidance and no routing to alternatives. With siblings like search_naukri_jobs and scrape_ats_jobs covering similar job-search ground, an agent gets no help deciding which source to pick; only 'No login needed' hints at an operational precondition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LinkedIn posts by keyword. Returns post snippet, author name, headline, and profile URL. Uses Google's index, so no LinkedIn login is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword or phrase to search for in LinkedIn posts | |
| maxResults | No | Max posts (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers the two facts that matter most: the retrieval mechanism ('Uses Google's index') and the auth posture ('no LinkedIn login is needed'), plus the shape of the response. It stops short of noting index-coverage/freshness limitations or pagination behavior, which would be the remaining behavioral risks.
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, front-loaded with purpose, then return contents, then the mechanism/auth caveat. Every sentence carries information the agent needs, including the return fields that no output schema supplies.
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 no output schema, the description compensates by enumerating returned fields (snippet, author, headline, profile URL), and with full schema coverage the inputs need no further prose. It is only slightly short of complete because it does not warn about the coverage/freshness limits inherent in scraping Google's index.
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% for both parameters (query and maxResults with its default), so the schema already documents the inputs fully; the description adds no syntax, quoting, or matching-behavior detail. Baseline 3 is appropriate when the 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?
States a specific verb and resource ('Search LinkedIn posts by keyword') and immediately names the returned fields, so an agent can distinguish it from nearby siblings like search_linkedin_employees, search_linkedin_jobs, and get_linkedin_profiles without opening any schema.
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 resource ('posts') and the note that no LinkedIn login is required, which tells the agent this works without credentials. However, there is no explicit when-to-use/when-not-to-use guidance and no routing to alternatives such as find_linkedin_candidates or get_linkedin_profiles when a person or company lookup is actually wanted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Naukri.com for job listings in India. Returns job title, company, location, salary range, experience required, and description.
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Job title or skills (e.g. "Python developer", "product manager") | |
| location | No | City or region (e.g. "Bangalore", "Mumbai", "Remote") | |
| maxResults | No | Max jobs (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adequately states the tool returns specific job fields, which implies a read-only search operation. However, it does not disclose potential rate limits, pagination behavior, or result ordering. A score of 3 reflects adequate but minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It effectively conveys the tool's purpose and return data. This level of conciseness is optimal for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a reasonable set of information: it states the source (Naukri.com), geographic scope (India), and returned fields. It does not mention result limits beyond the maxResults default or any API specifics, but it is largely complete for a straightforward search tool. A score of 4 indicates it is slightly above adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the parameters (keywords, location, maxResults). It does mention return fields, which is helpful context but not parameter-specific. The schema descriptions are sufficient, hence a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Naukri.com for job listings in India and lists specific return fields (title, company, location, salary, experience, description). This verb+resource combination effectively distinguishes it from sibling tools like search_linkedin_jobs (LinkedIn) and scrape_ats_jobs (ATS scraping).
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 usage for Indian job searches on Naukri.com but provides no explicit guidance on when to use this tool over alternatives. Sibling tool names are listed in context, but the description itself lacks directives like 'Use this for Indian Naukri jobs; for global jobs use search_linkedin_jobs.' A neutral score of 3 is appropriate as the usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search NIH RePORTER for grant awards by topic, agency, or institution. Returns project title, abstract, award amount, PI names, and institution.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Research topic or keyword (e.g. "CRISPR gene therapy cancer") | |
| agency | No | NIH agency code (e.g. "NCI", "NIAID", "NHLBI") | |
| maxResults | No | Max grants (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. Beyond stating it searches for grants, it offers no behavioral details such as rate limits, authentication requirements, or what happens when no results are found. The description adds minimal transparency beyond the basic functionality.
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 purpose and immediately follows with the output details. Every word adds value, with no redundancy 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?
For a search tool with three parameters and no output schema, the description adequately covers what is searched (grants), how to search (by topic, agency, institution), and what is returned. Missing details like pagination or error handling are acceptable for a simple 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 coverage is 100%, providing baseline parameter descriptions. The description adds value by listing the returned fields (title, abstract, award amount, PI, institution), which helps the agent understand what data to expect from the query. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool searches NIH RePORTER for grant awards, with clear specification of the resource (NIH RePORTER), action (search), and returned fields (title, abstract, award amount, PI names, institution). This clearly distinguishes it from sibling tools like search_pubmed (biomedical literature) or search_arxiv (preprints).
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 usage for grant searches but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Sibling tool names hint at different domains (e.g., grants vs. literature or jobs), but no direct comparison or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed for biomedical literature. Returns PMID, title, abstract, authors, journal, and DOI. 36M+ articles indexed.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | PubMed search query (e.g. "GLP-1 cardiovascular outcomes clinical trial") | |
| maxResults | No | Max articles (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description adds context about return fields and index size (36M+ articles). However, it lacks disclosure of rate limits, authentication needs, or handling of large queries.
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 concise sentences: first states purpose, second lists return fields and scale. No unnecessary words, front-loaded with key information.
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 simple search tool with no output schema or nested objects, the description covers purpose, return fields, and index size. It lacks behavioral details like pagination or result limits, but is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage; parameters are well-described. The tool description does not add extra meaning beyond the schema, so baseline score is 3.
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 tool clearly states it searches PubMed for biomedical literature and lists return fields (PMID, title, etc.). It is distinct from siblings like search_arxiv and search_nih_grants, but does not explicitly differentiate.
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 usage for biomedical literature searches with an example query, but provides no guidance on when to use this tool versus alternatives like search_arxiv (preprints) or search_nih_grants (grants).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Realtor.com for-sale or sold listings by city or ZIP. Returns price, beds, baths, sqft, county, listing status, and the listing agent and brokerage office for every record. No MLS login.
| Name | Required | Description | Default |
|---|---|---|---|
| minBeds | No | Minimum bedrooms | |
| location | Yes | City or ZIP (e.g. "Austin, TX") | |
| maxItems | No | Max properties (default 50) | |
| maxPrice | No | Maximum price | |
| minPrice | No | Minimum price | |
| soldMode | No | Return sold listings instead of for-sale (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral burden well by listing returned fields and noting sold mode via soldMode parameter. However, it omits potential rate limits, data freshness, and geographic scope (US only).
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 concise sentences front-load the core action and return data, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists return fields and key parameters. Missing details on pagination or error handling, but still sufficient for a straightforward 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 coverage is 100%, so the description adds marginal value beyond schema. It restates 'city or ZIP' and 'for-sale or sold' but does not deepen understanding of minBeds, maxPrice, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Realtor.com for-sale or sold listings by city or ZIP, specifies returned fields (price, beds, baths, etc.), and distinguishes from siblings like search_zillow and search_redfin by targeting Realtor.com.
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 indicates usage via city/ZIP and mentions 'No MLS login' for ease, but does not explicitly advise when to choose this tool over siblings (e.g., search_zillow) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Redfin for-sale or recently-sold listings by city, ZIP, or Redfin URL. Returns price, beds, baths, sqft, price per sqft, listing agent, broker, MLS ID, and listing URL. Use soldWithinDays for comparable-sales analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| minBeds | No | Minimum bedrooms | |
| location | Yes | City, ZIP, or Redfin URL | |
| maxItems | No | Max properties (default 50) | |
| maxPrice | No | Maximum price | |
| minPrice | No | Minimum price | |
| soldWithinDays | No | Return recently-sold within N days (7-365) instead of for-sale |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists return fields but does not disclose behaviors like pagination, data freshness, rate limits, or authentication requirements. This is insufficient for a tool with 6 parameters.
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 very short (2 sentences), front-loaded with the core action, and contains no unnecessary words. Every sentence 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 6 parameters and no output schema, the description covers the main function and one key parameter use case. It does not explain filtering options like minBeds or maxPrice, but the schema covers those. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema, only highlighting that soldWithinDays enables recently-sold searches.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Redfin for-sale or recently-sold listings by city, ZIP, or URL, and lists return fields. However, it does not explicitly differentiate from sibling tools like search_zillow or search_realtor, which provide similar functionality.
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 gives one specific use case ('Use soldWithinDays for comparable-sales analysis'), but does not provide guidance on when to use this tool vs alternatives or 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.
Search live US federal contract opportunities on SAM.gov: solicitations, presolicitations, sources-sought, and award notices. Filter by keyword, NAICS code, notice type, agency, and set-aside type. Needs your own free SAM.gov / api.data.gov API key.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | Yes | Your free SAM.gov / api.data.gov API key. Get one at sam.gov (Account Details -> API Key) or api.data.gov/signup. | |
| keyword | No | Full-text search on the opportunity title (e.g. "software") | |
| postedTo | No | Latest posted date. Defaults to today. | |
| naicsCode | No | NAICS industry code, up to 6 digits (e.g. "541511") | |
| maxResults | No | Max opportunities to return (default 100) | |
| noticeType | No | Procurement type code: o=Solicitation, p=Presolicitation, r=Sources Sought, a=Award Notice, k=Combined Synopsis, s=Special Notice, g=Sale of Surplus, u=Justification, i=Intent to Bundle | |
| postedFrom | No | Earliest posted date, MM/DD/YYYY or YYYY-MM-DD. Defaults to 30 days ago. | |
| setAsideType | No | Set-aside code (e.g. "SBA", "8A", "WOSB", "HZC") | |
| organizationName | No | Department/sub-tier name (e.g. "DEPARTMENT OF DEFENSE") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses an authentication requirement (your own free API key), which the schema only partially signals, and 'live' implies fresh data. However, it says nothing about rate limits, result caps, pagination, or failure modes for a 100-default multi-result query - a meaningful gap with zero annotation coverage.
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 tight sentences with zero waste: purpose and coverage first, filter dimensions second, the API-key prerequisite last. Every clause earns its place and nothing is buried.
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 fully documented 9-parameter schema and no output schema, the description covers purpose, filter scope, and the auth prerequisite adequately. The remaining gap is return-shape and result-volume behavior, but with maxResults and date defaults already documented in the schema, this is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the 9 parameters (including date defaults and the noticeType code list) is already fully documented in the schema. The description restates the filter categories but adds no syntax, format, or interaction detail beyond what the schema provides, so the baseline 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?
States a specific verb (Search) and resource (live US federal contract opportunities on SAM.gov), then enumerates the notice types covered (solicitations, presolicitations, sources-sought, award notices) and the filter dimensions. No sibling tool shares this domain, so the resource alone cleanly differentiates it from search_sec_filings, search_nih_grants, and the rest.
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?
Gives clear context for use - filtering contract opportunities by keyword, NAICS, notice type, agency, and set-aside - and states the key prerequisite that the caller must supply their own free SAM.gov / api.data.gov API key. It does not spell out when NOT to use it or name alternatives, but no sibling overlaps this domain, so that omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across SEC EDGAR filings: 10-K, 10-Q, 8-K, and more. Returns filing metadata and matched text excerpts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. "artificial intelligence risk" or company name) | |
| dateFrom | No | Filter filings from this date (YYYY-MM-DD) | |
| filingType | No | Filing type filter (e.g. "10-K", "8-K", "10-Q") | |
| maxResults | No | Max filings (default 25) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions returns metadata and excerpts, but no details on limitations, rate limits, pagination, or error behavior. Since no annotations, this is insufficient for a search tool.
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 brief sentences conveying purpose and output. No superfluous words, front-loaded with key information.
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?
Missing details on return format, pagination, query syntax, and date range of filings. With 4 parameters and no output schema or annotations, description should provide more 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 covers all parameters with descriptions; tool description adds no extra meaning beyond listing example filing types. Baseline 3 due to 100% 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?
Description clearly states full-text search across SEC EDGAR filings with specific filing types (10-K, 10-Q, 8-K). Distinguishes from siblings which cover other domains like arXiv, Crunchbase, LinkedIn.
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?
Implies usage when needing SEC filing search, but no explicit guidance on when not to use or comparisons to sibling tools like resolve_company_identity or search_crunchbase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Zillow for-sale or rental listings by city, ZIP, or neighborhood. Returns price, beds, baths, sqft, address, coordinates, and listing URL. No API key.
| Name | Required | Description | Default |
|---|---|---|---|
| minBeds | No | Minimum bedrooms | |
| location | Yes | City, ZIP, or neighborhood (e.g. "Austin, TX", "78701") | |
| maxItems | No | Max properties (default 50) | |
| maxPrice | No | Maximum price | |
| minPrice | No | Minimum price | |
| daysOnZillow | No | Only listings posted within this many days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states 'No API key' but lacks details on rate limits, data freshness, caching, or restrictions (e.g., geographies covered). The read-only nature is implied but not explicitly stated, and no error behavior is described.
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?
Description is concise, with three sentences each adding information: first sentence defines purpose, second lists returned fields, third notes no API key. No unnecessary words.
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 search tool with 6 parameters and no output schema, the description provides a list of returned fields which partially compensates for missing output schema. However, it lacks details on sorting, pagination (maxItems is described in schema), and whether both for-sale and rental are searched simultaneously or need separate calls.
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. The description adds marginal value by listing return fields (price, beds, baths, sqft, address, coordinates, URL) but does not enhance parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Search', resource 'Zillow for-sale or rental listings', and acceptable location inputs. It distinguishes from sibling real estate tools like search_realtor and search_redfin by specifically mentioning Zillow.
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?
Description implies use for searching Zillow listings and mentions 'No API key' as an advantage, but does not provide explicit guidance on when to use this tool over siblings like search_realtor or search_redfin, nor does it mention any limitations or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk-verify email addresses: syntax, MX records, SMTP deliverability, disposable-domain and role-based detection. Use before sending outreach so you only contact addresses that exist.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to verify | |
| checkSmtp | No | Run SMTP deliverability probe (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the verification depth (syntax → MX → SMTP probe → disposable/role detection), which is real context, but omits operational traits that matter for a network-probing tool: rate limits, latency, cost, and whether SMTP probing can be blocked or produce false negatives.
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, zero waste. The capability list is front-loaded and the usage cue follows immediately, so an agent can skim and act.
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 no output schema and no annotations, the description should say something about what verification returns (valid/invalid, reason codes, risk categories), especially since the enumerates disposable and role-based detection flags that presumably surface in results. That gap plus the missing cost/latency context leaves the definition adequate but incomplete.
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% – both parameters are documented, including the checkSmtp default of true. The description's mention of 'SMTP deliverability' implies what checkSmtp toggles, and 'bulk' implies array input, but neither adds syntax or format detail beyond the schema. 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?
States a specific verb (bulk-verify) and resource (email addresses) and enumerates the exact checks performed: syntax, MX, SMTP deliverability, disposable-domain and role-based detection. No sibling tool does email verification, so it is unambiguous within this toolset.
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?
Gives an explicit when-to-use condition: 'before sending outreach so you only contact addresses that exist.' There are no direct alternatives among the siblings, so no exclusions are needed, but it also says nothing about when NOT to bother (e.g. obviously malformed input) or about cost/latency tradeoffs.
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.
search_crunchbasesearch_fec_campaign_finance1 field changedInput schema / properties / committeeId / descriptionPrevious value: -"FEC committee ID (e.g. \"C00401224\") - required for contributions mode. Find it via committees mode first."New value: +"FEC committee ID (e.g. \"C00401224\"), required for contributions mode. Find it via committees mode first."search_companies_house_uksearch_fec_campaign_financesearch_sam_gov_contractsanalyze_github_reposfind_b2b_leadsfind_linkedin_candidatesfind_website_contactsget_linkedin_companyget_linkedin_profilesget_run_resultsget_zillow_property_detailslookup_leiresolve_company_identityscrape_ats_jobsscrape_redditscrape_trustpilotsearch_arxivsearch_crunchbasesearch_google_mapssearch_google_trendssearch_indiamart_supplierssearch_linkedin_employeessearch_linkedin_jobssearch_linkedin_postssearch_naukri_jobssearch_nih_grantssearch_pubmedsearch_realtorsearch_redfinsearch_sec_filingssearch_zillowverify_emailsReal-world market data for AI agents: 444 pay-per-call tools (SEO, ads, social, trends, finance)
Web scraping, SERP search, crawl/map and 74 Collectors through residential proxies. 25 tools.
One key to 1,000+ paid data APIs: enrichment, SEO/SERP, scraping, places, news. Pay per call.
LinkedIn companies, hiring signals and public profiles by URL. No login, no cookies. Pay per result.
Add one secure layer between your agents and this server.
