mcp-explorium

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. Description adds that it's a prerequisite and returns valid values, but doesn't clarify if the returned list is exhaustive or paginated, which is relevant given the openWorldHint.

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 bullet points and sections, front-loaded with primary purpose. A few redundant phrases like 'standardized parameter values' repeated, but overall every sentence adds value.

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

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

For a simple tool with no output schema, description covers return type (list of values), prerequisite nature, and field constraints. Lacks mention of potential empty results or error handling, but sufficient given annotations.

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 100% coverage with descriptions for both parameters. The description elaborates on field semantics (e.g., NAICS industry codes) and provides search tips, going beyond schema to clarify usage context for each 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 the tool provides standardized parameter values for fetch-entities filter operations, specifying it must be called first. Lists supported fields and distinguishes from sibling fetch/enrich tools, which are searches or enrichment, not parameter lookup.

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

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

Explicitly says when to use (before fetch operations on certain fields) and when not to use (fields with fixed values or free-text). Also notes technical failure if not used, providing strong 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?

Annotations (non-readOnly, non-destructive, openWorld) are present. Description adds context that returns combined structured data and requires business IDs from match-business/fetch-businesses, but does not elaborate on potential side effects or permissions, though annotations already cover the safety profile.

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 sections, bullet points, and bold text. However, it is somewhat lengthy; some details (e.g., enrichment list) could be more concise, but overall efficiently informative.

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 only vaguely states 'Returns: Combined structured data.' For a tool with nested objects and multiple enrichment types, more detail on the return format or example output 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?

Description explains each parameter: business_ids come from specific tools, enrichments are listed with definitions, and parameters object has sub-parameters (date, keywords) with format and usage details. This adds significant meaning beyond the schema, especially for the enrichments enum.

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 enriches business data using business IDs and enrichment types. It lists specific enrichments and provides an example input, making the 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?

Includes explicit 'Alternative Tools' section advising when to use fetch-prospects instead. Also provides an 'IMPORTANT' note to combine enrichments for comprehensive requests, offering clear context on when to use the tool.

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

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

Annotations already provide safety profile (not read-only, not idempotent, not destructive). Description adds that it uses up to 3 parallel calls, but no further behavioral details (e.g., rate limits, mutation specifics). Acceptable given annotation coverage.

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

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

Well-structured with sections and example, but includes redundancy (e.g., repeats input requirements) and has a contradiction between description and schema about enrichment limit. Could be 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?

No output schema provided; description only says 'Combined structured data' without specifics. Lacks details on error handling, prerequisites beyond input IDs, or pagination/limitations. For a tool with 2 parameters, more completeness is needed.

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%, but description adds context by stating provenance of prospect_ids (from match-prospects or fetch-prospects) and detailing enrichment options with descriptions. However, there is a contradiction: description says 'up to 3' while schema allows maxItems 10.

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 verb 'enriches' and resource 'prospect data' with input prospect IDs. Distinguishes from siblings like fetch-prospects and match-prospects by focusing on 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?

Provides explicit guidance to include all relevant enrichments in a single call for comprehensive information. However, does not discuss when to avoid using this tool or alternatives.

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

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

Annotations set readOnlyHint=false (allowing mutations) but description only discusses reading/searching. It adds useful behavioral constraints like search failure without autocomplete and mutual exclusivity of filters, but does not disclose potential side effects, rate limits, or authorization needs.

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 headings and bullet points, but verbose due to exhaustive listing of enum values and repeating some schema descriptions. Could be more concise while retaining clarity.

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

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

Given the complexity of filters and no output schema, the description covers return types (business IDs for further enrichment), critical constraints, and performance notes. Could add pagination behavior but overall sufficient.

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?

Though schema coverage is high (80%), the description adds significant value by grouping filters into types (Enum-Based, Autocomplete-Required) and clarifying dependency on autocomplete for several parameters. It also explains the events filter structure 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 'Searches for businesses using filter criteria' and distinguishes it from siblings like enrich-business or fetch-businesses-events by focusing on search and filtering with specific filter types.

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 extensive usage guidance, including when to use autocomplete-required filters (e.g., 'MUST be obtained from autocomplete tool FIRST') and special cases like 'BUYING INTENT' for sales prospecting. Does not explicitly compare to sibling tools or state when 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.

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

