LuxAlgo Library MCP

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 well: it discloses read-only behavior, states that the server cannot trade, and reveals the cache behavior. This goes beyond the bare schema and gives the agent realistic expectations about 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?

Three tightly packed sentences: the first states scope and return content, the second warns about caching and routes to broker_refresh, and the third reinforces safety. 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 parameterless list tool with no annotations and no output schema, the description is complete: it explains what is returned, the caching caveat, the live alternative, and the safety restriction. An agent has everything necessary to select and call 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?

The tool has zero parameters and the schema coverage is effectively complete, so there is nothing for the description to clarify. The field list adds useful context about what the response contains, which is the relevant semantic information here.

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: listing all connected accounts across every configured broker, and enumerates the returned fields (id, name, broker, currency, total equity, cash). This clearly distinguishes it from sibling tools that cover positions, trades, stats, or refresh operations.

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 that it uses a short-lived cache and points to broker_refresh when live numbers are needed. It clearly frames when this tool is appropriate, though it does not exhaustively discuss all sibling alternatives or exclusions.

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

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

With no annotations, the description carries the transparency burden. It usefully explains that negative quantity means short, market value is in the account currency when the broker prices it, and average entry price is provided where reported. However, it does not explicitly state that this is a read-only operation with no side effects, nor does it mention 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?

The description is a single front-loaded sentence that covers the core purpose, returned fields, key caveats, and the optional filter without any filler. Every clause adds information an agent needs.

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

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

For a simple tool with one optional parameter and no output schema, the description adequately explains the scope, field semantics, and data caveats. The main omission is an explicit statement that the result is a list/array and what happens when there are no open positions or no connected accounts.

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

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

The only parameter, broker, has 100% schema description coverage and includes concrete examples. The tool description simply restates that filtering is optional, adding no meaning beyond the schema, 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 identifies the resource (open positions) and scope (all connected accounts), and enumerates the returned fields. It lacks an explicit imperative verb such as 'list' or 'get' and does not differentiate itself from sibling tools like broker_trades, so it is clear but not fully distinguished.

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

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

There is no guidance about when to use this tool versus alternatives such as broker_trades, broker_accounts, or broker_stats. The only usage hint is the optional broker filter, which is parameter-level guidance rather than tool-selection guidance.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool bypasses caching, refreshes all configured brokers, and returns per-broker success/failure. It stops short of mentioning rate limits, failure details, or whether the operation is safe/idempotent, but the core behavior and return shape are clear.

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 tight sentences with no filler. The most important behavioral fact, cache bypass, is front-loaded, and the return value is stated succinctly.

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 zero-parameter refresh tool, the description is largely complete: it explains the action, the reason (bypass cache), the scope (every configured broker), and the result format. It lacks minor context such as potential slowness or error handling, but nothing essential 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?

The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The baseline of 4 applies because the description fully covers what an agent needs to know about invocation: no arguments are required.

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 action ('Bypass the 5-minute cache and re-fetch every configured broker right now') with a clear resource and behavior. It also distinguishes itself from sibling query tools like broker_accounts and broker_stats by focusing on refreshing rather than reading data.

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

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

The description clearly implies when to use this tool: when cached broker data is stale or up-to-the-minute data is needed. It does not explicitly name alternatives or exclusions, but the cache-bypass framing provides enough context to select it over read-only sibling tools.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that it never reveals credential values, only whether they are set in the session, and that key guides are read-only. This is useful transparency, though it does not explicitly state whether the tool performs any network calls or has side effects.

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

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

The description is two sentences with no filler. The first sentence front-loads all substantive content, and the second sentence gives precise invocation triggers. Every clause earns its place.

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

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

For a zero-parameter informational tool with no output schema, the description is complete: it explains what is returned, what is deliberately not returned, and when to use it. An agent can decide to call this tool correctly without needing additional details.

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 tool has zero parameters and 100% schema coverage, so the baseline of 4 applies. The description adds no parameter-specific details because there are none to document; it correctly focuses on the tool's informational contents.

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 what the tool provides: an inventory of every connectable broker/exchange, the environment variables for credentials, whether they are set in the current session, and one-line key-creation guides. This distinguishes it from data-oriented siblings like broker_accounts, broker_positions, and broker_trades.

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 says when to call it: first when no broker data comes back, or when the user asks how to connect an account. It does not explicitly name sibling alternatives or state when not to use it, but the 'call this first' phrasing gives clear context.

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

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

No annotations are provided, so the description carries the full burden. It discloses important non-obvious behavior: amounts remain in each account's native currency, mixed-currency totals are approximate, and trade stats are FIFO-matched. These are genuinely useful behavioral details beyond a simple 'get stats' 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 front-loaded with the core purpose and then expands into a structured list of outputs and a caveat. The second sentence, while dense, provides actionable routing to sibling tools without wasted words. Every clause 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?

With no output schema, the description adequately covers the return contents, including per-symbol breakdown and realized PnL. It also communicates the mixed-currency approximation caveat and provides alternative tooling for sequence-accurate simulations. For a zero-parameter analytics tool, nothing essential 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?

The input schema has zero parameters, so there is nothing for the description to clarify. The baseline of 4 applies: no parameter ambiguity exists, and the description focuses on output and usage rather than 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 a specific verb and resource: 'Computed performance across the whole portfolio', and enumerates the exact outputs (total equity, equity by broker, top positions, FIFO-matched trade stats). This clearly differentiates broker_stats from siblings like broker_positions and broker_trades, which return raw data.

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

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

The description gives explicit routing guidance for prop-firm odds: use propfirms_simulate from these stats, or broker_trades with propfirms_simulate_trades for sequence-respecting odds. However, it does not explicitly contrast broker_stats with broker_positions or broker_trades outside that odds context, though the aggregate-vs-raw distinction is strongly implied.

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 delivers: it discloses the broker-specific recency window, newest-first ordering, the output shape, and the critical refusal behavior for mixed-account histories. This adds meaningful context beyond the raw 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?

The description is three dense sentences, each earning its place. It front-loads the core purpose and ordering, then gives the integration workflow, then the critical warning. No filler or redundancy.

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

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

Despite having no annotations and no output schema, the description provides enough context to invoke the tool correctly: what it returns, how results are ordered, available filters, how to use the result downstream, and a key constraint. The schema covers parameter limits, 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 description adds value by clarifying that broker/symbol filters are optional and, more importantly, by explaining the broker-filtering requirement when multiple accounts are connected. This goes beyond the schema's simple 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 clearly identifies the tool as returning executed trades across all connected accounts, with an explicit ordering ('newest first') and optional filters. This distinguishes it from sibling tools like broker_positions, broker_stats, and broker_accounts.

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 usage context: it explains how to feed the result into propfirms_simulate_trades and warns to filter to one broker/account first because mixed-account histories are refused. It does not explicitly name alternatives like broker_positions, but the workflow and constraints are 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?

With no annotations, the description carries the burden, and it does disclose the catalog is precomputed nightly, explains what each preset provides, and states that the return value is preset ids for edge_report. It does not discuss auth, rate limits, or exact output shape, but for a simple read/list tool these omissions are minor.

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: it front-loads the catalog concept, gives concrete examples, explains the presets' value, and closes with the output relation to edge_report. Every sentence earns its place and there is no fluff.

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

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

For a simple optional-parameter list tool with no output schema and no annotations, the description covers what the tool does, what its data represents, and how the returned ids are used. The category behavior is already documented in the schema, so nothing critical is missing for an agent to call 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?

The only parameter, category, has a schema description ('Narrow to one category (the result lists all categories)'), giving 100% schema coverage. The tool description itself does not mention the parameter, so it adds no additional meaning beyond the schema; baseline 3 is appropriate.

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

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

