luxalgo-mcp-server

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

With no annotations, the description carries the behavioral burden and does provide useful context: presets are precomputed nightly, each preset explains its meaning in plain language, and the tool returns ids. The read-only nature is implied by 'List' and 'catalog,' and the description adds operational context without contradicting anything.

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 sentences with no fill. The first sentence front-loads the tool's purpose and examples; the second states the exact output and connection to edge_report. Every part contributes.

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?

This is a low-complexity list tool with two parameters, high schema coverage, and a simple return value. The description states what is returned and how it relates to edge_report, while the schema covers the optional category behavior. Nothing critical is missing for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, and the category parameter is already described as narrowing to one category. The tool description adds illustrative examples but no parameter-specific semantics beyond what the schema already provides, so the baseline 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 clearly defines the tool as a catalog of session-statistics presets, naming specific example categories (gap fills, opening-range breakouts) and stating the return value ('Returns preset ids for edge_report'). This differentiates it from the sibling edge_report tool, which is the consumer of those ids.

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 intended workflow is implied by 'Returns preset ids for edge_report,' but the description never explicitly says 'call this before edge_report' or explains when not to use it. The use case is reasonably inferable, but the guidance is not explicit.

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 fully carries behavioral disclosure. It reveals that the tool returns a precomputed read-only estimate with a specific honesty envelope: Wilson 95% CI, N, minimum-sample guards, stability split, per-year counts, value distribution, and disclaimer, plus the caveat that these are historical frequencies, not predictions.

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 dense but free of filler, front-loading the core result and then enumerating the report contents. The long first sentence packs many useful specifications; it could be slightly more scannable as a list, but every element 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?

In the absence of an output schema, the description enumerates all meaningful return components and the source of valid preset/symbol ids. Combined with the historical-not-predictive caveat, the agent has enough information to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents preset, symbol, and context. The description adds the relationship between these parameters and the output probability, but it does not need to compensate for missing schema documentation; 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?

Description states a specific resource ('hosted Edge Stats report') and the exact semantic content: a precomputed P(outcome | conditions) result for a preset on a hosted symbol. It clearly differentiates from siblings by defining the report as a single statistical artifact and pointing to edge_presets/edge_symbols as source lists.

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 when you need a precomputed conditional-frequency estimate for a known preset/symbol, and it warns that the result is not a prediction. It does not explicitly enumerate when-not-to-use alternatives, but the dependency chain and historical-frequency caveat make the intended usage clear.

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?

There are no annotations, so the description carries the behavioral burden. It discloses what data is included, what data is excluded, and data provenance. However, it does not explicitly state whether this is a read-only metadata lookup, whether any freshness guarantees apply beyond 'when the nightly build last ran,' or what the output shape looks like. It is adequate but not deeply 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 earn their place: scope, exclusions, and workflow routing. The content is front-loaded with coverage details before the sibling guidance. It is compact, though slightly more verbose than the minimal two-sentence ideal because it repeats some framing around 'hosted Edge Stats.'

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 and a single generic context parameter, the description provides enough for an agent to decide to call this tool and understand what it will see. It lists the included data categories and gives the recommended next steps. The main gap is not describing the return structure, but for a coverage/metadata tool this is a minor omission.

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 only parameter is a generic `context` field with detailed instructions. The description does not need to explain it and adds no parameter-specific meaning. Baseline 3 is appropriate because the schema already handles the parameter documentation.

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 identifies the resource (hosted Edge Stats store) and enumerates its contents: symbols, session calendars, coverage windows, session counts, and nightly build time. It also says what is NOT covered (session statistics from the open-source engine), which separates it from related stats concepts. It lacks an explicit action verb like 'list' or 'return', so it is clear but not maximally 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 provides explicit workflow guidance: 'Start here, then edge_presets for the questions you can ask, then edge_report for a result.' It also tells the agent that session statistics come from the open-source edge-stats engine, preventing misuse of this tool for that data. This is strong when-to-use and alternative-routing information.

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 explains that the output is markdown, outlines the sections included, and notes the requirement for an exact slug to succeed. This gives the agent a clear expectation of what the call returns and what input is needed, though it does not mention error handling for invalid slugs or any authentication/rate-limit considerations.

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 with no filler. It front-loads the primary purpose and output format, then immediately gives usage guidance and a prerequisite. Every sentence contributes essential information for selecting and calling the tool correctly.

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 a simple getter with two documented parameters and no output schema, so the description provides more than enough context: what it does, what the markdown includes, when to use it, and how to obtain the required slug. There is no missing information that would prevent an agent from invoking it correctly.

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

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

Schema description coverage is 100%, so the input schema already thoroughly documents both parameters: slug is described with examples and guidance to get it from search/list results, and context has a detailed multi-sentence explanation. The tool description reinforces the slug requirement but adds no meaningful semantic information 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 states a specific verb ('Explain') and resource ('a trading concept') and details the exact content returned: the Library's full write-up as markdown, including definition, formula, how traders read it, and indicator implementations. It clearly distinguishes itself from sibling get tools like library_get_family or library_get_source_code by focusing on the conceptual write-up.

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 to use this for 'what is X / how does X work' questions, providing clear context for when to invoke it. It also directs agents to find the required slug via library_search or library_list_concepts, naming the relevant alternatives for satisfying the prerequisite. It does not explicitly state when not to use sibling get tools, but the use case is specific enough.

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 disclosing behavior. It explains the output form (markdown), the content (overview plus concept roster), and the fact that it covers a complete family hub. Nothing contradicts the annotations because no annotations exist.

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 with all essential information front-loaded. The first sentence states what is returned; the second gives the usage context. 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?