The description claims the tool 'retrieves' data, implying it is read-only, but the annotation readOnlyHint is false, indicating potential side effects. This contradicts the description and misleads the 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 well-structured with a main sentence, bullet points for use cases, and a numbered workflow. It is concise and front-loaded, with no unnecessary words.

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

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

The description covers the tool's place in the workflow and use cases, but it does not mention pagination, rate limits, or the structure of the response (no output schema). This leaves some gaps 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?

With only 33% schema description coverage, the description adds context by explaining that business_ids come from fetch-businesses results and that timestamp_from is a date filter. However, it does not elaborate on parameter formats or additional details.

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 'Retrieves detailed business-related events from the Explorium API in bulk.' It uses a specific verb and resource, and distinguishes from sibling tools like fetch-businesses (which is for filtering) and prospects events tool.

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

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

The description explicitly outlines when to use this tool: after using fetch-businesses with events filter, and it warns to use prospects events tool for role changes. It also provides a step-by-step workflow.

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 destructiveHint=false, clearly indicating a safe, non-destructive operation. The description adds minimal behavioral context beyond stating it is aggregating insights, which aligns with the annotations. 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 a single sentence that conveys the core purpose efficiently. It is front-loaded and contains no redundant or extraneous information.

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

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

Given the complex 'filters' parameter with many sub-properties and no output schema, the description is too brief. It does not explain the required nature of filters, how to use them effectively, or what the returned aggregated insights look like. The annotations cover safety but not functional 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 description coverage is 50%, meaning half of the sub-properties may lack descriptions. The tool-level description does not compensate by explaining parameter meanings; it only mentions the aggregated dimensions. For the undocumented parameters, the agent has no additional guidance.

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 'Fetch', the resource 'aggregated insights', and the dimensions of aggregation (industry, revenue, employee count, geographic distribution). It effectively distinguishes this tool from siblings like 'fetch-businesses' (raw data) and 'fetch-businesses-events'.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'fetch-businesses' or 'fetch-businesses-statistics' for prospects. It does not mention prerequisites, limitations, or that filters are required, leaving the agent to infer usage from the name and schema.

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

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

The description states it returns verified, structured professional data and notes performance optimization, but does not disclose behavioral traits beyond annotations (e.g., no mention of side effects, rate limits, or that openWorldHint=true implies outside data may be included). Annotations already indicate readOnlyHint=false and openWorldHint=true, but the description adds no clarification.

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-organized with sections for use cases, filter types, technical constraints, and returns, and is front-loaded with purpose. However, it is verbose and includes some redundancy (e.g., listing enum values already in schema). Structured readability is good, but could be trimmed without losing essential info.

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

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

Given no output schema, the description adequately explains return value (prospect records with IDs usable by other tools). It covers all filter types, constraints, and performance notes. For a tool with many parameters and complex dependencies, completeness is high, though a note on pagination or result count limits would add value.

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 80% schema coverage, the description adds significant meaning by categorizing filters (enum-based, boolean, autocomplete-required, direct-use), explaining mutual exclusions, and detailing dependencies on autocomplete tools. This goes beyond the schema's property descriptions, making it easier for agents to construct valid requests.

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

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

The description clearly states the tool searches for prospects using detailed filter criteria, with concrete use cases like 'Who is the CTO at Google?' It distinguishes itself from siblings by mentioning that returned prospect IDs can be used with enrich-prospects or fetch-prospects-events, but does not explicitly differentiate from match-prospects or other search 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 guidance on when to use the tool (e.g., combining filters for performance) and technical constraints like mutual exclusions and autocomplete requirements. However, it does not provide 'when not to use' guidance or compare directly to sibling tools like match-prospects or fetch-businesses.

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

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

The description claims 'Retrieves' (read-only), but annotations set readOnlyHint=false, implying possible side effects. This is a contradiction. The description adds no behavioral details 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?

Two concise sentences, no wasted words. The purpose and workflow are 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?

No output schema, but description does not explain return format, edge cases, or error handling. The contradiction with annotations also harms 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 67% with descriptions for event_types and timestamp_from, but prospect_ids lacks description. The description adds no parameter meaning beyond the schema, meeting baseline for high coverage.

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

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

