Explorium AgentSource MCP Server

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

No annotations provided, but description gives strong behavioral hints (parallel calls, field dependencies). Could explicitly declare read-only nature, but it's implicitly clear for autocomplete. Good 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?

Well-structured with clear sections, lists, and hints. Front-loaded with purpose. Slightly long but 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?

No output schema and description does not mention return format (e.g., list of suggestions). Successful response structure and error handling are missing, leaving some ambiguity for an 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?

Schema coverage is 100% with enum and descriptions. Description adds value by listing all fields inline and providing hints (e.g., 'software' for 'saas'), but semantics are already well-covered by 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?

Description states 'Autocomplete values for various business fields based on a query string' with a clear list of specific fields. It distinguishes itself from sibling enrich/fetch tools by being a utility for filter selection.

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 states 'You MUST call this tool before using any of the following filters', lists 17 filters, advises calling simultaneously, and provides preference for linkedin_category over google_category.

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?

No annotations are provided, so the description must cover behavioral traits. It does not disclose potential side effects, rate limits, authentication needs, or data freshness. The assumption that data comes from SEC filings (implying public companies) is not explicitly stated as a constraint.

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 structured as a bullet list of return items, making it easy to scan. However, it is slightly verbose with repeated phrases like 'data security'. Overall, it is concise and front-loaded with the main purpose.

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 multiple return categories and no output schema. The description details what is returned but omits input constraints (e.g., only public companies) and does not clarify overlap with sibling tools like enrich_businesses_strategic_insights. It is moderately complete but has 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?

The single parameter 'business_ids' has a schema description stating it comes from match_businesses, which is clear. Schema coverage is 100%, so baseline is 3. The description adds no further meaning beyond the schema, but it does reference match_businesses which is helpful context.

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 provides insights on challenges, breaches, and competition of public companies. It lists specific return categories, distinguishing it from sibling tools like enrich_businesses_competitive_landscape which focuses solely on competition.

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. It does not mention when not to use it or provide context about prerequisites (e.g., only for public companies). The description only lists capabilities without usage recommendations.

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?

No annotations were provided, so the description must disclose behavioral traits. It explains the return categories (ratings, culture, etc.) but omits details like idempotency, rate limits, or that it requires business IDs from match_businesses (implied by schema but not explicit). This is adequate but not fully transparent.

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 brief and front-loaded with the primary action. The bullet list of return categories is well-structured, though listing each category individually is slightly verbose. Overall, it is efficient and easy to scan.

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 is a simple bulk enrichment with one parameter and no output schema, the description adequately covers what is returned. It lists all rating categories, though it could have mentioned that the results are for a specific company and require pre-existing business IDs.

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 already has 100% description coverage with a clear explanation of the business_ids parameter. The description does not add new semantic information beyond what the schema provides, so the baseline score of 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 uses the clear verb 'Get' and specifies the resource as 'internal company ratings', making the purpose obvious. However, it does not differentiate from sibling tools like enrich_businesses_financial_metrics, which also return data about businesses for enrichment.

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, nor does it mention any prerequisites or limitations. It simply states what the tool does without contextual usage advice.

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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, if authentication is required, or any side effects. The description only lists returns without describing the process or potential limitations.

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 concise bullet list of 6 items with no unnecessary text. The primary purpose is front-loaded in the first sentence. 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 explains return values well, listing specific fields like competitive differentiation strategies, filing dates, etc. However, it lacks details on error conditions or data sources, leaving some gaps for a single-parameter 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% (business_ids is described as 'List of Explorium business IDs from match_businesses'). The tool description adds no additional semantics beyond the schema, so 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 starts with a clear verb ('Get insights on') and resource ('market landscape of public companies'). It lists specific return items (competitive differentiation, key competitors, ticker symbols, etc.) that distinguish it from sibling tools like enrich_businesses_challenges or enrich_businesses_financial_metrics.

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 use when competitive landscape insights are needed, but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The context signal lists sibling tools, but no guidance is provided.

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?

