sales-intelligence-mcp

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

Annotations provide readOnlyHint=true and openWorldHint=true, and the description adds behavioral context: it wraps an external aggregator (nexgendata/company-data-aggregator) and performs a Crunchbase free-tier funding scrape when include_funding=True. This goes beyond the annotations without contradicting them. It does not mention rate limits or authentication, but that is acceptable given the read-only hint.

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 front-loaded with the core purpose in the first sentence, then lists sources, positions the tool among siblings, and provides parameter explanations in a clear 'Args' block. It is efficient and well-structured, though the parameter explanations could be integrated more concisely without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multi-source aggregation, external wrapper, funding scrape) and the absence of an output schema, the description should more fully explain the return structure. It mentions the fields covered but does not specify the exact JSON structure, nesting, or which fields are guaranteed. This leaves an agent uncertain about the output format.

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 0% description coverage, so the description must compensate. It explains name_or_domain as 'Company name or domain' and include_funding as 'Include Crunchbase + news-based funding lookup'. This adds meaning beyond the schema types and default values. A higher score would require more detail on allowed formats for name_or_domain.

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 builds a full company profile by aggregating multiple public sources (homepage, /about, /careers, JSON-LD, Crunchbase) and lists the specific fields covered (industry, HQ, founded date, employee band, key people, social handles, funding history). It also distinguishes itself from siblings by calling itself 'the richest of the company-research tools'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use: 'use this when you want one record covering...'. It implies alternatives through sibling tool names (e.g., detect_hiring_signal, detect_tech_stack), and mentions the include_funding parameter. However, it does not explicitly state when not to use it or compare directly to siblings like enrich_company.

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

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

Annotations indicate readOnlyHint and openWorldHint, and the description adds context by mentioning it aggregates from job boards and wraps a specific model. It does not contradict annotations, and explains the transformation (aggregation, keyword detection). While not exhaustive about rate limits or errors, it is sufficient given the annotations.

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

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

The description is front-loaded with the main purpose, then provides use cases and parameter details. Each sentence adds value 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?

For a read-only tool with one parameter and no output schema, the description explains the inputs, behavior, and high-level output (aggregated signals, keywords). It could be more precise about the output structure, but 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 description fully covers the single parameter company_slugs with an explanation and example, compensating for the schema's lack of descriptions (0% coverage). It adds meaning beyond the type definition.

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 detects hiring-momentum signals for a list of companies, specifying what it aggregates (open-role counts, growth keywords, trend indicators). This verb-resource combination is specific and distinguishes it from siblings like search_linkedin_jobs or track_startup_funding.

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 provides concrete use cases (sales prospecting, funding signals) but does not explicitly state when not to use this tool or recommend alternatives among siblings. However, the use cases are clear enough to guide selection.

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

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

Annotations already indicate readOnlyHint and openWorldHint. Description adds that it wraps another tool and returns categorized detections with version+confidence info, which is useful context beyond 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?

Very concise: two sentences plus arg example. No redundancy, front-loaded with purpose. 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 simple input (1 param, read-only) and no output schema, the description adequately describes what the tool does and returns (categorized detections with version+confidence). Could mention pagination or limits, but not essential.

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?

Despite 0% schema description coverage, the description provides clear guidance for the 'domain' parameter with example formats, adding meaning beyond the schema's mere type declaration.

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?

Clearly states it detects technology stack of a website, listing categories. Distinct from sibling tools that focus on company profiles, leads, etc.

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 says it's a drop-in replacement for Wappalyzer API, guiding users familiar with that. However, no explicit when-not or comparison to alternatives among siblings, which are clearly different in domain.

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

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

Annotations already indicate readOnlyHint and openWorldHint. The description adds transparency by naming the underlying tool (nexgendata/company-enrichment-tool) and explicitly listing the enrichment fields. No contradictions.

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

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

Three sentences front-load the purpose, specify source, and explain input. No redundant information; 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?

For a simple tool with one parameter and no output schema, the description covers input format and output contents. It lacks error handling or limitations, but overall is sufficient for correct invocation.

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?

With 0% schema description coverage, the description adds critical meaning: it clarifies that domain_or_name accepts either a company name or domain, and provides examples ('Stripe', 'stripe.com'). This goes beyond the schema's bare type declaration.

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 'Enrich a single company' and enumerates the specific fields added: domain, description, industry, employee band, social profiles, and email patterns. This distinguishes it from siblings like find_company_emails or detect_tech_stack which focus on narrower aspects.

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 a single company and specifies acceptable input formats (name or domain), but does not explicitly provide when-to-use or when-not-to-use guidance relative to sibling tools like enrich_lead_list or detect_tech_stack.

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

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

Annotations already indicate readOnlyHint=true, so the description's mention of enriching is consistent. It adds value by naming the external service and batch size recommendation, but doesn't discuss data freshness, missing domains, or rate limits.

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?

Extremely concise: three sentences plus a single bullet for the argument. Front-loaded with purpose, no wasted words. Perfect structure for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives a high-level overview of returned data types but lacks detailed output structure (e.g., exact fields per domain, nesting). With no output schema, more specificity would help agents use the data effectively.

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?

With 0% schema description coverage, the description compensates by explaining the 'domains' parameter as a list of company domains with examples. However, it could add more detail on format constraints or error handling.

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 bulk-enriches a list of company domains with specific data types (emails, contact pages, social profiles, phone numbers). It uses a strong verb and resource combination and distinguishes from siblings like enrich_company and find_b2b_leads.

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 recommends use after find_b2b_leads and advises a batch size of ~50 domains for response time. This provides clear context, though it lacks explicit when-not-to-use scenarios.

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

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

