sales-intelligence-mcp

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

Annotations indicate readOnlyHint and openWorldHint, which description complements by detailing data sources (homepage, /about, /careers, JSON-LD, Crunchbase) and behavior (wraps external aggregator, conditional funding scrape). No contradiction.

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?

Concise five sentences arranged logically: purpose, wrapper note, positioning, then parameter docs. Front-loaded with primary function, no extraneous content.

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 no output schema, description lists included data (industry, HQ, founded date, etc.). Could specify response format, but for a profile aggregation tool, coverage is 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?

Schema has 0% description coverage, but description fully explains both parameters: name_or_domain as company name or domain, include_funding with specific source (Crunchbase free-tier + news). Adds clarity beyond 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 action: 'Build a full company profile by aggregating across multiple public sources', listing specific sources and data points. It positions itself as the richest among sibling tools, providing clear differentiation.

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 recommends using this tool when a comprehensive company record is needed. It implies alternatives for simpler needs through sibling context, but lacks explicit '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.

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

Annotations declare readOnlyHint=true, consistent with the detection nature. The description adds that it aggregates data from job boards and wraps a detector, providing behavioral context beyond 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, followed by details and use cases. It is relatively concise, though the final 'Args' block is slightly redundant with the schema.

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 explains what the tool returns in general terms, but lacks specifics on the output format or structure. Given the tool has no output schema, more detail would improve 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?

The single parameter company_slugs is well-described with examples (e.g., 'stripe', 'notion') and clarification that slugs or names are accepted. Schema coverage was 0%, so the description fully compensates.

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 detects hiring-momentum signals for a list of companies, specifying aspects like open-role counts, growth keywords, and trend indicators. This differentiates it from sibling tools like search_linkedin_jobs 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?

The description explicitly mentions use cases: sales prospecting and funding signals. While it doesn't explicitly state when not to use it or list alternatives, the use cases are clear and helpful.

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 that it returns categorized detections with version and confidence info, which is useful but not extensive. 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 succinct, with a clear first sentence summarizing purpose, followed by contextual details and parameter formatting. No extraneous content.

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 a single parameter, no output schema, and annotations. The description covers purpose, usage context, parameter format, and return structure, making it fully adequate 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?

The schema has 0% description coverage, but the description clarifies the 'domain' parameter with examples and notes it accepts full URLs or domains. This compensates well for the schema gap.

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 detects technology stack of a website, listing categories like frameworks, CMS, analytics, etc. It also notes it's a drop-in replacement for Wappalyzer, distinguishing it from sibling tools that focus on company profiles or job searches.

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 specifies when to use (need to detect tech stack) and provides context as a Wappalyzer replacement. It doesn't explicitly list when not to use, but siblings are diverse enough that confusion is unlikely.

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, which the description reinforces. It adds that email patterns are provided where available, offering extra context about data completeness. 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 extremely concise: two sentences plus an Args line. No unnecessary words. Front-loaded with the key action and outputs.

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 read-only tool with one parameter and no output schema, the description provides all necessary information: what it does, what it returns, and how to specify the input. No gaps for an LLM to select or invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema lacks a description for 'domain_or_name', but the description explains it accepts a company name or domain, with examples. This adds necessary semantics beyond the schema alone.

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: enriching a single company with domain, description, industry, employee band, social profiles, and email patterns. It specifies the accepted input types (name or domain) and differentiates it from sibling tools that target specific enrichment 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 provides examples of valid inputs and notes the underlying tool, but does not explicitly differentiate when to use this tool over siblings like 'aggregate_company_profile' or 'detect_hiring_signal'. Some implied context from the output types, but no 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 declare readOnlyHint=true and openWorldHint=true, so the description builds on this by adding that it wraps a third-party API and gives a batch size recommendation. It does not contradict annotations and provides useful behavioral context beyond what annotations offer.

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 covering purpose, usage context, and parameter definition. No redundant information; every sentence serves a distinct purpose. Front-loaded with the main action.

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 purpose, usage, and parameter. Lacks explicit mention of return format or structure, but the annotations (openWorldHint) partly mitigate this. Functionally complete for an AI agent to select and invoke.

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 only parameter 'domains' is explained with a clear description ('list of company domains') and an example. Given 0% schema description coverage, the description fully compensates by adding meaning and usage guidance (batch size).

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 the verb 'bulk-enrich' and resource 'list of company domains', specifying the types of data added (emails, contact pages, social profiles, phone numbers). Distinguishes from siblings like 'enrich_company' by emphasizing bulk operation and connection to '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?