No annotations exist, so the description must fully disclose behavioral traits. It mentions the tool returns data but omits prerequisites (e.g., business IDs from match_businesses, noted only in schema), potential rate limits, or any side effects. The 'in bulk' hint is vague.

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 purpose line and a bulleted list of returns. Some redundancy exists (e.g., 'leadership information' repeated in both line and list), but overall it is efficient and 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 complexity and absence of output schema, the description comprehensively lists the return fields (financial metrics, leadership, earnings, peers, TSR). However, it fails to mention constraints like maximum batch size (50 from schema) or rate limits, leaving minor 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 coverage is 100% for both parameters, so baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides (e.g., date format, business IDs source). No additional value.

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: 'Get financial metrics for public companies in bulk.' It also mentions additional use for leadership information, effectively distinguishing it from sibling tools like enrich_businesses_firmographics or enrich_businesses_company_ratings.

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 on when to use the tool (financial metrics and leadership info), but lacks explicit when-not-to-use guidance or comparisons to alternatives. The mention 'You may also use this tool when looking for leadership information' gives positive direction but no exclusions.

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?

No annotations are provided, so the description bears full responsibility. While it details the output fields, it does not disclose whether the operation is read-only, any authentication requirements, or potential side effects. The lack of any behavioral warnings leaves 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?

The description is concise, using a bullet list for output details and a short exclusion note. It is well-structured, though the list could be slightly more compact. 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 has one parameter and no output schema, the description is fairly complete, listing all returned fields. However, it omits details like pagination, maximum response size, or any rate limits, which could impact agent decision-making.

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 'business_ids' has 100% schema coverage with a description that clarifies the IDs come from match_businesses, adding meaningful context beyond the schema. This helps agents understand the data source.

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 'Get firmographics data in bulk' and lists all returned fields, making the tool's purpose unambiguous. It is distinct from sibling tools like enrich_businesses_financial_metrics or enrich_prospects_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 explicitly states when NOT to use the tool (for finding employees or leadership info), providing clear exclusion criteria. However, it does not suggest alternative tools for those cases, which would improve guidelines.

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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'in bulk' but does not indicate whether the operation is read-only or destructive, nor disclose any rate limits or authentication requirements.

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, starting with a clear purpose sentence followed by a bullet list of return fields. The structure effectively communicates the output without unnecessary verbiage.

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 absence of an output schema, the description compensates by listing expected return fields. However, it does not describe the format or structure of the response, nor potential errors or performance considerations (e.g., max business IDs from schema).

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 describes the required business_ids parameter with 100% coverage. The description adds the context that IDs come from match_businesses, but does not provide further semantic detail 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 gets funding and acquisition history in bulk, and lists specific return fields. This distinguishes it from sibling tools like enrich_businesses_firmographics or enrich_businesses_financial_metrics.

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 the tool is for funding/acquisition data, but it does not explicitly state when to use this tool vs. other enrich_businesses_* tools, nor does it mention any prerequisites or exclusions.

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?

No annotations are provided, so the description must disclose behavioral traits. It lists return values but fails to mention any limitations, rate limits, data recency, or authentication requirements. For a tool with no annotations, this is a significant gap.

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 efficient with a clear opening sentence followed by a bullet list of return items. Each bullet adds value, though the list could be slightly more concise. Overall, it is well-structured and 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 one parameter and no output schema, the description covers the primary purpose and return types. However, it lacks details on pagination, result limits, or data freshness, which would help the AI use it correctly. It is minimally 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 only parameter, business_ids, is well-documented in the input schema with a clear description. The tool description adds no further meaning beyond what the schema provides. With 100% schema coverage, the baseline 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 'Get LinkedIn posts for public companies', specifying the verb, resource, and target. It distinguishes from sibling tools like enrich_prospects_linkedin_posts by focusing on businesses. However, it does not explicitly differentiate from other enrich_businesses_* tools, so a slight deduction.

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 when LinkedIn posts for public companies are needed. No explicit when-not or alternatives are provided. Sibling tools like enrich_businesses_firmographics or enrich_prospects_linkedin_posts exist but are not mentioned, leaving the AI to infer 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?

