PropScorer

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

With no annotations, the description carries the full burden. It discloses that the tool returns live data, KB-backed source context, citations, and freshness/debug metadata, giving insight into the response composition. However, it does not mention limitations such as no-answer handling, rate limits, or potential side effects, and does not explain how the citations or metadata are structured.

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, front-loaded with the core purpose, and followed by concise usage guidance. There is no filler or redundancy; every sentence earns its place.

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 Q&A tool with 4 parameters and no output schema, the description provides essential context about data sources, citations, and metadata, and clearly delineates when to use it. It does not detail the exact output format or error handling, but it is reasonably complete for the tool's complexity and the sibling 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?

The schema descriptions cover 75% of parameters (question, firm_slug, include_raw_sources), but the limit parameter lacks a description. The tool description adds no parameter-specific meaning, so it does not compensate for that gap. The existing schema descriptions are helpful, but the overall parameter semantics are only adequate.

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 answers complex prop firm questions using live data and KB-backed source context. It explicitly distinguishes itself from get_firm_score for simple single-firm score lookups, and positions itself for multi-firm comparisons or nuanced rules questions, differentiating it from comparison-focused siblings.

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 guidance: 'Use for multi-firm comparisons or nuanced rules questions.' It also gives a direct alternative for simple lookups: 'use get_firm_score first for a simple single-firm score lookup,' which acts as a when-not-to-use instruction. This is clear and actionable.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It uses 'Retrieve' to imply a read-only operation and 'KB-backed' plus 'excerpts' to indicate the source and partial nature of returned data, providing some useful context. However, it does not explicitly state whether the operation is non-mutating, safe, or limited by rate constraints, leaving the agent with partial information.

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 front-loads the action ('Retrieve') and resource ('KB-backed rule excerpts'), followed by the purpose. Every word contributes value, with no filler or redundancy.

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

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

The description covers the core purpose clearly but omits important contextual details: it does not clarify the output format (crucial since there is no output schema), explain the role of limit_per_firm, or mention the min/max firm constraints visible in the schema. While the schema covers some constraints, the description leaves the tool's return behavior and limits underspecified 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 description coverage is 67%, with slugs and question described, but limit_per_firm has no description in the schema or the tool description. The description adds no new parameter semantics beyond the schema—its listed comparison areas (drawdown, payouts, etc.) are already in the question parameter's schema description. The lack of any guidance on limit_per_firm is a notable gap.

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

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

The description clearly states the tool retrieves KB-backed rule excerpts for multiple firms, with a specific purpose of comparing drawdown, payouts, consistency, news trading, and prohibited practices. It uses a specific verb ('Retrieve') with a clear resource ('KB-backed rule excerpts') and scope ('multiple firms'), which distinguishes it from siblings like get_firm_rules (single firm) and compare_firms (likely metric comparison).

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 gives clear context: use this when you need to compare rule-related aspects across multiple firms, listing example focus areas. However, it does not explicitly state when not to use it or name alternatives such as get_firm_rules or compare_firms, so it lacks explicit 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 carries the full burden of disclosure. It does not disclose the return format, limitations (e.g., max 6 firms), or behavior on invalid slugs. The core purpose is stated, but behavioral traits are largely absent.

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 with no wasted words. It efficiently conveys the tool's purpose 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?

The tool is simple, but the description lacks details on output structure and does not sufficiently differentiate from compare_firm_rules. Without an output schema or annotations, more context would be helpful for an agent to select the correct tool in all scenarios.

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 only parameter (slugs), with description 'Firm slugs to compare'. The tool description adds no additional parameter semantics beyond what the schema already provides, so a 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 uses the specific verb 'Compare' with resource 'several prop firms' and scope 'side by side using PropScorer metrics', clearly distinguishing it from siblings like compare_firm_rules (which focuses on rules) and get_firm_score (which targets a single firm).

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 needing to compare multiple firms, but it does not explicitly state when not to use it or mention alternative tools. Clear context exists, but no exclusions or alternative 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 are provided, so the description carries full responsibility. It states this is a search operation but does not disclose whether it is read-only, whether special permissions are needed, how the search matches (exact, fuzzy, boolean), or what the response contains. This is a significant transparency 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 a single sentence with useful examples, no redundancy, and the action is front-loaded. It is concise and clear, though the examples make it slightly longer than necessary. It earns a 4 for being efficient without additional explanatory detail.

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 no output schema and no annotations, the description should explain what the tool returns, any limitations (e.g., maximum limit), and the nature of the knowledge base. It only states the search action and examples, leaving the response format and edge cases undisclosed. This is insufficient for full agent comprehension.

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 describes 'query' but not 'limit'. The description adds example rule preferences for the query parameter, providing meaningful context beyond the raw schema. However, it does not explain the 'limit' parameter's behavior, and the schema coverage is only 50%, leaving some parameters without semantic 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 uses a specific verb 'Search' with a resource 'KB' and clarifies the specific scope 'firms matching a rule preference'. Examples of rule preferences are given, making the purpose clear. However, it doesn't explicitly distinguish from sibling tools like 'search_firms', so it doesn't fully earn a 5.

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 searching for firms by a rule preference, and provides example queries. However, it does not state when not to use this tool or mention alternative tools such as 'search_firms' or 'compare_firm_rules' for different use cases.

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 provided, the description carries the full transparency burden. It discloses some behavioral traits: 'currently visible' implies deals may change or be filtered, and 'ranked by discount and public availability' explains ordering. However, it does not mention any limitations, rate limits, authentication, or what happens when no deals are found.

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, concise sentence that front-loads the core purpose and key behavior. It contains no redundant information and is appropriately sized for the tool's simplicity.

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 is simple with two optional parameters and no output schema. The description gives the essence but lacks explanation of the return format and parameter semantics. It is minimally viable but leaves some context gaps, particularly for an agent expecting detailed invocation guidance.

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

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