The title and description clearly state the tool lists Edge Stats report presets and returns preset ids for edge_report. This distinguishes it from the edge_report tool, which likely consumes those ids rather than listing presets.

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 establishes the tool as a catalog of precomputed session-statistics questions and explicitly ties the output to edge_report, making it clear this is the discovery/preview step before running a report. It does not explicitly contrast with siblings or say when not to use it, but the context is 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?

With no annotations provided, the description carries the full disclosure burden and does so well: it states results are precomputed, framed as historical conditional frequencies rather than predictions, and enumerates the statistical guards (Wilson 95% CI, minimum-sample guards, stability split, per-year counts, disclaimer). It leaves failure modes unaddressed, but for a read-only report tool the honesty-envelope detail is unusually 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?

Tightly front-loaded with the core message ('One precomputed session-statistics result') and every clause earns its place — the honesty-envelope list and the 'not predictions' caveat are all informative. It reads as a dense run-on em-dash chain, so scannability suffers slightly, but there is no wasted verbiage.

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

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

For a simple two-parameter read tool with no output schema, the description compensates by spelling out the full return envelope: estimate, N, Wilson interval, minimum-sample guards, stability split, per-year counts, value distribution, and disclaimer. The only notable omission is error behavior for invalid preset/symbol values, which the schema examples partially mitigate.

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

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

Schema coverage is 100%, and both parameter descriptions already include examples ('gap-fill', 'BTCUSDT') plus cross-references to edge_presets and edge_symbols. The tool description repeats that sourcing relationship but adds nothing materially new beyond what the input schema states, so the high-coverage 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?

States a specific deliverable — 'One precomputed session-statistics result: P(outcome | conditions) for a preset on a hosted symbol' — and details the return contents. The epistemic qualifier 'Historical conditional frequencies, not predictions' further pins down what the tool does. References to edge_presets/edge_symbols distinguish it from the sibling listing tools that supply its inputs.

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 closing sentence, 'Preset ids come from edge_presets; symbols from edge_symbols,' implies the correct calling workflow and routes the agent to the data-source siblings. The 'Historical conditional frequencies, not predictions' phrase acts as a when-not-to-use caution. No explicit comparison to an alternative report tool is given, but the guidance 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, the description carries the transparency burden. It discloses the scope of data covered, the nightly build timing, and the boundary between this tool and the open-source edge-stats engine. It does not describe return formatting or size, but for a zero-parameter coverage tool this is sufficient context.

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

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

Three sentences, each earning its place: the first defines scope, the second clarifies what is not included, and the third gives the workflow. It is front-loaded with the most important information and contains 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 zero-parameter tool with no output schema, the description is complete: it explains what the tool covers, where it fits in the workflow, and what it does not provide. An agent can confidently invoke it as the starting point for Edge Stats questions.

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 tool has zero parameters, so there is nothing for the description to explain about arguments. The empty input schema is already fully covered, and the description appropriately focuses on content rather than parameters. This matches the baseline for a no-parameter tool.

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 timestamp. It lacks a strong imperative verb like 'List' or 'Get', but the phrasing 'What the hosted Edge Stats store covers' is specific enough to tell an agent what this tool returns and distinguishes it from edge_presets and edge_report.

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 workflow guidance: 'Start here, then edge_presets for the questions you can ask, then edge_report for a result.' It also clarifies that session statistics come from a separate open-source engine, which helps an agent avoid expecting statistical results from this tool.

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

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

Annotations cover safety/idempotency, but the description adds real context beyond them: the OAuth LuxAlgo sign-in requirement, the duplicate-skip rule, the fill-to-trade derivation model (long = buy then sell, lone fill opens a position), and the return shape. That is substantive behavioral disclosure the annotations do not carry.

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 core action and account constraint are front-loaded in the first clause, and each following sentence contributes distinct value (derivation rules, duplication behavior, return shape, exclusions, auth). Dense but free of 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 nested-fills write tool with no output schema, the description supplies everything an agent needs: account eligibility, fill ordering/derivation semantics, duplicate handling, auth prerequisite, and a summary of what is returned.

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 domain semantics the schema does not: ISO 8601 instants with offset, fees being per fill, and how side/sequence map onto trade direction. It goes past restating field descriptions without documenting every individual field.

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?

Specific verb (log/add) plus resource (fills into a journal account) with an explicit scope constraint: only `manual` or `import` accounts, never broker-synced ones. It also names journal_update_trade as the follow-up consumer of returned keys, so an agent can separate it from siblings without opening 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?

States when to use it (hand-logging fills to manual/import journals) and when not to (broker-synced accounts, correcting or removing existing fills — done in the app). It routes the agent to journal_update_trade for subsequent edits, leaving little to inference.

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

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

Annotations declare readOnlyHint and openWorldHint, so safety is covered; description adds what annotations cannot: the auth requirement (LuxAlgo OAuth sign-in), the default-all-time behavior, the breakevens-excluded rule, and the sample-size rationale. Lacks disclosure of return format/pagination, but no output schema exists so this is a modest gap.

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

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

Front-loaded with the core purpose and the nine-dimension enumeration, then defaults, then routing guidance, then auth. Every sentence earns its place. Slightly dense with the long enumeration and metric list, but no wasted 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?

Covers purpose, grouping dimensions, returned metrics, default window, scoping, sibling routing, and auth — substantial for a 4-param read tool with no output schema. Missing only pagination/result-size limits, which is minor given the schema is fully documented.

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

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

Schema description coverage is 100% and the schema already documents range/from/to override precedence and account id semantics. The description's 'narrow with range or from/to' corroborates but adds no syntax or format detail beyond the schema. Baseline 3.

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

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

States a specific verb+resource ('P&L breakdown' of closed trades) and enumerates the nine grouping dimensions and the eight aggregate metrics returned. Differentiates from the sibling journal_overview by name, and positions it against 'what am I good or bad at' questions.

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?

Explicit when-to-use ('what am I good or bad at' questions vs journal_overview for headline numbers), explicit defaults ('Defaults to all time, since groups need sample size'), and explicit scoping guidance (narrow with range or from/to). The narrow-vs-broad tradeoff is spelled out.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the OAuth/LuxAlgo sign-in requirement, the timezone semantics ('Days are in the journal timezone'), and the null-cell convention for days without trades. These are real behavioral facts not recoverable from the annotations.

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

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

Dense but front-loaded: it leads with what the calendar contains, then defaults, then the sibling route, then auth. Every clause carries information, though the long enumerations of cell fields make it heavier than strictly 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?

With no output schema, the description carries the burden of explaining return values and does so thoroughly, including per-week and per-month aggregates and the null convention. Auth prerequisites and the day-drill route are also covered, leaving little an agent would need to infer.

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 both `month` and `accounts` (including defaults, rejection of unknown ids, and archived-account behavior). The description restates the current-month default but adds no parameter detail the schema lacks; baseline 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 states exactly what the tool returns: one month of the P&L calendar with week rows, day cells, per-week and per-month aggregates, and the trade statistics included. It is clearly distinguishable from siblings like journal_get_day (single-day drill-down) and journal_overview (different scope).

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 gives explicit operating guidance: omit `month` for the current month, and 'Drill into one day with journal_get_day' routes the agent to the day-level alternative. It does not say when to prefer this over journal_overview or journal_breakdown, so it stops short of full when/when-not coverage.

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

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

Annotations already cover read-only and open-world nature, but the description adds real behavioral detail beyond them: stats is null when nothing traded, how 'trades' is defined (closed that day OR opened that day and still open), and that OAuth sign-in is required. These edge cases and the auth requirement meaningfully improve invoke correctness.

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

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

Front-loaded with the return payload, then the date key, then usage, then auth requirement — each clause earns its place with no padding.

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

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