No annotations are provided, so the description carries the full burden. It discloses the data source (SEC filings) and that returns are based on public disclosures. It does not explicitly state idempotence or safety, but 'Get' implies a read-only operation. Slight improvement could be made by confirming no side effects.

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 bullet points for clarity. It is somewhat lengthy but each bullet adds value. The purpose and caution are front-loaded. Could be slightly more concise.

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 one parameter, no output schema, and a clear domain, the description covers purpose, data sources, output types, usage caveats, and parameter context. It is complete for an AI agent to select and invoke this 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% with a single parameter 'business_ids' already described as 'List of Explorium business IDs from match_businesses'. The description does not add further parameter details, so it meets the baseline but does not exceed.

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 retrieves strategic insights for public companies, listing specific outputs like strategic focus areas, target markets, and SEC filing links. This distinguishes it from similar sibling tools that focus on financial metrics, workforce trends, 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 an explicit when-not-to-use instruction: 'Do NOT use this when you need to find employees at a company.' This guides the agent away from inappropriate use and implies an alternative tool for employee data.

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?

With no annotations, the description must disclose all behavioral traits. It only implies a read operation ('Get ... data') and does not mention authentication, rate limits, data freshness, or potential side effects. The extensive output description does not compensate for missing behavioral context.

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 purpose and then provides a structured list of return categories. While the list is long, it is directly useful for an agent to understand output content. It could be more concise but is not 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?

Given the absence of an output schema, the description thoroughly explains the return value structure with 21 categories. It covers the essential information needed to use the tool. However, it lacks context on error handling, limits, and data recency.

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 'business_ids' has a description. However, the tool description adds no new meaning beyond the schema's description. Baseline score of 3 is appropriate as it neither improves nor degrades parameter understanding.

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 starts with 'Get technographics data in bulk,' which clearly specifies the verb 'get' and the resource 'technographics data.' The detailed list of categories distinguishes it from other enrich tools like enrich_businesses_firmographics or enrich_businesses_financial_metrics. It is specific and unambiguous.

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

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

No guidance is provided on when to use this tool versus its siblings. The description does not mention prerequisites, alternatives, or scenarios where this tool is preferred. The agent must infer usage from the tool name alone.

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?

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or side effects. The agent cannot infer safety or constraints from the description alone.

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 an initial summary followed by a bulleted list of outputs. It is front-loaded and efficient, though it could include more on usage context without becoming 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?

The description thoroughly explains the return values, which is helpful given no output schema. However, it lacks guidance on when to invoke the tool and parameter behavior, leaving gaps in overall 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% with descriptions for both parameters. The description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.

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 returns website changes for public companies and lists specific outputs. However, it does not differentiate from sibling 'enrich' tools that may also provide strategic or keyword-related insights, reducing clarity.

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 like enrich_businesses_website_keywords or enrich_businesses_strategic_insights. Prerequisites or context are not mentioned, leaving the agent to guess.

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?

No annotations are provided, so the description carries full burden. It discloses return fields but does not mention side effects, idempotency, rate limits, or assumptions (e.g., that the company must have a website). The lack of behavioral warnings is a gap.

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: it opens with purpose, explains input format, then lists outputs. Every sentence adds value, and there is 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?

Given 100% schema coverage and no output schema, the description adequately covers inputs and outputs. However, it lacks edge-case details (e.g., what 'Keywords indicator' returns) and doesn't mention that the tool works only for companies with websites.

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 value by explaining that comma-separated terms simulate AND logic for keywords, and it describes the output fields. This goes beyond the schema descriptions, though business_ids is not further elaborated.

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: 'Get website keywords for public companies.' It explains the use of multiple search terms with AND logic and lists the return data, making it distinct from sibling tools like enrich_businesses_website_changes.

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 (e.g., enrich_businesses_website_changes). It explains how to input keywords but does not specify use cases, prerequisites, or when not to use.

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?