The tool is simple, with only two parameters, both fully documented in the schema, and a clear output description. The description supplies the needed usage and intent context, so an agent has enough information to invoke it correctly.

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

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

Schema description coverage is 100%, and both parameters are already well documented in the schema with enum values and an example for 'key'. The description adds no additional parameter-level meaning, 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 clearly states that the tool returns a family's hub page as markdown with the written overview and complete concept roster. This distinguishes it from the sibling library_get_concept and library_get_indicator tools by focusing on the whole family rather than individual items.

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 tells the agent when to use it: after library_list_families, or when the user asks about a whole area such as 'SMC' or 'Wyckoff'. This gives clear contextual conditions 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?

With no annotations, the description carries the behavioral disclosure burden. It discloses what the tool returns (details, family, concept links, preview image) and clarifies a key boundary: it only indicates source-code availability and does not return the code, directing to a sibling for that. This gives the agent accurate expectations beyond the input schema.

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

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

Two sentences accomplish a lot: the first enumerates the return content compactly, the second gives the usage trigger and a cross-reference to the source-code sibling. Every phrase adds value with no repetition 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?

Given the tool's simple scope and lack of an output schema, the description adequately covers what the agent needs: what the tool does, what information it returns, when to use it, and what it deliberately does not return. The schema covers parameters fully, so no critical information is missing.

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%, so the baseline is 3. The schema fully documents 'slug' and the 'context' parameter with examples and constraints. The description does not need to add parameter details, and it doesn't, which is acceptable.

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 and resource ('Details for one indicator') and enumerates exact content: what it does, how to read it, family, concept links, preview image, and source-code availability. This clearly differentiates it from list/search/source-code siblings by focusing on a single indicator's detailed profile.

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: 'Use when the user asks about a specific indicator.' It also points to library_get_source_code as the alternative for fetching code itself. It does not explicitly contrast with library_search or library_list_indicators for non-specific queries, but the guidance is clear enough for correct tool selection.

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 behavioral burden. It discloses that the tool returns the full working source, that sources are long, and that the tool is scoped to TradingView indicators. It does not explicitly state read-only behavior or output format, but the getter semantics and source-code return are clearly conveyed.

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 with no filler. The primary purpose is front-loaded, and the second sentence earns its place by explaining when to use the tool and why it is separate from a sibling.

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 two-parameter getter with no output schema, the description covers the essential outcome and the one cautionary behavior (long source). It could add explicit read-only confirmation or return format, but nothing critical is missing for correct selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level detail beyond the schema, but none is needed since both slug and context are already well documented.

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 states a specific verb and resource: it returns the full, working source code of a Library indicator on TradingView. It also explicitly distinguishes itself from library_get_indicator, so an agent can tell them apart immediately.

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 explicit when-to-use guidance: call it only when the user wants the code itself, and contrasts it with library_get_indicator, which exists for the indicator itself. This leaves no ambiguity about which sibling to choose.

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 signals a read-only browsing operation, states that results are paginated, and indicates that family filtering is optional. It also implies the output contains slugs usable by library_get_concept, but it does not detail the page response contents or pagination behavior beyond that.

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 compact, front-loaded with the core purpose, and every sentence earns its place. It covers scope, pagination, family filtering, the intended downstream use, and the preferred alternative 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 the tool's low complexity, no output schema, and absence of annotations, the description is sufficient for an agent to invoke it correctly. It covers what the tool enumerates, how it can be filtered, what the output is useful for, and when not to use 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?

Schema coverage is 75%, so the schema already documents page, page_size, and context. The description adds meaning by explaining the output intent ('find slugs for library_get_concept') and clarifying that family is an optional filter, going beyond the raw parameter names and enum values.

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 specifies a concrete verb and resource: 'Browse every trading and technical-analysis concept in the Library', adding pagination and an optional family filter. It also clearly distinguishes the tool from library_search and library_get_concept, so an agent can tell them apart without inspecting schemas.

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 explicit when-to-use guidance: 'Use to enumerate a topic area or find slugs for library_get_concept' and 'for keyword lookup prefer library_search.' This directly routes the agent to the correct sibling tool for the alternative use case.

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 transparently reveals the return contents: 17 families, concept counts, and hub links. However, it does not explicitly state that it is read-only or describe any other behavioral traits such as ordering, pagination, or data freshness.

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 dense sentences with no filler. The first sentence delivers the core scope and output contents, and the second sentence frames the usage recommendation. Every phrase contributes value.

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

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

For a simple read-only list tool with one parameter and no output schema, the description covers the essential points: what the resource is, what data will be returned, and when to call it. It could add an explicit pointer to library_get_family for deeper exploration, but that is not necessary for correct invocation.

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

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