The description clearly states the tool retrieves prospect-related events from the Explorium API in bulk, but does not explicitly differentiate from siblings like fetch-businesses-events or fetch-prospects-statistics.

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 a clear workflow example ('Fetch businesses > Fetch prospects > Fetch prospects events') indicating when to use it, though it lacks explicit when-not-to-use guidance or alternatives.

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 read-only, idempotent, non-destructive behavior. The description adds output structure details (total_results, job_department_breakdown, country_breakdown) which provides some behavioral context but does not cover other traits like pagination or error handling.

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 two sentences and a bullet list, but it lacks mention of the required 'filters' parameter, making it less helpful. It is front-loaded but could be more complete without adding length.

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 complex input schema with many nested filters and no output schema, the description is incomplete. It does not explain that a filters object is required or that many filtering dimensions are available, leaving the agent to rely entirely on the schema for usage 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 high (all filter parameters have descriptions), so the baseline is 3. The description does not add any parameter information beyond what the schema provides, merely mentioning the two breakdown dimensions.

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 aggregated insights by job department and geographic distribution, distinguishing it from sibling tools like fetch-prospects which returns individual prospects. The output structure further clarifies the resource type.

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

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

No explicit guidance on when to use this tool vs alternatives (e.g., for individual prospects use fetch-prospects). The description assumes the agent will infer usage from context but provides no direct or indirect usage hints.

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=true, idempotent=true, etc. The description adds valuable context beyond annotations: business IDs are required for enrichment, cannot be used interchangeably with prospect IDs, and lists data characteristics (verified, structured B2B data). No contradiction with annotations.

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

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

The description is relatively long but well-organized with labeled sections (Input Options, Returns, Technical Requirements, etc.). Each section serves a clear purpose. It is not overly verbose given the amount of useful context, but 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 the tool's complexity (2 parameters, no output schema), the description covers input options, technical dependencies on enrichment tools, use cases, and example queries. It explains that the return value is business IDs, compensating for the lack of an output schema. It is complete enough for an AI agent to understand 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?

The input schema has 2 parameters with 50% description coverage (tool_reasoning and businesses_to_match with item property descriptions). The description adds meaning by showing example JSON inputs for name only, domain only, and both, and explains that the output (business IDs) are the key result. This compensates for the lack of full schema descriptions.

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

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

The description clearly states that the tool retrieves business IDs required as input for business enrichment operations (enrich-business, fetch-businesses-events). It distinguishes from siblings by noting that fetch-businesses also returns business IDs, so this tool may be unnecessary after that. The specific verb 'retrieves' and resource 'Explorium business IDs' make the purpose precise.

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 to use this tool (to get business IDs for enrichment) and when not to (not needed after fetch-businesses). It provides input options (name only, domain only, or both) and recommends both for accuracy. It also includes extensive use cases and example queries, giving clear context for 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?

Consistent with annotations (readOnlyHint, idempotentHint, etc.). Adds details about data characteristics (verified, current, structured) and input requirements 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?

Well-structured with sections and bullet points, clear and informative. Slightly verbose 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?

Given no output schema, description fully explains what is returned (prospect IDs), input requirements, use cases, and relationships with other tools. Complete for a retrieval 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 already has descriptions for both parameters. Description complements by clarifying the purpose of the output and use cases, but does not add significant new parameter-level detail.

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 tool retrieves prospect IDs required for enrichment operations. Distinguishes from sibling tools like enrich-prospects and fetch-prospects-events by specifying its role as a prerequisite.

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 when to use (before enrichment operations) and when not needed (after fetch-entities). Provides specific use cases and clarifies that prospect IDs are not interchangeable with business IDs.

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

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

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying the return format (titles, URLs, snippets) and that it covers public information not in Explorium's BI data. No contradictions with annotations.

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

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

The description is well-structured with sections and bullet points, front-loaded with the core purpose. Every sentence adds unique information, and there is no redundancy or fluff.

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 required parameter, no output schema, and thorough annotations, the description fully covers the tool's behavior, return values, and usage context. It is complete for its complexity.

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

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

Schema coverage is 100% with a description for 'query' that already states it's a search query string. The description adds contextual guidance on query types but doesn't provide format, examples, or constraints beyond 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 'Perform web search using Explorium Search capabilities' with a specific verb and resource. It lists concrete use cases like general web searches and news, distinguishing it from sibling tools like match-business or enrich-prospects.

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 provides when-to-use (general web searches) and when-not-to-use (company/people queries) with named alternatives such as match-business, match-prospects, and fetch-prospects. This gives an agent clear decision criteria.

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