With no annotations, the description carries full burden for behavioral disclosure. It lists return fields but does not mention data freshness, limitations, required privileges, or any side effects. The behavior is mostly opaque.

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 reasonably concise with a clear opening sentence followed by a bulleted list of returns. The list could be trimmed, but it remains readable and 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?

For a tool with one parameter and no output schema, the description adequately explains what it returns. However, it lacks any usage context or behavioral notes that would help an agent decide when to invoke it.

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 'business_ids' is well-documented in the schema with a description. The tool description does not add further semantic meaning beyond what the schema provides, so it scores a baseline 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 'Get workforce trends and department composition for companies', which specifies the verb and resource. It distinguishes from sibling tools like enrich_businesses_financial_metrics by focusing on workforce data. However, the list of returns is somewhat verbose without adding core distinctiveness.

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 other enrich tools, nor does it mention any prerequisites or context. It simply describes what it does, leaving the agent to infer usage.

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?

With no annotations, the description provides minimal behavioral insight. It does not disclose whether the operation is read-only or destructive, any authentication requirements, rate limits, or side effects like modifying existing data.

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 and front-loaded with the main action. It lists return fields in a bullet-like format. However, it could be slightly more structured (e.g., grouping return types) but remains effective in its brevity.

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 simple input and no output schema, the description covers the main purpose and return data. However, it lacks details on error handling, invalid IDs, or the enrichment process itself, leaving some gaps for a basic 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 single parameter 'prospect_ids' is well-documented in the schema (list of IDs from match_prospects, max 50). The tool description adds no additional parameter semantics beyond the schema, meeting the baseline 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 explicitly states it enriches prospect contact information and lists the specific data returned (emails, email type, phone numbers). This clearly differentiates it from sibling tools like enrich_prospects_profiles or enrich_prospects_linkedin_posts.

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 other enrich tools, no prerequisites mentioned, and no context on when not to use it. The parameter description hints at using it after match_prospects, but the tool description itself lacks this 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?

With no annotations, the description must disclose behavioral traits. It lists output fields but does not mention if the operation is read-only, any side effects, rate limits, or potential errors (e.g., for prospects without LinkedIn posts). It adequately describes the main function but lacks depth.

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 relatively short, front-loads the main action, and uses a bullet list for clarity. One minor waste: the bullet list could be integrated into prose, but overall 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?

Given no output schema, the description should fully explain the return structure. It lists fields but not the structure (e.g., per prospect, array, map). No error handling or edge cases mentioned. Adequate but not 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 coverage is 100% for the single parameter, so the description adds no additional meaning beyond what the schema already 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 clearly states the tool enriches prospect LinkedIn posts with additional details and lists specific returned fields. However, it does not explicitly differentiate from the sibling tool 'enrich_businesses_linkedin_posts' for businesses, though the name and context imply the distinction.

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, no prerequisites mentioned (e.g., that prospect IDs come from 'match_prospects' – only in schema), and no exclusions provided.

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?

No annotations are provided, so the description bears full responsibility for behavioral traits. It only lists return fields and mentions the input parameter, but fails to disclose whether the operation is read-only, requires authentication, has rate limits, or produces side effects. This is insufficient for safe tool selection.

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 starts with a clear purpose statement but is quite long due to a bullet list of return fields. While structured, it contains redundant phrasing and could be more concise. It is adequate but not exemplary.

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 (one parameter, no output schema), the description thoroughly documents the return values across various categories (demographics, location, LinkedIn, work history, education, skills). This compensates for the missing output schema, though it lacks usage and behavioral 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 description coverage is 100% with a clear description for prospect_ids: 'List of up to 50 Explorium prospect IDs from match_prospects'. The tool description does not add new meaning beyond the schema, so a 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 tool gets detailed profile information for prospects and enumerates specific fields like full name, demographics, location, LinkedIn URL, current role, work history, education, and skills. It distinguishes from sibling tools which focus on businesses or other aspects (e.g., enrich_businesses_firmographics, enrich_prospects_contacts_information), making its purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., enrich_prospects_contacts_information, enrich_prospects_linkedin_posts). It does not mention prerequisites, limitations, or exclusions, leaving the agent without context for appropriate invocation.

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?