Schema description coverage is 0%, so the description must compensate but does not mention 'limit' or 'category' at all. The schema provides types, defaults, and an enum, but the semantic meaning of 'category' (e.g., futures vs crypto) is not explained anywhere. The agent must infer parameter meaning from param names alone, which is insufficient for full clarity.

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 function: 'Get currently visible PropScorer promo codes and deals' with a specific verb and resource. It also adds unique qualifiers ('ranked by discount and public availability') and distinguishes from all sibling tools, which focus on firm comparison and rules rather than deals.

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 explicitly state when to use this tool or mention alternatives. However, from the sibling tool names, it is clear that this is the only tool for deals/promo codes, so usage is implied. There is no misleading guidance, but also no explicit 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 of behavioral disclosure. It mentions the data source (KB-backed) and output components (source URLs, freshness metadata), but does not disclose whether the operation is read-only, any prerequisites, error behavior, or 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 single, well-structured sentence that front-loads the main purpose and includes specific output details. Every word earns its place with no filler.

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 no output schema and no annotations, so the description must convey the essential usage context. It provides a solid high-level overview but leaves parameter behavior and when-to-use vs siblings unexplained, making it adequate but not fully 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 description coverage is low (33%, only slug described). The description does not explain 'limit' or 'category' parameters, although the list of excerpt types implicitly maps to category enum values. It adds minimal semantic value beyond the schema, failing to compensate for the coverage gap.

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

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

The description clearly states the verb 'Return' and the resource: KB-backed rules, pricing, payout, FAQ, and terms excerpts for one firm, with source URLs and freshness metadata. It distinguishes from siblings like compare_firm_rules by emphasizing 'for one firm' and the specific knowledge-base categories.

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

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

The description implies usage for retrieving one firm's KB-backed information but does not explicitly state when to use this tool versus alternatives like search_firms, compare_firm_rules, or ask_propfirm_question. No exclusions or alternative references are given.

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

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

With no annotations, the description carries the transparency burden. It clearly lists the data categories returned and provides a working example, which covers the key behavioral aspects for a read-only retrieval tool. It stops short of detailing error handling or data freshness, but the core behavior is well described.

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 only two sentences plus an example, with the main purpose stated up front. Every word contributes value and there is no redundancy or filler.

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 main use case, lists the return fields, and gives examples. Given the low complexity (single parameter) and absence of an output schema, the description is largely complete, though it could have elaborated on the meaning of 'health signals' or mentioned what happens for an invalid slug.

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 documents the 'slug' parameter with 100% coverage. The description adds examples of valid slugs but no additional semantic meaning beyond what the schema provides, 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 uses a specific verb ('Get') and resource ('PropScore, health signals, rules, plans, promos, and editorial notes for one firm'), clearly distinguishing it from sibling tools like get_firm_rules or compare_firms, which have narrower or comparative scopes.

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 before broad Q&A when the user names a single firm,' providing a clear usage context. It lacks explicit alternatives or exclusions (e.g., 'for specific rules use get_firm_rules'), so it doesn't fully earn a 5.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'Return', which implies a read operation, but does not reveal side effects, authentication needs, output format, or any caveats about what 'freshness' entails. This is minimal disclosure.

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, clear sentence that is front-loaded with the core purpose. It is concise and avoids redundancy. However, it could have included usage guidance without being bloated, so it doesn't reach a perfect score.

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 is simple with one optional parameter and no output schema, but the description still leaves ambiguity about what 'coverage and freshness' concretely represent (e.g., scores, timestamps, format). It is minimally viable for a read tool but lacks details that an agent would need to interpret the result effectively.

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

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