With no output schema, the description correctly enumerates the return shape (stats, trade summaries, notes with ids) and discloses the auth prerequisite. It stops just short of noting the accounts scoping or any pagination/limit behavior, but is otherwise complete for invoking the tool.

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

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

Schema description coverage is 100%, so both `date` and `accounts` are already fully documented in the schema. The description restates the date format but adds no syntax or semantics beyond it, and omits the accounts scoping entirely, leaving the schema to carry the load — the baseline 3.

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

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

The description states exactly what the tool returns for a specific resource (a single trading day): stats, trade summaries, and notes with ids. The single-day scope inherently distinguishes it from aggregate siblings like journal_overview or journal_calendar, so an agent can route correctly 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 gives concrete when-to-use guidance ('how did Tuesday go') and a downstream workflow ('to find note ids for journal_update_note'), which is genuinely useful routing. It lacks an explicit when-not or a named alternative tool, so it lands at 4 rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond them: the OAuth/LuxAlgo account requirement and the fact that hidden fills and user corrections are exposed in the response. It stops short of noting pagination or payload size, but for a single-record read that is minor.

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

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

Front-loaded with the returned payload, then usage guidance, then auth. The long field enumeration is dense but earns its place because there is no output schema; still, it could be tightened slightly for readability.

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

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

With no output schema, the description compensates by itemizing the response contents, and it covers the trigger, prerequisites, and auth requirement. An agent has everything needed to select and invoke 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% and the schema's own description already instructs that the key must come from sibling tools and never be constructed. The body text adds no syntax or format detail about the key, so the baseline 3 applies — the schema does the heavy lifting here.

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 specific verb and resource — fetch one trade in full — and enumerates exactly what the payload contains (summary fields, fills, per-exit gross P&L, hidden fills, annotations). This distinguishes it cleanly from list/day/search siblings that return multiple trades or partial data.

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

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

Explicitly says when to call it: 'Use after journal_list_trades or journal_get_day when the user asks about a specific trade or before annotating it.' It names the prerequisite siblings and the downstream workflow (annotating), leaving nothing to inference.

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

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

The annotations already declare a safe read-only open-world operation, and the description adds important behavioral context: OAuth sign-in requirement, empty-list semantics, and the downstream constraint that other tools reject unknown account ids. It also discloses the returned account metadata without needing an output 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?

The description is front-loaded with the purpose and then usage guidance, and every clause adds useful information. It is somewhat dense because it lists many returned fields in one long sentence, but that detail is justified without an output schema.

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 no input parameters, the description fully covers what the tool returns, when to call it, authentication requirements, and empty-state behavior. An agent has everything needed 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?

The tool has zero input parameters, so there are no parameter semantics to describe. The baseline for a no-parameter tool is 4, and the description does not need to compensate for missing schema coverage.

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

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

The description states a specific verb and resource: listing the signed-in user's trade-journal accounts. It also enumerates the returned fields and distinguishes itself from siblings by saying other journal tools' `accounts` filters depend on these 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?

It explicitly says to call this first, explains why other journal tools reject unknown account ids, and notes that journal_add_trade requires a `manual` or `import` account. It also tells the agent what an empty list means and what authentication is 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real context beyond that: an OAuth/LuxAlgo-account auth requirement and the result ordering contract ('most-used first with the number of trades carrying each'). Only the sort/aggregation behavior is disclosed; nothing about pagination or limits, so it lands just short of full marks.

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 carrying a distinct payload: what the tool returns, when to call it, and the auth requirement. The scope constraint and the sibling exclusion are front-loaded before the trailing auth note.

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

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

With no output schema, the description compensates by describing the return shape (tags with trade counts, most-used first) and the auth prerequisite. It is essentially complete for a low-complexity read tool, though it says nothing about result size or truncation.

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 single optional 'accounts' parameter is fully documented in the schema, including the journal_list_accounts source, the omit-for-all behavior and rejection of unknown ids. The description adds nothing further about parameters, so the baseline 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?