Provides explicit usage context: 'best used after find_b2b_leads' and a batch size recommendation ('up to ~50 domains per call'). Lacks explicit when-not-to-use or alternative comparisons, but the guidance is clear and actionable.

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 readOnly and openWorld hints. The description adds that the tool returns company-level leads with specific fields and wraps an external API, providing useful behavioral 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, return details, usage suggestion, and parameter list. It is slightly verbose but each part contributes 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?

The description covers parameters, return content, and a next-step suggestion. Without an output schema, it provides adequate context for an agent to select and invoke the tool 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?

With 0% schema description coverage, the description fully compensates by detailing each parameter: industry, country, employee_band (with example values), and limit (with range). This adds essential meaning beyond the 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 finds B2B sales leads with filters for industry, geography, and size. It distinguishes from sibling tools like find_yc_companies and enrich_lead_list.

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 recommends using 'enrich_lead_list' afterwards, guiding the agent to a common workflow. However, it lacks explicit 'when not to use' or alternative selection criteria.

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. The description adds value by detailing the behavior: it wraps a data source, returns probable role-based emails and verified contacts discovered by crawling. 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 a clear summary sentence followed by a brief explanation. It includes a docstring-style parameter description. No superfluous text; well front-loaded.

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 only one parameter and no output schema, the description adequately explains what it does and what it returns. However, it could be more complete by describing the structure of returned emails (e.g., list 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 only defines 'domain' as a required string without a description (0% coverage). The description adds meaning by specifying the format (company domain, e.g., 'stripe.com') and noting that scheme is optional.

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 finds 'publicly available business email addresses for a company domain', using a specific verb and resource. This distinguishes it from sibling tools like 'find_b2b_leads' or 'enrich_company' which have different purposes.

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 finding company emails but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'find_b2b_leads' might also return emails). No exclusions or when-not-to-use are given.

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 declare readOnlyHint=true, and the description confirms a read operation by stating 'Returns the YC directory entries'. It adds the wrapper source and lists return fields, providing 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?

The description is concise, front-loaded with purpose, and efficiently covers wrapper info, return fields, and parameter explanations in a few sentences with no extraneous content.

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 simplicity (2 optional params, no required), the description fully covers its functionality and return values, making it complete for an agent to understand and invoke 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?

With 0% schema description coverage, the description fully compensates by providing explicit examples for batch (e.g., 'W26', 'S25') and stage (e.g., 'Active', 'Acquired', 'Public'), adding significant meaning beyond the 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 explicitly states the tool finds Y Combinator companies with optional filtering by batch or status, clearly distinguishing it from sibling tools like aggregate_company_profile or detect_hiring_signal which focus on different 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 indicates optional filters and mentions the underlying scraper, but does not explicitly contrast with siblings or state when not to use it. However, the purpose is unique enough that usage is clear from context.

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. The description adds meaningful behavioral context: returns specific fields (title, company, location, date, description) and softness of recency filter. 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?

Concise with a brief summary followed by structured Args. No unnecessary sentences. 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 no output schema, the description lists key return fields. Could mention pagination or result count, but the return description is adequate for a 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 0%, so the description carries full burden. Each parameter (query, location, posted_within_days) is clearly explained in the Args section, including default values and constraints (e.g., max 90 days).

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 searches LinkedIn for public job postings, with a specific verb 'search' and resource 'LinkedIn jobs'. Distinguishes from sibling tools which are about company profiles, leads, funding, 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?

Provides explicit context such as the wrapper 'nexgendata/linkedin-jobs-scraper' and notes that the posted-within filter is a soft hint applied client-side. Does not explicitly state when not to use, but the openWorldHint annotation suggests it can be used broadly.

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. The description adds valuable behavioral context: it wraps a specific tracker (nexgendata/startup-funding-tracker), returns data from multiple sources, and lists the fields included. It also notes the maximum days_back of ~180, which is not in the schema.

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

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

The description is concise and well-structured: a single-sentence purpose, followed by source and return overview, then a parameter list. Every sentence adds value with no redundancy. Suitable length for the tool's complexity.

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 filtering tool with three optional parameters and no output schema, the description is complete. It covers purpose, data source, return fields, and parameter details. No additional context is needed for effective 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?

With 0% schema description coverage, the description fully compensates by providing detailed parameter descriptions in an Args section, including example values (e.g., 'seed', 'ai') and constraints (default 30, max ~180). This adds essential semantic meaning beyond the schema's types.

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 tool's purpose: 'Track recent startup funding announcements filtered by stage and sector.' It also specifies the data sources and fields returned, distinguishing it from all sibling tools which focus on company profiles, hiring, or tech stack detection.

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 obtaining startup funding data with optional filters, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. However, the sibling tools are sufficiently different, so context is clear.

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