Annotations set readOnlyHint=true and openWorldHint=true. The description adds that the tool wraps a data source and returns company-level leads with names, domains, and job-title contacts, plus it lists all parameters with examples. No contradiction with annotations.

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

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

The description is concise yet complete: a one-line summary, a context paragraph explaining the tool's output and follow-up, and a bullet-like args list. Every sentence adds value without 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?

Despite lacking an output schema, the description clearly states what is returned (company leads with names, domains, contacts). It covers all 4 parameters, explains the tie-in with enrich_lead_list, and mentions the external data source. This is sufficient for a search/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 description coverage is 0%, but the description provides full parameter explanations: industry (vertical), country (optional region), employee_band (with specific size-band examples), and limit (range 1-500, default 50). This fully compensates for the missing schema 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 opens with 'Find B2B sales leads matching an industry / geography / size filter,' specifying a clear verb and resource with distinct filters. It also mentions using 'enrich_lead_list' afterwards, distinguishing this tool from siblings that focus on enrichment or other data.

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 advises to 'use enrich_lead_list afterwards to add contact info,' providing a clear post-processing step. While it doesn't explicitly list when not to use this tool, the context and sibling names imply this is the initial lead-finding step.

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

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

The description adds behavioral context beyond the annotations (readOnlyHint, openWorldHint) by stating it wraps a specific data source and returns role-based emails plus verified contacts from crawling. This helps the agent understand the nature of results and method. No contradictions.

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

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

The description is concise with no wasted words. It is front-loaded with the main action, then provides additional details in a logical order: purpose, data source, output types, and parameter specification.

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 the essential aspects: what it does, what it returns, and how the parameter should be provided. It is missing explicit return format but is sufficient given the read-only and open-world hints.

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?

With 0% schema description coverage, the description compensates by explaining the 'domain' parameter format and example. It adds meaning beyond the bare schema by specifying that the domain can be with or without scheme.

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

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

The description uses a specific verb 'Find' and resource 'company emails'. It clearly explains the output (probable role-based and verified contacts) and distinguishes from sibling tools like 'enrich_company' or 'find_b2b_leads'. No ambiguity.

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 clear context for when to use the tool (when needing publicly available email addresses for a company domain). It does not explicitly mention alternatives or when not to use, but the context is sufficiently clear given the sibling tools are distinct.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that it wraps an external scraper and returns directory entries, but does not disclose additional behavioral details like caching, rate limits, or data freshness. Adequate but not extra.

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 (6 lines), front-loaded with purpose, and organized into overview, wrapper info, return fields, and parameter descriptions. No unnecessary 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?

Tool is simple with two optional parameters. Description covers what it returns, parameters, and wrapper. No output schema, but return fields are listed. Lacks mention of pagination or result limits, but context is largely complete for typical use.

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 0%, but description compensates by providing clear definitions for batch (example codes) and stage (status values), adding meaningful context beyond the schema structure.

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?

Clearly states 'Find Y Combinator companies' with optional filters. The description specifies verb (find) and resource (YC companies), distinguishing it from siblings like aggregate_company_profile or enrich_company.

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?

Describes optional filters (batch, stage) with examples but does not explicitly state when to use this tool over siblings or provide exclusions. Usage is implied but lacks direct guidance.

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

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

Annotations already provide readOnlyHint and openWorldHint. The description adds value by noting the scraper reliance, return fields, and the 'soft hint' nature of the posted_within_days filter.

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 concise, front-loaded with the main purpose, and uses a clear args list. Every sentence adds value with no 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?

The description covers return fields, soft filter behavior, and dependency. For a read-only search tool with simple parameters, this is nearly complete; only missing mention of pagination or result limits.

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 0% description coverage. The description explains each parameter's purpose (free-text query, optional location with examples, and soft recency filter with defaults/limits), compensating well.

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 for public LinkedIn job postings with a specific verb+resource combination. It differentiates well from sibling tools (e.g., company profiles, leads, funding).

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 usage context is clear—searching for jobs—but there is no explicit guidance on when not to use this tool or which alternative to choose. Siblings are sufficiently distinct to avoid confusion.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true, so the safety profile is clear. The description adds that it wraps an external dataset, returns recent rounds, and has a max days_back of ~180. It does not disclose pagination, rate limits, or behavior on empty results, but provides adequate extra context beyond 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 well-structured with a summary line, wrapper info, return fields, and an args list. It is slightly verbose but not excessive, clearly presenting all necessary information in a readable format.

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 three simple parameters, no output schema, and moderate annotations, the description covers purpose, parameters, and basic behavior. It mentions return fields but does not detail the exact output structure (e.g., whether it's a list or paginated). Overall, it is fairly complete for the tool's 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 0%, so the description carries full responsibility for parameter explanations. It clearly describes 'stage' and 'sector' as optional filters with examples, and 'days_back' with default and max values, adding significant meaning beyond the raw schema.

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

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

The description clearly states the tool tracks recent startup funding announcements with filtering by stage and sector. It specifies the data sources (Crunchbase News, TechCrunch, sector press) and the information returned (company, amount, round type, investors, date), distinguishing it from siblings like enrich_company or search_linkedin_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?

The description mentions optional filters and a look-back window, providing some usage context. However, it does not explicitly compare with sibling tools or state when to prefer this over other company data tools, lacking clear when-to-use or when-not-to-use guidance.

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