No annotations provided; description states it returns Business IDs for further use, implies read-only nature. Does not detail pagination or rate limits, but adequate for a fetch 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?

Eight sentences, no redundancy, logically ordered instructions (before, during, after), each 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?

Covers prerequisites, filter constraints, and output (Business IDs). Missing explicit pagination behavior, but page/Page_size parameters are documented in schema.

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 75% of top-level params with descriptions; description reinforces autocomplete requirement for certain filters and adds context about mandatory filters 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 it fetches businesses from the Explorium API with filtering, and distinguishes from siblings like autocomplete, enrich_*, and match_businesses by explicitly warning against calling match_businesses afterwards.

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 instructions: must call autocomplete first for filter values, do not use without available values, stop if filter unsupported, and suggests fetch_prospects for employee searches.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It fails to mention any behavioral traits such as rate limits, pagination, result limits, data freshness, or authentication requirements. The minimal description leaves significant gaps for an agent.

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 three sentences long, which is concise. However, the third sentence 'This is a VERY useful tool' is promotional and adds no functional information, slightly reducing efficiency. Still, the structure is clear with purpose, alternative, and value statement.

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 bulk retrieval tool with no output schema, the description does not explain the return format or any pagination/limits. It covers purpose and usage guidelines well but lacks behavioral details. It is moderately complete given the schema richness, but missing output information lowers the score.

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%, with detailed enum descriptions in the schema. The description adds no additional meaning beyond what the schema already provides. It does not explain how to obtain business_ids or the exact format for timestamp_from, relying on 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?

The description clearly states the tool retrieves business-related events in bulk from the Explorium API, with a specific verb and resource. It also differentiates from the prospects events tool by mentioning role changes as a different use case.

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 tells when to use this tool and when not to, providing a named alternative (prospects events tool) for role-change events. It also suggests the tool is useful for researching company events and history, giving clear 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?