Names a specific resource ('the user's annotation vocabulary') and precisely enumerates what it contains: every tag, mistake and playbook id attached to any trade, open or closed. It also explicitly carves out what it does NOT cover ('per-trade tags are on each trade summary, not here'), which lets an agent separate it from journal_get_trade and journal_list_trades.

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 an explicit when-to-use rule tied to a named sibling workflow: 'Check it before journal_update_trade so new annotations reuse the user's own words instead of minting near-duplicates.' That is both the condition and the rationale, leaving nothing to inference.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses non-obvious behavior: keyset pagination requiring identical sort/order/filters on the cursor call, trades lacking the sort value sorting last in either direction, netPnl being post-fee vs grossPnl pre-fee, and the OAuth LuxAlgo sign-in prerequisite. This is exactly the extra context annotations cannot carry.

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 scoping and sort/order defaults are front-loaded, and every clause carries real information. It is dense and unbroken as a single block, and the long field enumeration at the start is slightly heavy, but with no output schema that enumeration does earn its place.

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

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

For an 11-param list tool with no output schema, the description covers return fields, sort/order defaults and tie-breaking, pagination protocol, filter semantics and auth requirements. Nothing 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 already 82%, but the description still adds meaning: sort names match response field names, order defaults to desc except symbol (asc), from/to are inclusive day keys in the journal timezone applied to the open day, open positions are always listed, and tag must match exactly one tag. These clarify ambiguous parameters rather than repeat 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?

Opens with a specific resource ('Trade summaries') and enumerates the exact fields returned, making the verb+resource unambiguous. It explicitly distinguishes itself from journal_get_trade (which has fills and note text) and from other journal list tools, so an agent can route correctly without opening a 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?

Provides concrete when-to-use recipes ('biggest winners this month = from/to + sort netPnl', 'longest holds = sort durationMs') and an explicit redirect ('journal_get_trade with the key has those'). Filter and sort semantics are stated as rules, not hints.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavioral context beyond them, including close-day bucketing in the journal timezone, open positions counting toward any window reaching today, what compare:true returns (a `previous` window), null-metric semantics, and the OAuth sign-in requirement. It stops short of covering pagination, output size limits, or latency/rate 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?

Front-loaded with the core purpose and efficient overall, with routing and prerequisites trailing correctly. The long parenthetical metric enumeration is dense but justified for a dashboard tool, since it tells the agent what it will receive without an output schema.

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

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

With five parameters, no output schema, and open-world annotations, the description supplies the missing pieces: return contents, window semantics, compare behavior, defaults, null handling, and auth. An agent has everything needed to call 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 coverage is 100%, so the baseline is 3. The description nonetheless adds meaning beyond the schema by explaining compare's effect ('adds `previous` — the equal-length window just before'), the default 30-day window, and the timezone/bucketing rule that governs how from/to and range are interpreted.

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 specific verb and resource ('the journal dashboard in one call for a window') and enumerates the metric families returned, so an agent knows exactly what this tool produces. It also explicitly names sibling routes (journal_breakdown, journal_list_trades), making it easy to distinguish from them.

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 directs the agent elsewhere when appropriate: 'Use journal_breakdown for where the P&L comes from and journal_list_trades for the trades themselves.' It also states the default window (last 30 days) and how to widen it (range: 'all' or explicit from/to), covering when and how to invoke.

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

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds real behavioral detail: newest-first single stream split by kind, the shape of each stream, keyset pagination via cursor/nextCursor, and the OAuth sign-in requirement. These are exactly the traits an agent needs and cannot infer from the annotations.

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

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

Front-loaded with the verb and resource, then filters, then pagination, then auth — a logical order with no filler. It is dense to the point of being one long run-on, but every clause carries information.

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

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

With no output schema, the description carries the return-shape burden and does so: it describes the stream split, the per-kind contents, and the pagination cursor contract. Auth and filtering caveats round it out, leaving nothing an agent needs to call 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 coverage is 86% so the baseline is already high, yet the description still adds meaning: `q` is case-insensitive, `to`/`from` form a day-key window, `symbol` applies only to trade notes, `accounts` scoping with unknown-id rejection, and the cursor must keep other arguments identical. It notably compensates for the `symbol` parameter, which has no schema description.

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 specific verb (search) plus the exact resource (the notes feed) and even resolves the resource into its two constituent streams, `notes` and `tradeNotes`. An agent can distinguish it from journal_list_trades or journal_get_day without opening a 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?

Gives concrete usage context: omit every filter to get the latest notes, symbol only applies to trade notes (day notes drop out), and it names journal_update_note/journal_update_trade as the follow-up consumers of the returned ids. It never explicitly names a sibling search/list tool as the alternative to use instead, so it falls short of a full when/when-not/alternative statement.

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

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

Annotations already declare non-read-only and idempotent behavior, but the description adds genuinely non-derivable context: the body is replaced whole (an easy-to-miss destructive semantic), OAuth sign-in with a LuxAlgo account is required, and the updated note is returned. It stops short of rate limits or error handling, but the key mutation caveat is disclosed.

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 replacement-destroys-text warning front-loaded and no filler. Each sentence carries distinct, load-bearing information (targeting, replacement semantics, sibling exclusion, auth).

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 three-parameter mutation tool with no output schema, the description covers targeting, replacement semantics, the sibling alternative, the auth prerequisite, and what is returned. Nothing an agent needs to invoke 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 description coverage is 100%, so noteId, body, and date are already documented, including that body is the full new text and date moves the note in the journal timezone. The description reinforces but does not extend this beyond the schema, so the baseline 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?

States a specific verb (replace/move) and resource (day note) plus the identifier needed to target it. It also explicitly distinguishes itself from journal_update_trade and implicitly from journal_write_note, so an agent can route correctly without opening sibling 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 the provenance of noteId (journal_get_day or journal_search_notes), names the excluded case (trade notes go to journal_update_trade), and instructs append users to read the current text first. When-to-use, when-not, and the alternative are all covered.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and openWorldHint=true. The description adds that fields are user-owned only, that fills/prices/P&L are immutable, and that OAuth with a LuxAlgo account is required. It doesn't disclose failure modes or what happens on partial updates beyond the null-clear rule.

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

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

Front-loaded with the verb, but the enumerations of field names and the parenthetical asides make it dense and run-on. Every sentence carries information, but the wall-of-prose format hurts 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 13-parameter mutation tool with no output schema, it covers the key semantic distinctions (replace vs. add/remove, null clears, auth required, derived fields untouched). It could note the return shape or idempotency behavior more explicitly, but it's nearly 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 85%, so the baseline is 3. The description adds the semantic distinction that tags/mistakes are wholesale replacements vs. the add/remove variants, and clarifies that stopLoss is the reference for realized R — meaning beyond the schema's terse field 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?

States a specific verb and resource ('Annotate a trade') and enumerates exactly which fields are user-owned vs. derived. It explicitly distinguishes itself from sibling tools like journal_update_note by scoping to trade-level fields.

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 addTags/removeTags/addMistakes/removeMistakes instead of tags/mistakes, warns against combining them, and points to journal_list_tags for existing vocabulary. This is actionable 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?

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false), and the description adds real value on top: it explains why it never overwrites (days hold any number of notes), states the return value, and discloses the OAuth/LuxAlgo sign-in requirement. Auth prerequisites are exactly the kind of context annotations don't carry.

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 tight sentences, front-loaded with the core action, followed by the non-overwrite guarantee and the routing alternatives. No filler or repetition; every clause carries information.

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

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

For a simple two-parameter write tool, the description covers the action, the non-destructive guarantee, the alternatives, the return value, and the auth requirement. With no output schema, noting that it returns the note with its id is a helpful touch.

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

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

Schema coverage is 100% and both parameters are already documented with format and timezone. The description repeats the YYYY-MM-DD/journal-timezone constraint but adds no syntax or edge-case detail beyond the schema, so the baseline 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?

States a specific verb and resource ('Add a new note to a trading day') and immediately distinguishes itself from journal_update_note and journal_update_trade's notes. An agent can tell what this does and what it doesn't do 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?

Explicitly names both alternatives and the condition that selects each: use journal_update_note to change an existing note, and journal_update_trade's notes for a trade-specific note. It also clarifies the day can be traded or not, removing ambiguity about applicability.

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 burden. It discloses the output format (markdown), the content scope, and the exact-slug requirement, which are genuinely useful behavioral details. It does not discuss potential errors, output length, or non-existent-slug behavior, but the key behavior is well 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?

Three sentences, each earning its place: what the tool returns, when to use it, and what prerequisite knowledge is needed. The most important information is front-loaded.

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

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

For a single-parameter, read-only lookup tool with no output schema, this description is complete. It explains the tool's purpose, content, usage trigger, and parameter provenance, leaving no critical gap 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?

The schema already fully documents the slug parameter, so the baseline is 3. The description adds meaningful semantics by emphasizing that the slug must be exact and should be obtained from search or list results, which helps agents avoid guessing or constructing invalid slugs.

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 action and resource: explaining a trading concept using the Library's full markdown write-up. It lists the content components (definition, formula, trader interpretation, indicator implementations), which clearly distinguishes it from sibling tools like library_get_indicator or library_get_source_code.

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 gives an explicit usage context: 'Use for any what is X / how does X work question.' It also routes the agent to library_search or library_list_concepts to obtain the required slug. It does not state explicit when-not-to-use conditions versus siblings, so it misses the top score.

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 burden of behavioral disclosure. It reveals the output type (markdown), the two main sections (overview and concept roster), and the informational/read-only nature of the call. It does not mention error cases or auth, but for a simple retrieval tool this is adequate.

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 what the tool returns, then gives a compact usage rule with concrete examples, all in minimal space.

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

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

Given a single enum-constrained parameter, no output schema, and no annotations, the description provides everything needed to invoke correctly: what is returned, in what format, and when to use it. The sibling routing is also covered.

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

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