Schema description coverage is 100%: the only parameter, context, is thoroughly documented with an example and explicit constraints. The tool description adds no additional parameter-level insight, so the baseline 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?

Uses a specific verb and resource: 'List concept families', and further clarifies it is the Library's top-level taxonomy with 17 families and detailed contents. The phrase 'top-level taxonomy' and 'natural first call' distinguish it from sibling tools like library_list_concepts or library_get_family.

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 this tool: 'The natural first call for orientation.' This gives clear positional context among the many library siblings. It does not name explicit alternatives or when-not-to-use scenarios, so it stops short of 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, the description carries the full burden, and it delivers useful behavioral context: server-side sorting, newest-first default, AND-combined tags, and concept-slug semantics. It does not mention response format or pagination behavior, but for a read-only browsing tool the disclosed behavior is largely sufficient.

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 dense, purposeful sentences with no filler. The core behavior and filtering scope are front-loaded, and the alternative-tool guidance is placed at the end without diluting the message.

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

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

Despite 11 params and no output schema, the descripion gives enough orientation for a browse tool: key filter categories, one composite filter example, and a route to the sibling search tool. It doesn't explain pagination or result shape, but schema defaults and the nature of a list operation make that gap minor.

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 high at 82%, so the baseline is 3. The description mostly restates what the schema already documents, though it adds useful framing such as 'AND-combined' for tags and 'implementations of one concept' for concept slugs. It does not add meaning for direction or page_size, but those are adequately covered by schema metadata.

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?

States a clear verb ('Browse') and a specific resource ('indicator catalog') with the available filtering dimensions. The description also distinguishes this tool from library_search by positioning it as structured browsing, making its role 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?

Explicitly tells the agent when to use this tool: structured browsing with concrete query examples ('latest indicators', 'everything in the volatility family'). It also names the alternative for keyword discovery—library_search—so the agent can route between siblings confidently.

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 and it does disclose key behavioral aspects: it returns IDs, the tags represent behavioral traits, and the tags are orthogonal to the taxonomy. It does not cover rate limits or errors, but for a simple read-only list operation the behavior is adequately conveyed.

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 with no filler: it states what the tool returns, how to use those returns, and the key distinction from the taxonomy. All information is tightly packed and front-loaded with the 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?

For a simple list tool with one required parameter and no output schema, the description provides the essential context: what is listed, what the return values are for, and how they relate to other tools. It could mention ordering or exhaustiveness, but those are not critical for correct invocation.

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

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

Schema description coverage is 100% for the single context parameter, so the schema already thoroughly documents it. The tool description adds no additional parameter-level meaning, which aligns with the baseline of 3 when the schema handles parameter documentation.

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 the Library's indicator tag vocabulary and that it returns IDs for use as the tags filter in library_list_indicators. It is specific about the resource and purpose, and the mention of orthogonality to the concept-family taxonomy differentiates it from sibling taxonomy 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 explicitly indicates when this tool is useful: when the agent needs tag IDs to pass to library_list_indicators' tags filter. It also implicitly distinguishes from concept/family list tools by noting tags are orthogonal to that taxonomy, though it does not name alternative tools or state 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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals useful traits: alias-aware search ('stochastics' finds Stochastic Oscillator), coverage breadth (800+ concepts and indicators), and result contents (slugs and canonical URLs). It does not cover failure behavior or read-only guarantees, but for a search tool this is reasonable.

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 earning its place: the first names the tool and resource, the second details capability with a concrete example, the third gives usage guidance and output content. Information is front-loaded and there is zero 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?

Given five parameters and no output schema, the description provides enough operational context: what is searched, when to use it, what results contain, and how results connect to sibling tools. The unusual context parameter is fully documented in the schema, so it need not be repeated here.

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%, so the baseline is 3. The description adds some nuance beyond the schema by framing query as an 'informal term or topic' and giving an alias example, but it does not add meaning to the type, limit, family, or context parameters that the schema does not already provide.

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 states a specific verb ('Search'), a specific resource ('the LuxAlgo Library'), and the scope ('800+ concepts' and '800+ ready-to-use indicators'). It also distinguishes the tool from its get/list siblings by noting that results 'carry slugs for the get tools' and by branding it as the entry point ('Start here').

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?

