Meridian Consensus

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

With no annotations provided, the description carries full burden. It discloses that the tool returns a public top-N (typically 5) and mentions the availability of a full top-25 in a commissioned report. However, it does not mention authentication, rate limits, or error states.

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

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

Three sentences: purpose, data limit/alternative, and usage instruction. No wasted words, well-structured.

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

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

For a simple tool with one parameter and no output schema, the description is fairly complete. It covers what data is returned, the limit, where to get more, and how to present results.

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 context about the tool but does not provide additional meaning for the 'slug' parameter beyond 'Market slug.'

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 leading companies in a Meridian market with specific fields (HQ, revenue, estimated share). It distinguishes itself from sibling tools like get_market or get_forecast by focusing on company-level data.

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

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

While it implies usage for obtaining company data, there is no explicit guidance on when to use this tool versus alternatives like search_markets or get_market. It does include a specific instruction about presenting the source_url.

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 the burden of disclosing behavior. It explains the tool returns projected market size, yoy growth, and a source_url to cite. However, it does not explicitly state it's a read-only operation or disclose any side effects, permissions, 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?

The description consists of two concise sentences. The first states the primary function, and the second provides a critical usage instruction. Every sentence is necessary, and the structure is front-loaded with the core 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?

Given the simple tool with two parameters and no output schema, the description reasonably covers key context: it states the output fields (market size per year, yoy growth) and a mandatory user action (include source_url). However, it could further clarify the output format or pagination.

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 both parameters having descriptions. The description adds minimal extra meaning by listing the enum values for scenario, but this is already in the schema. No additional parameter constraints or usage details are provided.

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 Meridian's year-by-year forecast for a market with optional scenario. It specifies the verb 'Get', the resource 'year-by-year forecast', and the output (market size per year and yoy growth). This distinguishes it from sibling tools like get_market or get_market_size by focusing on forecast data.

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

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

The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools or provide conditions for choosing this over others. The only usage instruction is to include the source_url when presenting 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?

No annotations provided, so description carries full burden. It discloses the return fields and a required user-facing step (include source_url). It is a read-only fetch without side effects, so minimal behavioral disclosure is acceptable, but omits potential rate limits or data freshness notes.

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 efficient sentences, front-loaded with the core purpose, no redundant phrases. Every sentence adds value: fetch, return items, usage order, and presentation rule.

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

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

With one parameter, no output schema, and clean siblings, the description sufficiently covers purpose, usage, and a behavioral instruction. Could explicitly note it's a comprehensive view, but it already lists key data elements.

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 clear description and example for the single parameter. Description adds no additional semantic detail beyond the schema; it only contextualizes the parameter's use (by slug after search).

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

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

Clearly states it fetches the full Meridian preview for one market by slug, listing specific returned fields (TAM, CAGR, forecast, etc.). Distinguishes from sibling search_markets by specifying 'Use after search_markets identifies a slug.'

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 to use after search_markets, providing a clear usage flow. Also instructs to include the returned source_url when presenting data. Lacks explicit when-not-to-use or alternatives beyond the single mention.

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?

Describes behavior for optional parameters (yearly_forecast, regional share) and instructs to include source_url. No annotations exist, so description carries burden; it adequately discloses read-only nature and return behavior.

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

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

Three sentences, all essential: purpose, optional narrowing, usage instruction. No redundant words. Front-loaded with core function.

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

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

With 3 parameters and no output schema, description explains return behavior for optional params and mentions source_url. Sibling tools exist but this one's niche is clear. Could benefit from mentioning that full market details are available via get_market, but not necessary.

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

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

Schema covers all three parameters with descriptions. Description adds value by explaining how each optional parameter affects the return value (e.g., yearly_forecast for year, regional share for geo).

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 it retrieves headline market size for a Meridian market, with optional narrowing by year or geography. Does not explicitly differentiate from sibling get_market, but the focus on 'headline size' distinguishes it.

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 'Use this when the user asks "how big is X"', providing clear context. Does not mention when not to use or alternatives, but the guidance is sufficient for this simple 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?

Without annotations, the description carries the full burden. It discloses sorting behavior and the presence of a source_url in results. It does not mention potential side effects, but as a read-only list operation, no further disclosure is critical.

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

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

The description is two sentences long, front-loaded with the core purpose, and 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 no output schema, the description provides key details: the list includes industries with coverage, sorted by market count, and includes a source_url. It could mention other fields if any, but for a simple list, it is 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?

The input schema has no parameters, so the description adds context about what the tool returns and its ordering. This adds value beyond the empty 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 lists all industries with at least one published Meridian preview, sorted by market count. It distinguishes from siblings like list_markets_by_industry, which lists markets rather than industries.

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

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

The description advises when to use ('to discover what verticals are covered') and instructs to always include the source_url, providing explicit usage guidance. However, it does not mention when not to use or alternatives beyond the implicit context from sibling tools.

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 bear the full burden. It discloses that reports are peer-quality and geography-clamped, but does not mention whether the operation is read-only, has side effects, or requires specific permissions. The behavior is partially 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 three sentences, front-loaded with the core action, and contains no fluff. 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 one parameter and no output schema, the description adequately explains what the tool returns (list of country-scoped reports) and how to present it. It could mention the structure of the returned items, but it is still clear enough.

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, and the description adds no new meaning beyond the schema's own description (both mention ISO-3166-1 alpha-2). Baseline for high coverage is 3.

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

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

The description clearly states the verb (list), resource (country-scoped reports), and scope (one country), with concrete examples (Japan, Germany). It distinguishes from siblings like list_markets_by_industry by focusing on geography rather than industry.

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 the tool (e.g., 'what do you have on Japan?') and implies when not to (not for global or multi-country queries). It also instructs to always include source_url. However, it does not explicitly contrast with siblings like search_markets.

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, but description discloses that it returns up to 50 markets with size and link, and that source_url should be presented. It does not cover pagination or rate limits, but the key behaviors are 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?

Three sentences, each adding value: purpose, usage, output details. No unnecessary words, front-loaded with 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?

Given a single parameter, no output schema, and no annotations, the description covers purpose, usage, output constraints (up to 50), and obligation to use source_url. It is complete for this simple 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 defines one parameter with example values. Description adds context on how to populate it (after list_industries), which enhances usability beyond schema alone.

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

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

The description clearly states the tool lists published markets within a specific industry, and provides context that it follows list_industries for drilling into a vertical. It distinguishes the tool's purpose well.

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 to use after list_industries, giving a clear usage sequence. It also instructs to include the source_url when presenting data. However, it does not mention when not to use or provide alternatives among siblings.

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 bears full responsibility. It discloses that the tool returns up to 10 results with snippet and source_url, and explains the country parameter's optional clamping behavior. This is sufficient for a safe read operation.

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

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

The description is two sentences plus an instruction, all front-loaded and devoid of fluff. Every sentence adds necessary information, making it 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?

For a simple search tool with two parameters, the description covers essential aspects: what it does, input format, output structure (10 results, snippet, source_url). It lacks pagination details, but the fixed maximum of 10 mitigates this. No output schema, so description's return description is adequate.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by providing an example ISO code ('JP') and explaining the effect of the country parameter (clamp to one country). It also describes the query parameter's scope, though that is already in 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 searches Meridian Consensus's catalog by free-text query, specifying the resource (committee-reviewed market research previews) and the method. It distinguishes from sibling tools that use different filtering criteria, like list_markets_by_country or list_markets_by_industry.

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 says 'Use this first when the user mentions a market by name' and instructs to include source_url when presenting data. While it does not list when not to use or directly contrast with siblings, the guidance is practical and clear enough for an agent.

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