Schema coverage is 100% because the sole parameter 'slugs' has a clear description ('Optional firm slugs. Omit to inspect all firms with KB rows.'). The tool description adds nothing beyond the schema, so 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 has a specific verb ('Return') and a clear resource ('knowledge base coverage and freshness for one or more firms'). It distinguishes itself from sibling tools by focusing on KB metrics, though it doesn't explicitly name alternatives. The phrase 'for one or more firms' adds useful scope information.

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. It simply states what it returns, leaving the agent to infer usage. There are no prerequisites, exclusions, or alternative tool recommendations, making this a clear gap.

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 must carry the full burden of behavioral disclosure. It notes that payout stats are included 'when available,' which signals potential missing data. However, it does not discuss authentication, rate limits, side effects, or error behavior. The word 'Return' implies a read-only operation, but this is not made explicit.

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 front-loads the action and resource, then lists specific data types. Every word contributes to understanding the tool's scope, with no wasted or redundant content.

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

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

For a simple one-parameter read tool, the description adequately covers the returned data categories. Since there is no output schema, it gives an overview of available fields (payout speed, transparency, payout stats) and notes the conditional nature. It could be more detailed about return formats, but it is sufficiently complete for typical use.

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

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

Schema description coverage is 100% for the single 'slug' parameter, described as 'Firm slug.' The description adds 'for one firm,' which only slightly reinforces the schema. It does not explain slug format, constraints, or how to obtain valid slugs beyond what the schema already provides.

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 uses the verb 'Return' and specifies the resource as 'payout-related intelligence for one firm,' which distinguishes it from sibling tools like compare_firms or get_firm_score. It further details the data types (payout speed, transparency, payout stats), 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?

There is no explicit guidance on when to use this tool versus alternatives such as get_firm_score or compare_firms. The purpose implicitly suggests use for payout intelligence, but it does not state preferred contexts or exclusions, leaving the agent to infer if it should select this over others.

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 weight for behavioral disclosure. It only states that the tool ranks firms, but does not reveal whether it returns a scored list, the ranking direction, any side effects, or whether the operation is read-only. This is minimal given the lack of annotation support.

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 states the action and key criteria without any fluff. It is concise and structured effectively, with every word contributing meaning.

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 7 parameters, no annotations, no output schema, and several sibling tools, the description is too sparse. It lacks information about return values, ranking methodology, default behavior (e.g., limit=10, category='futures'), or when to choose this tool over find_firms_by_rules or compare_firms. The description is inadequate for full autonomous use.

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

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

Schema description coverage is 71%, so the schema already documents most parameters. The description adds value by grouping parameters into high-level concepts ('price, account size, payout, platform, rule preferences'), which maps to max_price, min_account_size, daily_payouts, platform, and one_day_pass/category. However, it does not introduce semantic details beyond what the schema already provides.

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 specific verb 'rank' with a clear resource ('firms') and enumerates the key criteria (price, account size, payout, platform, rule preferences). This distinguishes it from sibling tools like search_firms, which searches, and compare_firms, which compares, 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?

The description implies a use case ('for a trader profile') and the types of preferences involved, but it does not explicitly state when to use this tool versus alternatives like find_firms_by_rules or compare_firms. No exclusions or alternative guidance is provided, leaving the context to be inferred.

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 only lists searchable fields and does not mention limit behavior, category default, pagination, result format, or read-only nature. This significant gap leaves the agent unsure of expected outcomes.

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 with no filler. It is concise and to the point, but omits useful behavioral and usage details, making it efficient yet incomplete.

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, annotations, and a rich parameter schema, the description is too sparse. It does not mention the default limit (10), maximum (25), or default category ('futures'), nor does it describe what the search returns. For a general search tool among specialized siblings, this is insufficient 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 only 33% (only 'query' has a description). The tool description adds meaning by clarifying that queries can be names, categories, platforms, instruments, or rule preferences, which helps interpret the 'query' parameter. However, it does not explain 'limit' or 'category' beyond what the schema already provides, so compensation is partial.

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

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

The description uses a specific verb ('Search') and clearly identifies the resource ('PropScorer's prop firm database') along with the search dimensions (name, category, platform, instrument, rule preference). It conveys what the tool does but does not explicitly distinguish it from sibling tools like find_firms_by_rules.

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 explicit guidance on when to use this tool versus alternatives such as compare_firms or find_firms_by_rules. There are no when-not-to-use conditions or alternative recommendations, leaving the agent without a clear selection heuristic.

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