Schema coverage is 100%, and the schema already documents the key parameter with an enum and an example value ('smc-ict'). The description adds usage context but no additional parameter-level meaning, 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 identifies the resource ('a family's hub page') and specifies the deliverable format ('as markdown') and content ('written overview ... plus its complete concept roster'). It distinguishes itself from library_get_concept by framing usage around a whole school of analysis, and from library_list_families by being a follow-up detail fetch.

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 use this tool: after library_list_families, or when the user asks about a broad area such as 'SMC' or 'Wyckoff'. It stops short of explicitly naming the alternative for single-concept queries, but the 'whole area' phrasing implies that boundary.

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

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

With no annotations provided, the description carries the full burden of explaining behavior. It discloses what the tool returns in useful detail, including indicator semantics, how to read it, related concepts, preview image, and source-code availability. It doesn't mention error handling or explicit read-only guarantees, but the 'Get' semantics and content listing give a solid behavioral picture.

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. The first sentence front-loads the tool's purpose and return contents, and the second provides a concrete usage trigger with an alternative. Every clause earns its place.

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

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

For a simple one-parameter lookup tool with no output schema, the description is complete: it explains what information the agent will receive, when to use the tool, and that source code is obtained via a sibling. 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?

The input schema already fully documents the single 'slug' parameter with format guidance and an example ('tri-star'), giving 100% schema coverage. The description adds no additional parameter-specific detail, but it doesn't need to because the schema carries the meaning. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as returning details for one specific indicator, listing concrete content types (what it does, how to read it, family, concept links, preview image, source availability). It also distinguishes itself from library_get_source_code by noting that the actual code is fetched by that sibling. An agent can confidently select this tool over its 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 says 'Use when the user asks about a specific indicator,' giving a clear trigger condition. It also points to library_get_source_code as the alternative when source code itself is requested, though it doesn't explicitly contrast with library_search or library_list_indicators for broader queries.

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. It discloses that the output is the full working source code, that it works on TradingView, and importantly that sources are long, implying a potentially large response. It does not mention error behavior or output formatting, but the core behavioral traits are covered.

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 deliver the resource, the key differentiating behavior, and explicit usage guidance with no wasted words. The most decision-relevant information appears first.

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

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

For a simple one-parameter read tool with no output schema, the description adequately describes the returned artifact: the full working source code. It also adds the important context that this is a TradingView indicator and that responses can be long. Slightly more detail about what happens for an invalid slug would push this higher, but the current content is sufficient 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?

The input schema already documents the only parameter, slug, with 100% coverage. The description adds only that the slug refers to a Library indicator, which is marginal. Per the schema-coverage baseline, a 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 identifies the specific verb+resource: retrieving the full working source code of a Library indicator. It also explicitly differentiates itself from the sibling library_get_indicator, so an agent can immediately tell which tool to select.

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 usage guidance: call it only when the user wants the code itself, and explains why it is separate from library_get_indicator because sources are long. 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that results are paginated and optionally filtered by one family, and implies a read-only browsing operation. It does not mention response format or rate limits, but the core behavior is 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?

The description is two sentences with no filler. The primary behavior is front-loaded, and the alternative-tool routing is stated in the same compact passage.

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 no required parameters, this description is complete: it states the scope, pagination, filtering, and relationship to sibling tools. The mention of finding slugs also signals what the output can be used for, which is sufficient given there is no output schema.

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

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

Schema coverage is 67%, and the description adds useful meaning to the family parameter by explaining it as a filter for a single family and by tying pagination to the page and page_size parameters. The schema already documents defaults, so the description complements rather than repeats it.

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

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

The description clearly states a specific action ('Browse every trading and technical-analysis concept in the Library') and defines the pagination and optional family scoping. It distinguishes this tool from library_search and library_get_concept by naming the exact use cases.

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 says to use this tool to enumerate a topic area or find slugs for library_get_concept, and directs users to prefer library_search for keyword lookup. This gives clear when-to-use and when-not-to-use guidance relative to key siblings.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It does so by stating the tool returns 17 families, includes concept counts and hub links, and serves as a top-level taxonomy. The word 'list' plus the described output makes the read-only nature clear enough for this simple tool.

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

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

The description is two short sentences with no filler. The core information—top-level taxonomy, 17 families, examples, and output content—is front-loaded, and the usage cue is appended efficiently.

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 zero-parameter, simple listing tool with no output schema, the description provides enough context: what the result represents, roughly how many items, what each item includes, and when to use it. Nothing critical is missing for an agent to select and invoke 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?

The tool has zero parameters, and schema description coverage is 100% by definition. The rubric sets a baseline of 4 for zero-parameter tools, and the description adds no unnecessary parameter claims while still explaining what the output contains.

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: listing concept families, and clearly characterizes them as the Library's top-level taxonomy with 17 items. This distinguishes it from sibling tools like library_list_concepts by emphasizing 'families' as the top-level grouping rather than individual concepts.

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 this is 'the natural first call for orientation,' giving clear guidance on when to invoke it. It does not explicitly mention alternatives or exclusions, but for a zero-parameter orientation tool this is sufficient context.

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

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

With no annotations, the description carries the transparency burden, and it does a good job: it discloses server-side sorting, default newest-first ordering, AND-combination for tags, and what a concept slug means. It does not explicitly mention pagination behavior or response shape, but the schema documents page/page_size defaults and there is no mutation or auth concern implied.

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 front-load the core behavior, list the filter dimensions, and close with concrete use cases and sibling routing. Every sentence earns its place with no repetition of schema details.

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 read-only browsing tool with 10 optional parameters, the description covers the main filter dimensions, sorting semantics, and the key sibling split. Minor gaps remain around supported platform values and return/pagination shape, but these are partly covered by the schema and 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 coverage is 80%, so the baseline is 3, and the description adds meaningful semantics: it explains the concept slug as 'implementations of one concept', sources tags from library_list_tags, and clarifies AND-combination. It also clarifies the default sort ordering, which informs the sort parameter.

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

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

The description names a specific action and resource: 'Browse the indicator catalog with filters and server-side sorting'. It explicitly contrasts itself with library_search ('for keyword discovery prefer library_search'), so an agent can distinguish this structured-browsing tool from its closest 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?

It gives explicit when-to-use examples ('latest indicators', 'everything in the volatility family', 'indicators implementing liquidity sweeps') and states the alternative for keyword-style queries. It also tells the agent that tag ids must come from library_list_tags, connecting it to the correct sibling tool.

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

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

With no annotations, the description carries the behavioral burden; it does so by clarifying that the result is ids for downstream filtering rather than a display of tag metadata. It does not explicitly state read-only/pagination behavior, but a zero-parameter vocabulary listing implies no mutation and no pagination.

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 front-loaded sentences and every phrase earns its place; the key output semantics come before the relationship/orthogonality context.

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 zero-parameter list tool, the description is complete: it defines the vocabulary, gives examples, states the output type, and names the consuming sibling. No missing context would prevent a correct call.

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?

There are no parameters, so the schema has nothing to document. The description adds value by explaining the return ids' meaning and destination, which is all an agent needs.

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 specific action (returns ids from the indicator tag vocabulary) and names the downstream consumer (library_list_indicators). The note that tags are orthogonal to the concept-family taxonomy separates it from sibling concept/family listers.

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 this tool is relevant: to obtain ids for the tags filter of library_list_indicators. The orthogonality statement acts as a when-not, steering agents away from using it for concept-family filtering.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals alias-aware matching with a concrete example ('stochastics' finds Stochastic Oscillator) and discloses the key output payload: slugs for the get tools and canonical URLs. It does not mention ordering or result count semantics, but those are minor for a search tool.

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

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

Three sentences each do distinct work: state the purpose, define the scope, and give usage plus downstream value. The description is front-loaded with the action and resource, and contains no filler or redundant restatement of the title or schema.

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 no-output-schema search tool, the description covers purpose, collection scope, alias behavior, and the usefulness of results (slugs and URLs). Parameter details are already complete in the schema. It omits exact result field structure and ranking, but this is not a blocker 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%, so the baseline is 3. The description adds meaningful semantic value for the required 'query' parameter: it accepts informal terms and aliases, which is not present in the schema. It does not add detail for type, limit, or family, but those are already fully described 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 the verb 'Search' against a clearly named resource, the LuxAlgo Library, and then quantifies the scope: 800+ concepts and 800+ indicators. It also differentiates itself from the library_get_* and library_list_* siblings by positioning search as the entry point that provides slugs for the get 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 says 'Start here whenever you have a name, informal term, or topic,' giving a concrete trigger condition. It also routes the agent onward by stating results carry slugs for the get tools, implying that exact-slug lookups belong to sibling tools. It does not name specific alternatives for exclusion, but the guidance 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?

Annotations already mark the tool as read-only and open-world. The description adds value beyond that by specifying that data is scoped to the signed-in user and requires OAuth authentication. It also discloses what categories of data will be returned, giving the agent a clear behavioral model. There is no contradiction with the annotations.

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

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

The description is compact and front-loaded: the first sentence defines the resource and contents, the second supplies use cases, and the third states the authentication requirement. Every sentence earns its place with no filler or repetition of schema information.

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

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

For a zero-parameter, read-only account lookup tool, the description is self-sufficient. It tells the agent what fields are available, when to call the tool, and what prerequisite must be satisfied. No output schema exists, but the listed categories give enough shape for the agent to use 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?

The tool has zero parameters and the schema coverage is trivially 100%, so the description has nothing to add for parameter invocation. The baseline of 4 for zero-parameter tools applies. The description instead appropriately focuses on the returned data and usage context.

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

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

The description clearly identifies the resource as the signed-in user's LuxAlgo account and enumerates its contents: plan tier, entitlements, and profile basics. It lacks an explicit retrieval verb like 'get' or 'list', but the use-case sentence clarifies that it exposes account information. It is clearly distinct from the sibling tools, none of which cover account data.

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

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

The description gives concrete trigger conditions: use this tool to tailor answers to what the user's plan allows, or when the user asks what plan they are on. It also states the OAuth prerequisite. It does not explicitly name alternatives or exclusion cases, but no sibling tool covers the same account resource, so the guidance is sufficient.

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 delivers extensively: refusal behavior, provenance disclosure via `inferredFields`, data-source attribution with env-var override (LUXALGO_APP_ORIGIN), authority caveats ('Firms change rules; each firm's own page is always authoritative'), and a precise units convention. It even distinguishes simulated rules from declared-only ones via `flagsNotSimulated`.

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

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

The description is front-loaded with the core purpose and organized via labeled sections (UNITS, DATA SOURCE & PROVENANCE, NOTE), which aids navigation in a very long text. However, it is exceptionally verbose, and the provenance/authoritative-page point is made roughly three times, so it does not fully meet 'every sentence earns its place.'

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

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

There is no output schema and no annotations, yet the description documents the full return shape (evaluation steps, daily-loss and max-loss semantics, fees, funded terms, flagsNotSimulated, sources, provenance), the units convention, the data origin, and edge/refusal cases. An agent can call this tool and interpret its result accurately without any additional lookups.

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 parameter descriptions already name the source listing (propfirms_list_simulatable) and give an example ('ftmo'). The main description reinforces the origin of the IDs but adds no new syntax, defaults, or formats for firmId/challengeId beyond what the schema provides, so baseline 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 opening sentence states a specific verb and resource: 'Fetch one directory challenge's complete ruleset (ChallengeSpec)'. The closing NOTE explicitly distinguishes it from propfirms_get and propfirms_search_challenges, removing any ambiguity with the closest 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 end of the description gives explicit routing: 'the directory listing with every captured field, plus live offers, is propfirms_get and propfirms_search_challenges.' It also explains the integration path with simulation tools ('copy it, change a rule, and re-simulate') and states a refusal condition ('Challenges whose loss rules cannot be established are refused as not simulatable').

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

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

With no annotations, the description carries full disclosure and does so thoroughly: EV ordering is input-dependent and not a ranking, unsimulated rules make numbers optimistic, consistency and payout gating ARE simulated, results are deterministic given seed, and outputs are distributions under assumptions, not promises.

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, with clear CAPITALIZED signposts (UNITS, DETERMINISM, ASSUMPTIONS) and front-loaded behavior/scope before caveats. Given the tool's complexity, this density is appropriate rather than bloated.

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 Monte Carlo tool with no output schema and no annotations, the description is complete: it names the output row fields, explains assumptions/disclaimer handling, gives units, determinism, input forms, caps, and routes to propfirms_simulate for deeper analysis. Nothing essential to correct invocation 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%, so the baseline is 3; the description adds value by establishing global unit conventions (percent units vs winRate as a fraction), explaining determinism/seed reporting, and warning that probabilities in results are fractions. It does not need to restate each field.

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 opening sentence names a specific verb and resource — 'Simulate the SAME trader across several challenges' — and clarifies the return shape (one row per challenge sorted by expected value). It also distinguishes itself from propfirms_simulate by deferring per-challenge distributions to that 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 clear context: compare the same trader across up to 12 challenges and states an explicit alternative ('For full per-challenge distributions run propfirms_simulate on the interesting rows'). It does not enumerate when-not conditions against every sibling, but the routing advice is unambiguous.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that uncaptured null fields are omitted and that challenges reference offers through offerIds, which are meaningful behavioral details beyond the name. It could mention read-only behavior more explicitly, but 'get' plus the dossier framing strongly implies a safe retrieval.

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 contributes: what the tool returns, how to find the slug, how nulls and offer references behave, and when to use a sibling tool. It is front-loaded with the core purpose and keeps auxiliary guidance compact.

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 there is no output schema and no annotations, the description does a strong job of setting expectations for a complex dossier response: it enumerates the major sections, explains omission behavior, clarifies cross-references between challenges and offers, and points to search and pass-rate tools. An agent has enough context to invoke the tool correctly and interpret the result.

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

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

Schema coverage is 100% and the single parameter is already described as a public firm slug. The description adds value by stating that the parameter is used by slug and pointing to propfirms_search for discovering valid slugs, which helps the agent supply a correct value.

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

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

The description clearly identifies the tool as retrieving one prop firm's full dossier by slug, with an explicit enumeration of the contents (profile, challenges, offers, overview). It distinguishes itself from sibling tools such as propfirms_search, propfirms_challenge_rules, and propfirms_pass_rates by focusing on the complete consolidated record.

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 direct usage guidance: use this to get a full dossier by slug, find slugs via propfirms_search, and use propfirms_pass_rates for simulated pass odds. This explicitly routes to alternative sibling tools, making the selection criteria 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?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses the live API source, keyless access, origin override, alphabetical ordering with no endorsement, provenance of rule semantics, inferred-field disclosure, and refusal to guess unverifiable loss rules. This is far beyond what structured fields would reveal.

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 information-dense and well structured, with the core purpose and call-first guidance front-loaded, followed by data source and alternatives. A minor deduction for slight repetition of the 'rather than guessed' caveat in multiple sentences.

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 list tool with no output schema and no annotations, the description is remarkably complete: it names the returned attributes, the provenance model, the notSimulatable bucket, the authoritative-source caveat, and the sibling tools for fuller directory data. An agent has everything needed to invoke it correctly and 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%: the one optional productType parameter is fully documented in the schema with enum values and a clear 'Omit to list every firm' instruction. The description adds no additional parameter-level meaning, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it lists prop firms and every simulatable challenge with concrete fields. It also explicitly distinguishes itself from the full-directory siblings (propfirms_search, propfirms_search_challenges, propfirms_search_offers), so an agent can tell exactly what this tool provides.

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

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

The description says 'Call this first to discover the firmId + challengeId pairs accepted by' the other propfirms tools, which is explicit when-to-use guidance. It also clarifies what it does NOT cover by pointing to sibling tools for the full directory, platforms, prices, payout terms, and 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, the description carries the full transparency burden and meets it well. It discloses cost (one full simulation per point, ~30 points at 10,000 paths takes ~10 seconds), common random numbers for smooth curves, byte-identical determinism with the same seed, the mandatory surfacing of assumptions flags/disclaimer, and the caveat that results are distributions, not promises.

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 the tool is complex (19 parameters, nested spec, no output schema) and each section earns its place: purpose, divergence insight, CRN, units, determinism, performance, assumptions. It is front-loaded with the core purpose and then layered with necessary operational detail. Slightly repetitive in warnings, but justified for a high-stakes optimization tool.

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, 19 parameters, nested spec object, and no output schema, the description is remarkably complete. It covers the two result optima, the diverges flag, assumptions flags/disclaimer, unit conventions for all risk and probability values, reproducibility requirements, and cost/performance trade-offs. An agent has enough context to select and invoke this tool correctly and interpret its headline results.

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

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

Schema coverage is 100% and each parameter already has rich descriptions, so the baseline is 3. The description adds value beyond the schema by explaining grid defaults (0.1 to 3 in steps of 0.1), grid units relative to riskMode, the winRate fraction exception, and performance implications of grid/path choices — going beyond what the schema alone 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 and resource: 'Sweep risk-per-trade over a grid, run the full journey simulation at every point, and report two optima separately'. It clearly distinguishes this from single-point simulation tools by noting 'riskValue is not a parameter here - the grid supplies it' and by naming the two output optima, bestByPassProbability and bestByEv.

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 contextual guidance: report both optima rather than one, use coarse grids or fewer paths for a first pass, refine around the optima, and re-run with different seeds to gauge Monte Carlo spread. It does not explicitly name sibling tools like propfirms_simulate as alternatives, but the 'Parametric trader only' and grid-supplies-risk statements imply the boundary. Clear context, but no direct when-not-to-use comparison.

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 fully carries the transparency burden. It discloses determinism, caching, cheap invocation, the seed and path count, the reference archetype assumptions, returned metrics including confidence intervals and provenance, and the caveat that inferred fields must be relayed. It also warns that the firm's page is authoritative and to check lastVerified.

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 and dense, but it front-loads the core purpose and scope before caveats and alternatives. Most of the detail is relevant to selecting, invoking, and interpreting the tool correctly, so the verbosity is justified even though a tighter structure could improve readability.

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 probabilistic tool with no output schema and no annotations, the description is unusually complete: it covers inputs, outputs, assumptions, caching, expected costs, limitations, and alternative tools. An agent should be able to call it correctly and interpret the results without additional information.

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

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

The schema already describes both parameters with 100% coverage, including omitted challengeId behavior. The description adds context about per-challenge and per-archetype computation but does not materially improve on the schema's parameter documentation, so the baseline 3 is appropriate.

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

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

The description names a specific operation: compute reference challenge pass rates per challenge and per archetype from the directory's encoded rules. It distinguishes itself from a ranking and from user-specific simulation tools, and the scope is clear enough to tell it apart from siblings like propfirms_simulate.

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 these are reference odds, not the user's personal odds, and directs to propfirms_simulate or propfirms_simulate_trades for personal statistics. It also names propfirms_get and propfirms_search_offers as authoritative sources for current rules and live offers, providing strong when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: a firm matches only when at least one challenge/offer matches all filters, uncaptured null fields are omitted, nested challenges reference offers via offerIds into the firm-level offers list, and the data returned is explicitly directory data rather than simulation outcomes.

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

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

The description is dense but well organized: core action and matching semantics first, then usage guidance, then result-shape caveats, then routing to outcome tools. Every sentence earns its place for a tool with 53 parameters and no annotations.

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 53 optional parameters and no output schema, the description covers matching semantics, null-omission behavior, nested payload behavior, the offerIds relationship, and explicit pointers to the dossier and simulation tools. An agent has enough information to select and call this tool correctly in the vast majority of cases.

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 schema already documents all 53 parameters. The description adds value by grouping parameters into firm, challenge, and offer filter categories and by explaining the critical 'at least one challenge/offer must match all filters' rule plus the include/offerIds wiring. It does not enumerate each parameter, but it does not need to given the rich 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 LuxAlgo's prop-firm catalog', and defines what prop firms are. It distinguishes itself from propfirms_get ('for one firm's full dossier prefer propfirms_get') and from outcome-oriented tools by stating it returns directory data, not outcomes.

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 when-to-use guidance: omit all filters to list all firms, use include to nest matching challenges/offers/overview, and explicitly routes full-dossier and pass-odds use cases to propfirms_get and propfirms_pass_rates/propfirms_simulate. It does not, however, contrast this tool with the closely related propfirms_search_challenges and propfirms_search_offers siblings, leaving some alternative-selection 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, the description carries the behavioral burden and does so well: it discloses that uncaptured null rule fields are omitted and never match filters, explains the deduplicated offers list behavior, and clarifies that this tool returns rules and terms, not outcomes. It could mention pagination or response shape more explicitly, but the disclosed edge cases are valuable.

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

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

The description is front-loaded with the core purpose and filter scope, then moves to parameter usage, edge-case behavior, and sibling routing. Every sentence earns its place, and the parenthetical filter list conveys breadth without bloating the text.

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 35-parameter search tool with no output schema and no annotations, the description is remarkably complete: it covers input modes, optional offers expansion, null-filtering behavior, and clearly states what the tool does not return while pointing to the correct follow-up tools. The lack of a full output shape description is mitigated by the rich schema and the explicit 'rules and terms, not outcomes' framing.

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 adds practical meaning beyond the schema for key parameters: propfirmId vs challengeId selection, include=['offers'] behavior, and null-field filter semantics. It does not need to restate all 35 parameters because the schema already documents them thoroughly.

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: search funded-account challenges across visible prop firms, with filtering by challenge rules and firm properties. It also explicitly differentiates itself from simulation tools by saying it returns rules/terms, not outcomes. This clearly separates it from sibling tools like propfirms_simulate and propfirms_validate_strategy.

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 gives explicit usage scenarios: pass propfirmId to list one firm's challenges, challengeId to fetch specific ones, and include=['offers'] to attach offers. It also names alternatives and when to use them: propfirms_simulate/propfirms_pass_rates for outcomes and propfirms_validate_strategy for screening one strategy across many challenges.

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 behavioral disclosure burden. It does a good job by stating the default live-only filter, explaining that challengeId includes firm-wide offers, and enumerating what each returned offer contains. It could go further by mentioning pagination or sort defaults, but the core behaviors an agent needs are disclosed.

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 no filler. The core purpose is front-loaded, key filtering behavior is explained, and the output contents are summarized compactly. Every sentence earns its place.

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

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

Given 17 parameters, no output schema, and no annotations, the description supplies a strong high-level model: what offers are, the default scope, how two key filters work, and what fields appear in results. The schema already documents individual parameters, so the description doesn't need to restate them. Minor gaps like pagination defaults and sorting behavior are left to the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond field names by clarifying that propfirmId narrows to one firm and that challengeId resolves offers applying to a challenge, including firm-wide offers. This helps agents combine filters correctly.

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 promotional offers (discounts and promo codes) across prop firms.' This clearly identifies the tool's domain and differentiates it from sibling tools like propfirms_search_challenges, which target challenges rather than 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 explains default behavior ('defaults to live offers only') and how to narrow results using propfirmId and challengeId, but it never explicitly names alternative tools or states when to choose this tool over propfirms_search or propfirms_search_challenges. Usage context is implied rather than spelled out.

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, and it delivers: byte-identical determinism given a seed, Monte Carlo spread guidance ('re-run with a few different seeds'), explicit lists of what is simulated (consistency, payout gating) vs only flagged (scaling plans, soft daily lockouts), engine versioning and approximation flags, live data provenance with an env-var origin override, and the refusal behavior for challenges whose loss rules cannot be established. This is unusually complete behavioral disclosure for a compute-only tool.

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

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

The description is long, but it is front-loaded (purpose and the questions it answers come first) and organized with uppercase section headers (SIMULATED RULES, UNITS, DETERMINISM, ASSUMPTIONS, DATA SOURCE & PROVENANCE), making it scannable. There is mild redundancy — the identification contract restates the spec parameter's schema description, and the trader-parameter sentence re-covers schema content — but for an 18-parameter tool with no output schema, the density is mostly earned rather than padded.

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 that there is no output schema, the description compensates thoroughly: it enumerates the full result shape (perAttempt, journey, funded, ev, assumptions, text summary), every unit convention, determinism and reproducibility requirements, assumption flags, and data provenance. For a tool this complex — 18 parameters with deeply nested spec/steps/funded objects and zero annotations — nothing 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%, so the baseline is 3, but the description adds genuine value beyond the schema: the currency-to-R conversion formula (avgWinR = avgWin / avgRisk, avgLossR = |avgLoss| / avgRisk), the 'one clean design used across all tools' framing, and the spec mutation workflow (fetch a directory entry, change one rule, re-simulate). The 'provide exactly one of the two forms; providing both or neither is an error' contract is also clearer than the schema's scattered 'mutually exclusive' notes.

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?

Opens with a specific verb+resource+method: 'Monte Carlo-simulate a trader with the given statistics through a prop-firm challenge and (by default) a funded horizon,' and immediately enumerates the exact questions it answers (per-attempt pass chance, ever-funded probability, expected attempts/cost, EV, which rule kills attempts). It also names its closest sibling, propfirms_simulate_trades, and explains the summary-stats-vs-raw-series distinction, so an agent can tell the two apart without opening either 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?

Provides an explicit when-not condition against the nearest alternative: 'If you have the user's raw trade series rather than summary stats, prefer propfirms_simulate_trades - it preserves streaks.' It also spells out the two identification modes (directory reference discovered via propfirms_list_simulatable vs inline spec matching propfirms_challenge_rules), the both-or-neither error contract, the network-vs-offline tradeoff, and how to compose with broker-statistics 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?

With zero annotations, the description carries the full burden and delivers extensively: it discloses the resampling methodology (geometric block lengths, default blockMeanLength 5), that newsFilter runs the simulation TWICE and returns the news-avoided scenario, that portfolio overlap is ALWAYS analyzed with an audit-risk verdict warning, that consistency and payout rules are SIMULATED (with named flags), determinism guarantees, and the mandatory surface-the-assumptions-flags requirement. Even a removed pre-1.0 flag id is disclosed.

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 deliberately structured with scannable section headers (TIMESTAMPED LOGS, NEWS WINDOWS, PORTFOLIO MODE, SIMULATED RULES, UNITS, DETERMINISM, ASSUMPTIONS) and is front-loaded with the core purpose and differentiator. Some content repeats what the exhaustive schema already states (e.g., input format details), and the statistical rationale paragraph is slightly verbose for an agent audience, but each section earns its place given the tool's genuine 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 20-parameter tool with a deeply nested spec, no output schema, and no annotations, this description is remarkably complete: it covers input selection and mutual exclusivity, minimum data requirements, return shape (references the same SimResult as propfirms_simulate plus named result fields like structuredContent.newsComparison and portfolioOverlap), error behavior (ambiguous imports refused with diagnostics, skipped rows reported as warnings), and mandatory user-relay obligations (calendar caveat verbatim, assumption flags and disclaimer).

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, and the description adds real value on top: it interprets R-multiples with worked examples, explains when tradesPerDay is required vs. derived, gives tuning guidance for blockMeanLength (1 = i.i.d. destroys streaks; raise toward 10 for long regimes), and its UNITS section clarifies the winRate fraction exception and that results are fractions. It supplements rather than merely restates 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 opening sentence states a specific verb, resource, and 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 actively differentiates from propfirms_simulate by naming the alternative mechanism (win-rate model vs. actual trade series), so an agent can tell them apart immediately from the first line.

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?

Explicit routing guidance is given: 'Use propfirms_simulate when only summary stats are available; use this whenever the actual trades are.' It also states hard input constraints (exactly one of four input forms, at least 10 trades, 100+ recommended), which inputs require tradesPerDay, which are mutually exclusive, and it even provides conversion guidance for composing with broker-statistics tools (avgWinR = avgWin / avgRisk).

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 exceeds it: it discloses that this is a screen, not a ranking/endorsement; that flagged rules make numbers optimistic; that results are deterministic per seed; that one full simulation runs per challenge; and that fees use listed prices without live discounts. It also warns about risk-sizing sensitivity and the need to state the bar when relaying results.

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 sentence earns its place given the tool's complexity and 24 parameters. It front-loads the core purpose and bar concept, then packs behavioral caveats, parameter semantics, and sibling routing 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?

For a complex 24-parameter tool with no output schema and no annotations, the description is remarkably complete: it specifies the return fields per challenge, the simulation methodology and defaults, refusal behavior, fee assumptions, reproducibility, and related tools. Nothing essential for correct invocation 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%, so the baseline is 3, and the description adds value on top: it explains which strategy inputs are alternatives (rSeries/rSeriesText vs winRate/avgWinR), why rSeries is preferred (streak preservation), and emphasizes that riskValue is percent units not a fraction. It also frames minPassPerAttempt as the caller-stated bar and clarifies that funded-horizon EV scales with fundedHorizonDays.

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: 'simulate the given strategy through every simulatable challenge in the live directory' and answers a direct caller question ('which challenges would MY strategy actually pass?'). It clearly distinguishes itself from sibling tools like propfirms_simulate and propfirms_optimal_risk by framing this as an all-challenges screen with an explicit bar.

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 context: use it to screen across challenges, and use propfirms_optimal_risk to sweep one challenge afterwards. It also states exclusions and limits (challenges whose rules cannot be encoded honestly are excluded and counted, scopes above 40 challenges are refused) and points to sibling tools for directory data, so an agent can 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?

No annotations are provided, so the description carries the full burden; it discloses both list-mode returns (row count, freshness, years, searchable flag) and detail-mode returns (field roster, filterable paths, caveats, per-year coverage, source health, dump URLs). It implies read-only operation but does not discuss output structure, rate limits, or auth; for a catalog/list tool this is a minor gap.

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

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

The description is a single dense paragraph with the core purpose front-loaded and no filler. The dataset enumeration partly overlaps with the schema enum, but it expands terse enum labels into understandable categories, so it earns its place; still, it could be tightened slightly.

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

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

With one optional enum parameter, no annotations, and no output schema, the description fully covers what the agent needs: what the tool lists, what each mode returns, and how to use it as a prerequisite for trackers_query. No critical invocation detail 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?

The schema already fully covers the enum and says 'omit to list all', so the baseline is 3. The description adds meaning beyond the schema by explaining that passing dataset yields the full field roster, filterable paths, caveats, per-year coverage, source health, and dump URLs, and by tying this to trackers_query filter composition.

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 the tool as the 'Market Trackers catalog' and states exactly what it returns (row count, freshness, year coverage, ticker-searchability), making the listing purpose unmistakable. It differentiates from query siblings by positioning itself as the catalog to consult before composing trackers_query filters. This is more than just the title.

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 gives explicit context: call without dataset to list all and pass a dataset for the detailed view, and instructs the agent to read it before composing trackers_query filters. It only names trackers_query as an alternative and does not contrast with trackers_latest or trackers_ticker, so it lacks full exclusion coverage.

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 burden. It discloses that only the latest daily publish is returned rather than full history, that selection can be narrowed by ticker/text, and that patents are unsupported. It does not explicitly state output shape or read-only behavior, but the wording makes the read-only nature clear.

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 no filler: the core scoping fact is front-loaded, followed by concrete examples and an explicit exclusion/alternative. Every sentence earns its place.

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

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

For a read-only list tool with a fully documented input schema, the description covers what the tool returns, when to use it, and when not to use it. It leaves output shape unspecified, but with no output schema and rich parameter documentation this is a modest gap rather than a critical one.

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 every parameter is already documented. The description adds a small amount of guidance by highlighting ticker/text narrowing, but otherwise does not meaningfully extend the schema's 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 precisely defines what the tool returns: the newest ingestion day's rows from latest.json for one dataset, optionally filtered by ticker or text. It distinguishes itself from sibling trackers_query by explicitly naming where that alternative applies (patents).

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