No annotations are provided, and the description does not disclose any behavioral traits (e.g., if it's read-only, performance, or side effects). The schema hints at prerequisites but the description is silent.

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, front-loaded sentence that efficiently states the tool's purpose. However, it could be slightly more expansive without losing conciseness.

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 complexity of the filters (many parameters) and the absence of an output schema, the description is too vague. It does not enumerate all supported filter dimensions or explain the shape of the response, leaving agents underinformed.

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 schema description coverage at 0% (per context signal), the description must compensate but only vaguely mentions 'industry, revenue, employee count, and geographic distribution,' which hints at filter dimensions but adds little detail beyond the schema's own rich 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 clearly states 'Fetch aggregated insights into businesses by industry, revenue, employee count, and geographic distribution,' which includes a specific verb and resource. It distinguishes from siblings like 'fetch_businesses' which likely returns raw data, not aggregates.

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 does not provide any guidance on when to use this tool versus alternatives. While the schema contains usage notes about calling autocomplete, the main description lacks explicit when/why-to-use instructions.

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?

Without annotations, description carries full burden. It mentions returning Prospect IDs and stopping if filter unsupported, but lacks details on pagination behavior 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?

Front-loaded with purpose, then guidelines and alternatives; 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?

Given complex nested schema and no output schema, description provides essential guidance but omits explanation of pagination and full return 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?

Schema coverage is 75%; description emphasizes autocomplete for certain filters but does not add meaning beyond schema descriptions for page/size parameters.

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 'Fetch prospects (employees) using filters' and distinguishes from siblings like fetch_businesses and enrich_businesses_financial_metrics.

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 states to use autocomplete tool first and not to call without necessary filter values, providing clear usage 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?

No annotations are provided, so the description bears full responsibility. It only states the action and provides a workflow, but does not disclose rate limits, authentication requirements, side effects, or return behavior beyond 'in bulk'. This lack of transparency is a significant gap.

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 and a workflow hint. Every sentence adds value, and the most important info is front-loaded. 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 absence of an output schema, the description could explain return format, but the schema's $defs cover event details. The description lacks behavioral context like pagination or limits, making it adequate but not fully 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 description coverage is 100%, and the schema already provides detailed descriptions for all parameters, including a comprehensive $defs for event types. The description adds no extra meaning beyond the schema, so 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 verb 'retrieves' and the resource 'prospect-related events in bulk'. It also distinguishes from siblings like fetch_businesses_events by specifying 'prospect-related' and providing a workflow example that shows its position in the pipeline.

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 says 'Use this when querying for prospect-related events about businesses' and gives a workflow example. However, it does not explicitly mention when not to use it or suggest alternatives, which would make it clearer.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' IDs, implying a read operation, but does not explicitly confirm idempotency, side effects, rate limits, or authorization requirements. The mention of 'in bulk' and 'max 50 items' hints at constraints, but overall transparency is minimal.

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 efficiently structured: a one-sentence main purpose followed by bulleted usage guidelines. Every sentence is necessary and non-redundant. It is front-loaded with the core action, making it easy for an AI agent to parse quickly.

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 single parameter array, no output schema, and multiple sibling tools, the description covers everything needed: purpose, when to use, when not to use, and the next appropriate tool. It mentions the output (Explorium business IDs) and the bulk limit (max 50). No gaps remain for typical 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 0% per context, but the description adds guidance: 'Provide one or more identifiers to enhance matching accuracy. Use both name and domain when available.' This adds meaning beyond the property names and types. However, it does not elaborate on format or validation, so it's adequate but not exceptional.

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 retrieves Explorium business IDs from business name and/or domain in bulk. The verb 'Get' and resource 'business IDs' are specific. It distinguishes from sibling tools like fetch_businesses (which may return full data) and enrich_* tools by focusing on ID matching.

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 scenarios (need company size/revenue/industry, analyzing metrics, researching background) and when-not-to-use (looking for specific employees, exec info, when fetch_businesses was already called). It also recommends next step after using this tool (fetch_prospects). This is excellent guidance for an AI agent.

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?

No annotations provided, so description carries full burden. It explains the input constraints (email OR full name+company) but does not disclose side effects, idempotency, authorization needs, or rate limits. It implies a read-only lookup but lacks detail on behavioral traits beyond the matching logic.

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 relatively concise, with the core purpose front-loaded. The bullet points for usage are helpful but some are too broad ('Need prospect enrichment tools'). The 'Do NOT use' section is clear. Minor redundancy can be trimmed.

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 input constraints well but is incomplete on output. It states the tool returns a prospect ID but does not describe the response structure, error handling, or behavior for no matches. Without an output schema, more detail on return values is expected.

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% for the top-level parameter, but nested object has property descriptions. The description adds value by clarifying the required combination of email or full name+company, and mentions optional fields. However, it does not fully compensate for the lack of schema description on the main parameter.

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 gets a prospect ID from email, full name, and company. It distinguishes from sibling tools like enrich_prospects_profiles and fetch_prospects by specifying the matching purpose and when to use it. However, it could be more specific about the exact ID retrieval and how it differs from other prospect 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 explicit 'Use this when:' and 'Do NOT use for:' sections, with specific scenarios like prospect enrichment and contact information. It clearly excludes leadership searches and employee lookups, giving excellent guidance on when to and not to use this tool.

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