It explicitly tells the agent when to start: 'Start here whenever you have a name, informal term, or topic.' It also implies the downstream workflow by saying results carry slugs for the get tools. However, it does not explicitly say 'if you already have a slug, use library_get_* instead,' so the when-not guidance is slightly implicit.

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 full burden, and it does so thoroughly. It discloses live data provenance from LuxAlgo, the LUXALGO_APP_ORIGIN override, the distinction between verbatim and inferred fields, the presence of provenance/inferredFields in results, refusal behavior for non-simulatable challenges, and the authority of the firm's own page.

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 long, but it is densely packed with consequential details that are not available elsewhere, such as loss-rule semantics, units, provenance, and simulation compatibility. It is front-loaded with the core purpose and uses clear section labels, though a more streamlined structure would improve scannability.

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 lack of an output schema, the description is exceptionally complete: it explains the full shape of the returned ruleset, the semantics of each major rule category, units for percent values and winRate, provenance/inferredFields handling, and how the returned challenge object can be fed into simulation tools. An agent has enough context to call and correctly interpret 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 description coverage is 100%, so the baseline is 3. The description does not add much parameter-specific meaning beyond the schema, though it reinforces that firmId and challengeId come from propfirms_list_simulatable. No parameter semantics are missing, but the description also does not elevate the parameter 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 ('Fetch') and a specific resource ('one directory challenge's complete ruleset (ChallengeSpec)'), and clearly differentiates itself from sibling tools by stating that propfirms_get and propfirms_search_challenges serve the full listing instead. It also clarifies that this tool returns the simulatable encoding, distinguishing it from listing-oriented 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 explicitly tells agents when to use this tool vs alternatives: it returns the simulatable encoding, while the listing with every captured field and live offers is propfirms_get and propfirms_search_challenges. It also explains how the returned object can be copied and modified for re-simulation, and notes refusal behavior when loss rules cannot be established.

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 behavioral burden, and it does substantial work: it discloses that rows are ordered by EV for the caller's specific inputs, that different trader profiles reorder them, that unsimulated rules make numbers optimistic, that consistency rules and payout gating ARE simulated (engine v1), and that results are distributions under assumptions, not promises. It also explains determinism (byte-identical with same seed) and the expectation to surface assumption flags/disclaimer. Minor shortfalls: it doesn't explicitly state whether the tool performs network access for directory references vs offline inline specs (though the schema does), and it doesn't describe error 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?

The description is long but every section earns its place: purpose, non-ranking caveat, flags caveat, engine version disclosure, units, determinism, and assumptions. It is front-loaded with the core action and the critical "NOT A RANKING" caveat. The UNITS and ASSUMPTIONS sections are wordy and somewhat repetitive (the flagsNotSimulated caveat appears in both the row-list paragraph and the ASSUMPTIONS paragraph), which prevents a 5.

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 16 parameters, no annotations, no output schema, and nested challenge/spec objects, the description is remarkably complete: it explains units, determinism, how to present results, what is simulated vs. not, and where to route for deeper analysis. It does not enumerate return-value shape (no output schema, so a brief mention of the per-row columns exists in the description, which it does provide: perAttemptPassProbability, fundedProbability, expectedAttempts, expectedCost, evTotal, pEvPositive, daysToFundedP50, flagsNotSimulated). It is missing explicit guidance on what errors can occur (e.g., mixing spec and firmId, both/neither error) though the schema covers that, and the description assumes the agent will discover directory references via propfirms_list_simulatable rather than stating it directly.

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%, so the schema already documents all 16 parameters thoroughly. The description still adds meaningful semantics on top: the UNITS paragraph clarifies the percent-vs-fraction distinction (every *Pct field and percent-mode riskValue in percent units, except winRate as a fraction), the DETERMINISM paragraph instructs the caller to include seed and path count when reporting, and the ASSUMPTIONS paragraph tells the caller to surface flags/disclaimer. That goes beyond the schema, though the heavy lifting is done by the schema's rich per-parameter 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 leads with a specific verb ("Simulate") and resource (the SAME trader across several challenges, up to 12) and immediately clarifies the output (one row per challenge sorted by expected value). It also explicitly differentiates itself from a ranking or endorsement and mentions the sibling propfirms_simulate for full distributions, so an agent can distinguish it from the adjacent simulation 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 states exactly when to use this tool (comparing the same trader across challenges under identical options/seed) and names the alternative ("run propfirms_simulate on the interesting rows" for full per-challenge distributions). It also gives strong negative guidance: "THIS IS NOT A RANKING" and "never 'best firm'", plus explicit handling guidance for unsimulated flags and assumptions.

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 behavioral disclosure burden. It discloses that null fields are omitted and that challenges reference offers via offerIds, which goes beyond a simple return-value list. It does not mention failure behavior or rate limits, but for a read-only retrieval tool the disclosed behaviors are sufficient.

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 dense but each sentence earns its place: content inventory, slug lookup guidance, structural detail about nulls and offerIds, and an alternative-tool pointer. Slightly longer than minimal, but well-organized 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 lack of an output schema and the tool's complex return payload, the description thoroughly inventories what the agent will receive: profile, challenges, offers, overview, plus relational details like offerIds and null omission. The alternative-tool pointers round it out, making it complete for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description confirms propfirmId is a slug and directs users to propfirms_search for finding valid slugs, reinforcing the schema's existing parameter description without adding significant new 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?

The description identifies a specific verb and resource: fetching one prop firm's full dossier by slug. It enumerates the dossier's components, clearly distinguishing this tool from siblings like propfirms_search and propfirms_pass_rates.

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?

It explicitly tells agents to use propfirms_search to find slugs first, and to use propfirms_pass_rates for simulated pass odds. This provides clear routing guidance and prerequisite context without leaving inference to the 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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the live data source, keyless API access, origin override via environment variable, inference provenance, inferredFields disclosure, the notSimulatable refusal policy, and the caveat that firms change rules and their own pages are authoritative.

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 and front-loaded with the primary purpose and call-this-first guidance. However, the warning that challenges with unestablishable loss rules are listed as notSimulatable rather than guessed appears twice, making the text slightly longer than necessary.

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?

Even though there is no output schema, the description fully explains what the tool returns: simulatable challenges, firm/challenge IDs, account details, price, provenance, and inferredFields. It also addresses ordering, endorsement, data source, and limitations, so an agent has enough context to call and interpret the result correctly.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description does not add substantial parameter-level meaning beyond what the schema provides, 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 clearly states a specific action ('List the prop firms in the live LuxAlgo directory together with every simulatable challenge') and enumerates the exact fields returned. It also distinguishes itself from sibling tools by explaining that the full directory is served by propfirms_search, propfirms_search_challenges, and propfirms_search_offers.

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 the agent to call this first to discover accepted firmId + challengeId pairs for multiple sibling tools. It also states what this tool does NOT cover and routes the full-directory use case to propfirms_search, propfirms_search_challenges, and propfirms_search_offers.

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 present, the description carries the full burden and delivers extensively: it discloses common random numbers across grid points, byte-identical determinism from seed, compute cost (~10 seconds at default grid/paths), the typical divergence between the two optima and what it means, and the mandatory surfacing of assumptions.flags and the disclaimer. It also instructs agents to never present one number as THE optimal risk, which is behavioral guidance no annotation could express.

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 long but well organized, front-loaded with the core sweep behavior and the dual-optima distinction, and broken into labeled sections (UNITS, DETERMINISM, ASSUMPTIONS). For a 20-parameter tool with no annotations and no output schema, nearly every sentence carries load-bearing information; only minor redundancy (e.g., the full-simulation-per-point idea stated twice, default grid values also present in the schema) keeps it from a 5.

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 complex tool with 20 parameters, nested spec objects, no annotations, and no output schema, the description covers what the tool returns (both optima plus a diverges flag), how to interpret the divergence, unit conventions, reproducibility, compute cost, and the requirement to surface assumption flags and disclaimers. The only gap is a full enumeration of the result shape, but the named output fields and extensive risk-context guidance make that unnecessary for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, and the description earns the extra point by clarifying unit traps the schema leaves implicit (winRate is a fraction while everything else is percent units) and by explaining the grid/riskMode relationship and the compute trade-offs among min, max, step, and paths. It reinforces the schema's seed-reproducibility note and adds useful new advice to re-run with several seeds to gauge Monte Carlo spread.

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 names a specific verb and resource: 'Sweep risk-per-trade over a grid, run the full journey simulation at every point,' and it precisely defines the two outputs (bestByPassProbability and bestByEv). This clearly distinguishes the tool from siblings like propfirms_simulate and propfirms_pass_rates, which evaluate single scenarios or pass rates rather than optimizing over a risk grid.

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 strong operational guidance: parametric trader only, use a coarse grid or fewer paths for a first pass then refine around the optima, and adjust grid units via riskMode. However, it never explicitly contrasts with sibling tools or states when NOT to use this tool in favor of a single-point simulator, so the selection context is implied rather than explicit.

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 full behavioral burden and does so thoroughly. It discloses deterministic computation, caching, low cost, live derivation from directory rules, provenance handling, the need to relay inferred fields, and a detailed list of returned metrics. No contradictions with structured data exist.

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 long single paragraph, but nearly every sentence adds essential value: methodology, caveats, return contents, and alternatives. It is front-loaded with the core purpose and uses parentheticals efficiently, though bullet points would improve scannability.

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

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

Despite no output schema or annotations, the description enumerates the full set of returned metrics (pass probability, 95% CI, P(funded), expected attempts/cost, EV, payout/blowup probabilities, assumption flag ids, provenance) and provides interpretation safeguards. It also directs to authoritative sources for current rules and offers, making the tool self-sufficient 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?

Input schema has 100% parameter description coverage, so the baseline is 3. The description mainly restates the firmId source and challengeId omission behavior already present in the schema; it adds context about output interpretation rather than new parameter-level semantics.

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 specific function: computing reference challenge pass rates per archetype from the directory's encoded rules, with exact methodology (same engine, seed 42, path count 10,000). It also distinguishes itself from siblings by explicitly saying it is not the user's personal odds and not a ranking, directing to simulate tools for personal 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?

The description explicitly says when to use this tool: as reference odds for orientation and comparison, not for the user's own statistics. It names alternatives (propfirms_simulate, propfirms_simulate_trades, propfirms_get, propfirms_search_offers) and clarifies that a firm's page is authoritative and lastVerified should be checked, providing strong routing 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?

No annotations are present, so the description carries the full disclosure burden. It discloses the matching rule (a firm matches when at least one challenge/offer matches all filters), null-field omission, include/nesting behavior with offerIds references, and explicitly states the tool returns directory data rather than simulated outcomes. This goes well beyond a bare 'search' statement.

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 long but dense, and each sentence earns its place: purpose, filter semantics, include behavior, sibling routing, and the directory-vs-outcome caveat. The action and resource are front-loaded before implementation details, which is appropriate for this level of complexity.

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

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

For a 54-parameter tool with no output schema and no annotations, this is quite complete: it covers matching semantics, include behavior, null-field omission, expected response kind, and routes to companion tools for dossiers and simulations. It could be stronger by describing the exact response envelope or disambiguating against propfirms_search_challenges and propfirms_search_offers, but those are 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 description coverage is 100%, so the baseline is 3, and the description adds valuable meta-semantics: how firm, challenge, and offer filters combine, the invariant that at least one challenge/offer must match all filters, and the rule that omitting every filter lists all firms. It also explains include payloads and null handling, helping the agent reason across the 54 parameters without repeating each one.

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 names the exact verb ('Search') and resource ('LuxAlgo's prop-firm catalog') and clarifies the subject as proprietary trading firms offering funded accounts. It also distinguishes the tool from propfirms_get ('full dossier'), propfirms_pass_rates, and propfirms_simulate, so an agent can tell it apart without opening the schema.

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?

It explicitly states when to use this tool ('Omit every filter to list all firms') and names alternatives for related intents: 'for one firm's full dossier prefer propfirms_get' and 'for simulated pass odds... use propfirms_pass_rates or propfirms_simulate'. It does not explicitly route to the overlapping propfirms_search_challenges and propfirms_search_offers siblings, so the guidance is strong but not exhaustive.

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, and it delivers: it discloses that null rule fields are omitted and never match filters, that include=['offers'] returns a deduplicated top-level offers list with challenge-to-offer references, and that the result is a rules snapshot, not an outcome simulation. These are non-obvious behaviors an agent must know.

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 four sentences, front-loaded with the core purpose, and every sentence earns its place: scope, filter categories, id-based retrieval, offer inclusion, null-field behavior, and sibling-tool routing. There is no filler or repetition.

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 36-parameter tool with no annotations and no output schema, the description is remarkably complete: it explains purpose, scope, null handling, offer inclusion, and which sibling to use for outcomes. The only noticeable gap is the lack of any detail about the top-level response shape or pagination beyond what the schema already states, which is a minor omission given the schema's richness.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds genuine value by explaining how propfirmId and challengeId change the query scope, what include=['offers'] returns and how offerIds link to challenges, and that null rule fields cannot match filters. This exceeds a bare restatement of 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 opens with a specific verb and resource: 'Search funded-account challenges across all visible prop firms.' It also distinguishes itself from outcome-oriented siblings by stating 'This returns each challenge's listed rules and terms, not outcomes,' making its purpose unmistakable even without opening the schema.

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?

Usage guidance is explicit both within the tool ('Pass propfirmId to list one firm's challenges, or challengeId to fetch specific ones') and across alternatives ('to simulate... pass its ids to propfirms_simulate or propfirms_pass_rates, and to screen... use propfirms_validate_strategy'). It also clarifies what the tool does not do, which helps an agent choose correctly.

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 and it delivers: live-only default, challenge matching including firm-wide offers, and the fields every offer carries. It does not cover pagination or sorting behavior, but those are documented in the schema and are secondary for 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?

Three compact sentences: purpose and default, key filters, and result content. The most important information is front-loaded and there is 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?

For a tool with 18 parameters and no output schema, the description covers the core semantics and states what each returned offer contains. It leans on the exhaustive schema for the remaining filters, which is acceptable; a brief mention of pagination would have made it 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 coverage is 100%, so the baseline applies. The description reinforces propfirmId and challengeId semantics but adds little beyond the schema; 'firm-wide offers included' is already effectively captured by the challengeId schema text.

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 names a specific verb and resource: 'Search promotional offers (discounts and promo codes) across prop firms.' It then scopes the resource further with propfirmId and challengeId, which separates it from siblings like propfirms_search and propfirms_search_challenges without needing to open the schema.

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?

It clearly states the default (live offers only) and gives two concrete routing filters: propfirmId for a single firm and challengeId for offers applicable to a challenge. It does not explicitly name when-not-to-use alternatives, so it stops short of 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 and meets it thoroughly: simulated vs non-simulated rules with flags (consistency-stop-rule, funded-withdrawal-model, funded-consistency-window-approximated), byte-identical determinism with seed, the requirement to surface assumptions.flags and disclaimer alongside numbers, network vs offline behavior, and refusal of non-simulatable challenges rather than guessing. Even a deprecated flag id is noted. No contradiction with annotations (none exist).

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 long, but every paragraph carries dense, non-redundant information and it is front-loaded with the core purpose in the first sentence. Capitalized section headers (SIMULATED RULES, UNITS, DETERMINISM, ASSUMPTIONS, DATA SOUCE) aid navigation. The length will tax an agent's parsing, but nothing reads as filler; slight tightening would improve scannability.

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 19-param tool with nested objects and no output schema, this description is effectively complete: challenge identificition options and validation rules, detailed return-object fields (perAttempt, journey, funded, ev, assumptions), omitted histograms, units conventions, determinism and seed guidance, assumptions-flags surfacing requirement, data provenance, and composition with external broker tools. An agent has everything needed to select, parameterize, and interpret this tool correctly.

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

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

Schema description coverage is 100% with already-rich per-parameter descriptions, so baseline is 3. The description adds genuine meaning above that: the coherent R-multiples framing across all trader params, the clear percent-units vs fraction exception for winRate, and the explicit currency-to-R conversion formula for composing with broker-statistics tools. This is net-new guidance beyond individual schema fields.

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 names a specific verb and resource: 'Monte Carlo-simulate a trader with the given statistics through a prop-firm challenge and (by default) a funded horizon.' It answers concrete user questions (pass chance, funded probability, expected attempts/cost, EV, which rule kills attempts) and distinguishes itself from the closest sibling propfirms_simulate_trades ('prefer propfirms_simulate_trades - it preserves streaks').

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 this tool vs alternatives: raw trade series route to propfirms_simulate_trades; directory discovery via propfirms_list_simulatable; inline spec shape from propfirms_challenge_rules for what-if rule edits. It also states the mutual-exclusivity error condition ('providing both or neither is an error') and the offline/network trade-off between inline specs and directory references.

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 carries the full burden and exceeds it: it discloses that newsFilter runs the simulation TWICE and returns the news-avoided scenario, that portfolioOverlap is ALWAYS analyzed with an audit-risk verdict, that consistency/payout rules are simulated rather than flaggged, the units quirk (winRate fraction vs percent), byte-identical determinism, and the material assumptions that must be surfaced to the user. This is far beyond what annotations would provide.

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?

Effectively front-loaded with purpose and sibling routing in the first sentences, and organized with ALL-CAPS section headers (TIMESTAMPED LOGS, NEWS WINDOWS, PORTFOLIO MODE, SIMULATED RULES, UNITS, DETERMINISM, ASSUMPTIONS) that make the ~800 words scannable. It is long, but the tool genuinely has four input modes, a news comparison, portfolio mode, and simulated-rule flags; most sections earn their place. Slight redundancy with the already-detailed schema (e.g. newsFilter and blockMeanLength are described in both).

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 21-parameter tool with nested objects, four mutually exclusive input formats, no output schema, and multiple behavioral modes, the description is remarkably complete: it covers input selection and parsing, return shape (defers to 'the same full SimResult as propfirms_simulate' plus text summary), news comparison carry-over fields, portfolio overlap verdict, engine-v1 flags, unit conventions, determinism, assumption surfacing, and composition with broker-statistics tools. Not athing material an agent needs to call it correctly is missing.

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 already-rich per-parameter descriptions, so baseline is 3. The description adds genuine meaning on top: the R-multiple definition and conversion formula (avgWinR = avgWin / avgRisk), the UNITS clarification for winRate, why blockMeanLength tuning matters for streaky series, and the instruction to include seed/path count when reporting for reproducibility.

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 opens with a specific verb+resource+method: 'Simulate a challenge by resampling the trader's OWN R-multiple trade series with a stationary block bootstrap instead of a win-rate model.' It explicitly differentiates from the sibling propfirms_simulate ('use this whenever the actual trades are'), so an agent can pick correctly without inspecting schemas.

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?

Gives explicit routing: 'Use propfirms_simulate when only summary stats are available; use this whenever the actual trades are.' It also states the exact-one-of-four input constraint, minimum sample sizes (at least 10, 100+ recommended), and explains when timestamped logs unlock newsFilter and derived tradesPerDay. Alternatively none needed.

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 full behavioral burden, and it does: deterministic per seed, one simulation per challenge, exclusion/counting of non-encodable rules, optimism flags, refusal above 40 challenges, no live discounts applied, and the honesty frame that this is a screen, not an endorsement. This is model-level transparency.

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 dense but every sentence carries real decision-relevant content, with the core question and default bar front-loaded. It is a single monolithic paragraph rather than structured sections, which slightly hurts scannability, but for a 25-parameter tool with no annotations, this length is justified.

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 exists, yet the description enumerates the return fields per challenge: pass probability with 95% CI, P(funded), expected attempts/cost, EV, P(EV>0), assumption flag ids, and inferred rule semantics. Combined with the honesty frame, scope limits, follow-up routing, and schema-covered parameter details, nothing critical is missing for correct invocation.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning beyond the schema: the stationary block bootstrap preserves streaks that breach loss limits, winRate overestimation can flip EV negative, average loss 1 means stops are honored, EV scales with fundedHorizonDays, and the bar must always be stated. These are exactly the semantics that change how an agent selects and interprets 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 opens with the exact question the tool answers ('which challenges would MY strategy actually pass?') and names a specific verb/resource: simulate a strategy through every simulatable challenge in the live directory. It clearly distinguishes this all-challenges screening tool from the single-challenge optimization mentioned afterward.

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 strong context: when to use it (one-call screening across challenges), refuses scopes above 40 challenges instead of truncating, and routes follow-up single-challenge sweeps to propfirms_optimal_risk. It does not explicitly contrast with sibling tools like propfirms_simulate or propfirms_pass_rates, but the screening purpose is clear enough.

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, and it does well by disclosing the data source (CC0 public-record dumps), the list-view return fields, and the detailed-view contents including caveats and source health. It implies a read-only operation through 'Returns' and 'Pass dataset,' but it does not explicitly state the absence of side effects or mention pagination/auth, preventing a top score.

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 purpose and uses four sentences with no filler. The long first sentence packs a broad catalog list, which is arguably useful for agent discovery, though slightly dense. Every sentence earns its place, and the final sentence folds in usage guidance cleanly.

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 catalog tool with no output schema, the description is nearly complete: it specifies both list-view and detailed-view return content, covers the optional dataset parameter, and ties the tool into the broader query workflow. Minor gaps like error behavior, result ordering, or data update frequency prevent a 5, but the description is sufficient for an agent to call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: it enumerates the dataset categories (congressional trades, insider transactions, etc.) and explains what the detailed view yields (full field roster, filterable paths, caveats, per-year coverage, source health, dump URLs). This goes beyond the schema's one-line descriptions and helps the agent choose between list and detailed views.

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 the Market Trackers catalog, enumerates what it returns (row count, freshness, years, ticker-searchability), and explicitly distinguishes it from the query tool by instructing the user to read it before composing trackers_query filters. The title and opening sentence establish a specific verb and resource with no ambiguity.

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 for when to use this tool: as a catalog discovery step before composing trackers_query filters. It also explains the optional dataset parameter behavior ('Pass dataset for the full field roster...'). However, it does not explicitly mention alternatives like trackers_latest or trackers_ticker or state when not to use it, leaving some inference required.

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 and does add meaningful behavioral context: it returns only the newest daily publish's rows, references the latest.json source, and notes unavailability for certain datasets. It stops short of explicitly stating read-only behavior or describing output/pagination characteristics, though those are at least partially covered by the schema.

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

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

Three sentences, with the core concept front-loaded and the exclusions stated clearly. The phrasing 'the cheapest way to see what is new' is slightly promotional, and the example list is helpful but not strictly necessary, so it is concise without being maximally tight.

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 an 8-parameter tool with no output schema and no annotations, the description plus the rich schema is mostly sufficient. It captures the key limitation around patents and the ticker/text narrowing options, though return-value shape and the trackers_ticker alternative are left for the agent to infer or discover.

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 already documents all 8 parameters in detail, so the baseline is 3. The description only lightly reinforces the ticker/text filtering options and does not add 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 clearly explains that the tool returns the newest ingestion day's rows for a dataset, optionally narrowed by ticker or text, and cites the underlying source ('the dumps' latest.json'). It distinguishes itself from trackers_query for patent datasets, but does not explicitly differentiate from the trackers_ticker sibling.

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 a clear use case ('The cheapest way to see what is new') and an explicit exclusion with an alternative ('Not available for snapshot-only bulk datasets (patents); use trackers_query there'). However, it does not discuss when trackers_ticker would be more appropriate for ticker-focused lookups.

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 and does so thoroughly. It discloses year-sharded CC0 dumps, the default newest-year behavior, byte-budget refusal with narrowing advice, deep-history size caveats, and provenance.sourceUrl on every row. This is far beyond what the schema or annotations would provide.

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 dense but efficient, front-loading the core purpose in the first sentence and packing performance caveats, provenance, and three targeted examples into the remainder. Every sentence contributes to correct invocation, and the length is justified by the tool's complexity and 11 parameters.

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, full schema coverage, no annotations, and no output schema, the description is remarkably complete. It covers dataset selection, year scoping, byte limits, row provenance, and example use cases, and it points to trackers_datasets for metadata. An agent has enough context to select and call the tool correctly.

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

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

Although schema coverage is 100%, the description enriches parameter meaning by explaining the relationship between years and since/until, warning that deep-history years are large and recommending one at a time, and giving concrete examples mapping parameters to values (ticker NVDA, years [2024], where {code: 'P'}, text 'Tuberville'). This adds strategic guidance not present 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 opens with a specific verb and resource: 'Search one Market Trackers dataset' followed by the exact filter dimensions (ticker, free text, field values, date range, paging, ordering). It differentiates from siblings by positioning this as the query tool for a single dataset, while trackers_datasets is referenced only for metadata like archiveYears and dataset ids.

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 usage context through examples (insider purchases, senator trades, lobbying on a bill) and practical guidance on when to read one or two years at a time for deep-history datasets. It does not explicitly say when to use trackers_latest or trackers_ticker instead, but the reference to trackers_datasets for metadata implies the relationship between the 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 exist, so the description bears the full burden and it delivers: it discloses the return shape (per-dataset match counts with newest rows), the default year, and the skipped-years behavior with a pointer to trackers_query. It also characterizes the source as public-record primary sources, setting expectations about provenance.

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, with dataset scope front-loaded in sentence one, output semantics in sentence two, and the edge-case routing in sentence three. Every sentence earns its place and there is 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?

For a fan-out tool with 4 parameters, no output schema, and a nontrivial skipped-years behavior, the description covers purpose, scope, output, default, and fallback call. An agent can invoke it correctly and know exactly what to do with skipped years.

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%, so the baseline is 3. The description only restates the year default, which is already in the schema, and says nothing extra about limit, ticker, or context beyond their schema descriptions, so no uplift is warranted.

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 states the operation explicitly: one ticker across every ticker-bearing Market Trackers dataset for one year, and it enumerates the dataset families (insider transactions, congressional trades, 13F holdings, etc.). This clearly distinguishes it from siblings like trackers_query, which is referenced for deep-history archive years.

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?

It identifies a concrete trigger for an alternative: deep-history archive years too large for one fan-out are listed under skipped and should be read with trackers_query. It implicitly frames this tool as the broad multi-dataset dossier lookup, though it does not enumerate all sibling distinctions such as trackers_latest.

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