TradingView-MCP

by tedorigawa001

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.10
Disambiguation2/5
The set contains multiple near-synonymous clusters—run_*_study/audit tools, strategy backtest/regime variants, and template/context/outcome trios—so an agent can easily select the wrong specialized variant. Detailed descriptions help, but the sheer number of overlapping research and backtest tools creates real ambiguity.
Naming Consistency4/5
Almost all tools follow a snake_case verb_noun pattern (get_, set_, run_, compute_, validate_), and categories use predictable prefixes. Minor deviations like carry_panel_preflight and get_oanda_flow_collection_readiness are more noun-heavy, but no naming convention is mixed within a cluster.
Tool Count1/5
105 tools is far beyond the well-scoped range and well over the 50-tool extreme threshold. Even for a broad TradingView automation server, this number creates excessive selection overhead and makes the toolkit feel overgrown.
Completeness4/5
The surface is remarkably comprehensive: chart control, Pine script lifecycle, backtesting, research audit, journaling, alerts, market data, and risk sizing are all covered. Obvious gaps such as alert update/delete, watchlist modification, and direct script deletion exist, but core workflows have few dead ends.
Average 4.2/5 across 105 of 105 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 232 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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 discloses several meaningful non-obvious behaviors: the tool compares branches against non-event bars in a matched regime, verifies source/placement/inputs/symbol/timeframe, never ranks or adopts a branch, and explicitly excludes native VP, order flow, and assumed fills. It does not disclose potential side effects such as whether results are persisted to a journal or ledger, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense four-sentence block of roughly 90 words; the main verb and resource are front-loaded in the first sentence, but the heavy jargon makes it difficult to parse quickly. Each sentence adds real information, so it is not padded, yet the lack of segmentation or plain-language summary reduces readability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool: 10 parameters, no output schema, no annotations, and a multi-variant methodology with strict evidence-handling rules. The description covers the methodology, fixed parameters, exclusions, and the combine-prohibition, but omits the return/result format, persistence or side effects, prerequisites, and any meaning for the majority of parameters. An agent would need substantial probing to invoke this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10% (the count parameter), so the description needed to compensate but only loosely does. It clarifies that the 60-minute variant supports up to 15,000 rows (relevant to count) and implies expected_symbol/expected_timeframe are verified, but the other nine parameters (folds, signal_from, signal_to, pine_id, study_id, chart_index, event_limit) receive no meaning in either the schema or the description. The methodology terms (70% value area, four branches, 20 bps target) are not mapped to any concrete parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run') and an unusually precise resource: the frozen descriptive #61b reaction-study variant on CME exchange-volume chart bars with the audited Bushido Volume Profile Context proxy. It further scopes the tool by listing fixed methodology parameters (24 rows, 70% value area, four branches, horizons 1/2/4/8, 20 bps target) and exclusions, which differentiates it from the similar-sounding sibling run_volume_profile_poc_reversion_study. The heavy domain jargon slightly obscures the plain-language purpose, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives; no sibling tool is named and no selection conditions are stated. The warning that the 240-minute and 60-minute variants must not be combined is a methodological constraint, not usage routing. This is the weakest dimension for a tool in a large sibling set of research/audit studies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by disclosing the null mechanism (circular-shift empirical null after v3 default scaling), reproducibility through a configuration hash, and non-effects (does not read/change TradingView, does not establish profitability). It stops short of failure modes or resource costs, but covers the most decision-relevant behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with purpose, and each sentence adds a distinct behavioral fact: null method, scaling, reproducibility, and side-effect absence. It is not bloated, though the third sentence packs several technical clauses that could be split for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
High parameter count, near-zero schema description coverage, no annotations, and no output schema place a heavy burden on the description, which it only partially meets. It provides methodology and side-effect context, but not enough for correct invocation of required parameters or interpretation of the returned result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 8%, so the description must carry parameter semantics; it explains null variants and default scaling but never maps concepts to specific parameters like model, folds, replications, or nominal_alpha. Only return_standardization has any schema-level description, leaving required inputs largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Calibrate') and a specific resource ('frozen lead-lag candidate rule') against paired nulls, making the tool's core function clear. It is distinguishable from sibling falsification audits because it targets lead-lag rules specifically, though terms like 'frozen' and 'candidate rule' rely on domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named even though sibling falsification audits exist. The factor/independent variant explanation hints at use cases but does not state prerequisites or how to choose among the 13 parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool uses exact-time common bars, excludes overlapping state windows, and never produces a candidate or trade instruction, which meaningfully signals its non-execution and non-trade nature. It does not mention possible side effects or output format, but the core behavioral constraints 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and every clause earns its place: the outcome horizons, the bar-alignment constraint, the overlap exclusion, and the no-trade caveat. Information is front-loaded and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the high-level behavior but leaves the 8-parameter input surface completely undocumented and provides no return-value or output-shape information. For a research tool of this complexity, especially with no output schema and no annotations, an agent would not have enough context to invoke it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 8 parameters, including the 4 required ones: target_chart_index, auxiliary_chart_index, expected_target_symbol, and expected_timeframe. The tool name and description imply cross-asset context, but an agent cannot determine parameter meaning or valid combinations from this description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action, 'measure', and a specific resource, 'descriptive 15/30/60/120-minute outcomes for frozen observed cross-asset shock states.' It also differentiates itself from trading/execution tools by saying it 'never produces a candidate or trade instruction,' though it does not explicitly name an alternative sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when frozen cross-asset shock states have been identified and descriptive outcome measurement is needed. It provides no explicit when-to-use or when-not-to-use guidance and does not reference alternative tools such as classify_cross_asset_shocks or preflight_cross_asset_shock, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explains the methodology: local first-seen policy-rate versions, pair fixed effects, moving-block bootstrap refits, and the not_evaluable condition until 60 complete clusters exist. This is substantive transparency, though it omits side effects and return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly written sentences with no filler. The opening sentence front-loads the main action, the second explains the key methodology, and the third states a critical return condition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives good methodological context but is incomplete for invoking the tool correctly: there is no output schema, no parameter semantics, and no return-value description beyond the not_evaluable condition. An agent still cannot confidently know what a successful response contains or how to set the parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters: as_of, count, confirm, or chart_index. An agent cannot determine which parameter controls what, why chart_index is required, or what confirm does, leaving the invocation semantics almost entirely underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run the frozen carry_core_primary_v1 specification on the five-pair core FX panel.' This clearly identifies what the tool does and distinguishes it from the many sibling research/audit tools, which target different panels or specifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, and it names no sibling tools or exclusions. It implies that the test is only meaningful once sufficient history exists, but it does not tell an agent when to choose this over readiness checks or preflight tools like get_carry_core_primary_readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose a meaningful non-obvious behavior: only target_before_stop is positive, stop_before_target is negative, and ambiguous/incomplete/cancelled/neutral/unevaluated entries are exclusions. It does not cover side effects, permissions, or output format, but the most important behavioral rule is stated clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action and scope are front-loaded, and the essential labeling/exclusion policy immediately follows. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters, no output schema, and no annotations, so the description alone must enable correct invocation and interpretation. It explains labeling and exclusions but omits parameter meanings, the shape of the calibration result, and when to choose this over performance/audit siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions bias, bins, or symbol. The schema only provides types, an enum, and a pattern; the agent must guess what 'bias' filters, how 'bins' affects calibration, and what 'symbol' selects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Calculate') and a specific resource ('confidence calibration from the local analysis journal'), and it adds the positive/negative labeling and exclusion policy. However, it does not explicitly differentiate from siblings like get_analysis_performance or the audit/study tools, so the distinction must be inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when you need confidence calibration from the local analysis journal. But there is no explicit when-not-to-use guidance, no prerequisite mention, and no comparison against the many research/audit sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently describes what the tool computes and, importantly, what it does not observe or claim. This gives an agent a clear mental model of the tool's limitations and output nature, though it stops short of describing the exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded, and the second sentence provides necessary caveats and methodological detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides useful context about methodology and limitations, but it omits practical invocation details and parameter meanings. It is adequate for an expert who already knows the domain, but less complete for an agent that must decide when to call it versus sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate, but it only indirectly addresses expected_timeframe and expected_symbol by mentioning 'daily FX chart'. It does not explain count or chart_index, leaving two of four parameters underspecified from a semantic standpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Describe') and names a clear resource: an exploratory COT crowded-position unwind proxy on a bound daily FX chart. It adds the proxy's composition (positioning percentiles combined with a 20-day price break), which clarifies the tool's focus. It does not explicitly differentiate from siblings like get_cot_crowding_unwind_overlay_template, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description signals when this is appropriate by labeling it 'exploratory' and explicitly stating it never claims to observe orders, stops, institutions, or execution flow, which warns against using it as an actual flow or order tool. However, it does not name alternatives or give explicit when-to-use / when-not-to-use conditions relative to sibling tools such as get_futures_flow_context or get_positioning_context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 does this well by specifying that it uses only first-seen, available-at policy rates, counts non-overlapping business-day anchors, and returns 'not_evaluable' rather than fabricating history. This covers data-source integrity, counting methodology, and missing-data behavior, though it does not describe return values on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded, and the second sentence adds high-value behavioral detail about data sourcing and fallback behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nine parameters, nested objects, and no output schema or annotations. The description explains the core preflight intent but is missing crucial context: what a successful evaluation returns, what 'not_evaluable' looks like in practice, how parameters like fixed_regime or minimum_observations affect the check, and how this relates to sibling tools like measure_carry_panel_dependence. The description is too thin for an agent to confidently construct a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is responsible for explaining parameter semantics. It does not mention any of the nine parameters by name and does not clarify the meaning of pairs, from, to, fixed_regime, price_evidence, minimum_observations, or horizon_business_days. Some domain hints like 'business-day anchors' relate to horizon_business_days, but overall the description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check whether') and resource ('policy-rate evidence can support a fixed carry panel'). It differentiates itself from sibling preflight tools by focusing on locally first-seen policy rates and the fixed carry panel context, though it does not explicitly name any sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before any return study runs' gives explicit timing for when this tool should be used, establishing it as a preflight gate. It does not provide explicit when-not-to-use guidance or alternative tool names, but the intended usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It transparently states that the tool injects a synthetic effect, measures detection rates, and that output is sensitivity evidence rather than alpha. It does not mention side effects or persistency, but the core synthetic experimental 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences and front-loads the core measurement action, with the important 'not market alpha' caveat placed second. However, the dense jargon around 'frozen feature-outcome candidate gate' and 'injected after one body-direction bucket' harms readability, though every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 26 parameters, no output schema, no annotations, and zero schema description coverage, the description is far from complete. It establishes purpose but omits required parameter guidance, output expectations, operational constraints, and any invocation prerequisites, making it insufficient for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level guidance. Terms like 'predeclared signed next-bar effect' and 'body-direction bucket' only weakly map to effect_bps, horizons, or target_bucket, leaving the agent unable to construct a valid call for a 26-parameter tool with 8 required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and target: 'Measure how often the frozen feature-outcome candidate gate detects a predeclared signed next-bar effect injected after one body-direction bucket.' It also clarifies this is synthetic sensitivity evidence, not market alpha, which distinguishes it from sibling falsification audits and outcome studies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for synthetic sensitivity testing and warns against treating results as market alpha, but it never names sibling alternatives or gives explicit criteria for when to choose this audit over run_feature_outcome_falsification_audit or compute_feature_outcome_relationships. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does add meaningful disclosure: 'the target pane is read back and failures are rolled back,' revealing verification and transactional-rollback behavior. This partially compensates for the missing annotation layer. However, it omits other behavioral traits an agent would want, such as persistence effects, what a 'failure' condition looks like, and any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then examples, then the multi-chart qualifier. Every sentence earns its place and there is no redundant boilerplate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter setter, the description covers the action, valid values, multi-chart behavior, and verification semantics. But with no output schema or annotations, it leaves gaps: the return/confirmation format after the read-back is unspecified, error behavior beyond rollback is vague, and there is no statement about whether a chart/pane must already exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 genuine value beyond the schema by giving concrete resolution examples ('1', '5', '15', '60', '240' (minutes), '1D', '1W', '1M'), which clarifies the units and format that a bare 'Timeframe/resolution string' does not. The chart_index explanation mostly mirrors the schema, but the resolution semantics push this above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Change one TradingView chart's timeframe.' It also clarifies scope with 'one' (single-pane) and provides concrete valid values. It does not explicitly name a sibling it is not (e.g., set_symbol), so it doesn't fully earn a 5, but the action and target are unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit: an agent can infer this tool is for changing a chart's timeframe, and the chart_index explanation gives multi-chart layout guidance. However, there is no when-not-to-use guidance or mention of alternatives such as set_symbol, and no prerequisite stated (e.g., a chart must be open).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait: 'it does not persist either capture,' which reassures the agent about side effects. However, it does not mention whether the tool is read-only, how epsilon affects the comparison, or what happens if the two captures are structurally mismatched. The disclosure is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. It opens with the core action and context, then immediately states the return value and a critical side-effect. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is complex, with nested objects and three parameters, and there is no output schema to describe the return format. The description does not explain what 'closed-bar captures' means, what 'changed plot values' look like, or the role of epsilon. For an agent deciding whether and how to call this tool, significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's silence. It loosely explains 'before' and 'after' as 'two closed-bar captures' but gives no detail about the required structure (study_id, symbol, resolution, bars). Most importantly, the 'epsilon' parameter is never mentioned, leaving a key input undocumented. The description fails to convey the meaning or usage of one of the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Compare'), the exact resource ('two closed-bar captures of the same indicator'), and the situational context ('after a chart reload/restart'). It also differentiates itself by stating what it returns ('changed plot values') and what it does not do ('does not persist either capture'). This distinguishes it from sibling comparison tools like compare_research_evidence and compare_strategy_experiments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after a chart reload/restart' provides a clear context for when this tool should be used. However, it does not explicitly mention alternatives or state when not to use it, such as when comparing live values or arbitrary datasets. The absence of explicit exclusions keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that the result is an assumption-based estimate rather than broker data, which is a meaningful behavioral trait. It does not disclose defaults for optional parameters like commission_per_unit or slippage_pips_per_side, nor does it explain units or validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences, with the primary action first and the caveat second. It contains no filler or repetition of schema details, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is acceptable for a relatively simple calculator but has clear gaps: there is no output schema and the description does not state return format, units, or handling of omitted optional parameters. It also does not connect to sibling tools or typical workflow context, leaving an agent to infer how the result should be consumed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It links bid/ask to spread, slippage_pips_per_side to slippage, and commission_per_unit to commission, which adds semantic grouping beyond the raw schema. However, it does not explain the required symbol and quantity parameters or how optional parameters behave when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Compute explicit round-trip spread, slippage, and commission cost for a supported instrument.' It clearly identifies the tool's purpose and distinguishes it from broker execution data, so an agent can understand its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The caveat 'This is an assumption model, not broker execution data' gives useful context for when the result should not be treated as execution evidence. However, it does not explicitly state when to use this tool instead of related siblings such as compute_position_size or get_quotes, so usage guidance remains implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add value: it explicitly states the operation is read-only, explains the temporal semantics ('first-seen ... available by the requested time'), and reveals a non-obvious behavior (TradingView decision-date bars are never treated as intraday publication timestamps). It lacks details on auth, rate limits, or side effects, but for a read-only context tool this is meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core behavior front-loaded and the differentiating exclusion in the second sentence. Every clause earns its place, and there is no repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for an agent to fully invoke and interpret the tool: it does not describe the shape of the returned 'policy-rate versions', and no output schema exists to fill that gap. It also leaves the un-documented currencies parameter unexplained, so default behavior and filtering semantics remain unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: as_of is documented, but currencies has no description. The tool description adds no parameter-specific meaning; it never explains how currencies filters results or what happens when that array is omitted, leaving the agent to infer semantics from the enum values alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a well-qualified resource ('locally first-seen policy-rate versions that were available by the requested time'). It also draws a clear boundary with 'this is macro context, not a trading trigger,' which helps distinguish the tool from trading-signal siblings even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'not a trading trigger' line implies a context for use and warns against a likely misuse, but the description never names alternatives or gives explicit conditions for when to choose this tool over closely related siblings like get_exploratory_policy_rate_history. Usage guidance is mostly implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose append-only behavior, data exclusions (no OHLC/source code), and no chart side effects. But it omits auth requirements, duplicate handling, and whether the operation returns a confirmation, leaving significant behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the core purpose, and the second adds important scoping exclusions. Excellent structure for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with nested objects, no output schema, and no annotations, the description gives a solid overview but lacks guidance on how to map an experiment's result to fields, when to use it relative to run_strategy_experiment, and what the expected return/confirmation is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It groups key parameters into meaningful categories (hypothesis, population, Pine versions, full-ledger ids, metrics, guardrails, decision) which is helpful, but it leaves experiment_id, symbol, timeframe, methodology_version, and parent_experiment_id unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Append'), resource ('research journal'), and precise scope ('one exact strategy experiment result'). It enumerates the bound entities and explicitly excludes OHLC/source code/chart interactions, which clearly separates it from siblings that run or compare experiments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The journal-append context implies this is the persistence step after running a strategy experiment, and the 'never touches a chart' clause acts as an exclusion. However, no alternative tools are named and there is no explicit when-to-use or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose important traits: the entry is immutable, the journal is append-only, and the journal is local. However, it omits duplicate-ID behavior, error handling, required permissions, and what the function returns, leaving meaningful ambiguity for a mutation/registration operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the core purpose and behavioral constraints front-loaded and the alternative usage placed second. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with five required parameters, nested objects, no output schema, and no annotations. The description covers the high-level purpose but leaves out return values, duplicate handling, validation behavior, and most parameter semantics, so an agent still faces significant ambiguity before invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, yet the description adds little parameter-level meaning beyond referring to an 'outcome contract,' which loosely maps to evaluation_contract. It does not explain hypothesis_id, title, thesis, audit_definition, or how the evaluation_contract fields relate to the hypothesis, so the description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Register'), a specific resource ('immutable event-study or observational feature-study hypothesis and its outcome contract'), and a specific destination ('local append-only research journal'). It also distinguishes itself from siblings like register_strategy_hypothesis and the run_* study tools by clearly naming the domain of hypotheses it handles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete routing guidance by telling users to use the optional journal field of run_market_event_study or compute_feature_outcome_relationships for recording evidence instead of copying results manually. It does not explicitly say when not to use this tool or mention protocol validation, but the intended workflow is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does reveal meaningful behavior: expected_symbol and expected_timeframe are checked immediately before the write, confirm=true is required, and Replay Trading orders/autoplay are never used. However, it leaves ambiguity around what 'Preview' means, whether an existing replay is replaced, and what side effects or return values occur after the write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. The primary purpose is front-loaded, and the key constraints are stated clearly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description needs to cover more context. It covers the core action and critical guardrails, but it lacks guidance on follow-up tools, expected return behavior, and what happens to any existing replay session. It is adequate for a simple start action but still leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25%, so the description must compensate. It adds semantic meaning for expected_symbol and expected_timeframe by saying they are checked immediately before the write, and it clarifies that confirm must be true. However, start_at is only implied by 'one historical instant' and is not explicitly linked to the parameter, and no additional parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Preview or start'), a specific resource ('TradingView Bar Replay on the active chart'), and a precise scope ('at one historical instant'), distinguishing this from sibling tools like step_chart_replay, stop_chart_replay, and get_replay_status. It is not a tautology and immediately communicates what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: it is for entering replay at one historical instant, confirm=true is required, and Replay Trading orders/autoplay are never used. However, it does not explicitly state when to use this tool versus alternatives such as step_chart_replay, stop_chart_replay, or get_replay_status, or mention prerequisites like having an active chart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states the tool is non-mutating with respect to TradingView, Pine, alerts, orders, and journals, and it discloses the key output types. It does not discuss failure modes, data staleness, or authentication needs, but for a validation-only tool the most important behavioral trait is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The purpose is front-loaded, the side-effect guarantee is stated immediately, and the outputs are summarized efficiently. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 23 parameters, no parameter descriptions, no output schema, and no annotations, yet the description provides only a high-level overview. An agent would not know what a valid trade plan payload looks like, what quality issues are covered, how the cost adjustment is calculated, or what the exact response structure is. Given this complexity, the description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 23 parameters, and the description provides no parameter-level guidance. It does not explain how to construct a valid 'proposed trade plan', what fields are required, how targets map to risk/reward, or what 'cost-adjusted' means. The description adds essentially no meaning beyond what the schema's raw types and constraints already show.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource combination: 'Validate a proposed trade plan'. It clearly states what the tool does (validation) and what it returns (quality issues and cost-adjusted Target 1 risk/reward), and it distinguishes itself from execution/alert/order-producing siblings by explicitly saying it changes nothing in TradingView, Pine, alerts, orders, or journals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when a proposed trade plan needs validation before any execution or side effects. It does not explicitly name alternatives or exclusion conditions, but the 'without changing...' phrasing effectively implies when not to use it. Absence of explicit sibling routing keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses meaningful behavior: it temporarily borrows an auxiliary chart, restores it after each read, applies a frozen same-UTC-slot baseline contract, and restricts output to observed state. This is substantial transparency about side effects and scope, though it does not explain what the returned classified state rows contain or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by key behavioral caveats. Every sentence contributes value, though the phrase 'frozen same-UTC-slot baseline contract' is jargon-heavy and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, eight parameters, and low schema coverage, the description is not complete enough for correct invocation. It covers scope and chart side effects but leaves parameter semantics, output structure, and the meaning of 'classified state rows' undefined, so an agent cannot confidently determine all required inputs and expected result formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, leaving important parameters like target_chart_index, auxiliary_chart_index, count, and minimum_classified_states without meaningful schema descriptions. The tool description adds some context by explaining that the auxiliary chart is used for DXY, US10Y, and XAUUSD, and that the target is EURUSD or USDJPY, but it does not compensate for the majority of undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Classify observed EURUSD or USDJPY shocks') with a precise resource scope and method ('after exact-time cross-asset collection'). It also differentiates from siblings by explicitly saying it 'reports observed state only, never a forward outcome, candidate, order-flow claim, or trading instruction', which distinguishes it from related tools like evaluate_cross_asset_shock_outcomes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates the intended context: use after exact-time cross-asset collection and for observed-state classification rather than forward-looking evaluation. However, it does not name sibling tools or explicitly state when to use alternatives like preflight_cross_asset_shock or evaluate_cross_asset_shock_outcomes, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add useful context: data is scoped to the loaded chart bars and time is in unix seconds. However, it does not mention read-only safety, response ordering, error behavior, or that chart_index refers to the active chart by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Both the 'currently loaded' scope qualifier and the unix-seconds note earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two optional parameters and full schema coverage, the description plus schema is mostly complete. It lists all returned fields and the time format; only response ordering and array shape are left implicit, which is a minor gap given the straightforward nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with count and chart_index fully documented including defaults and bounds. The description itself adds no parameter-specific meaning beyond clarifying the output time unit, which is not a parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('OHLCV candle data'), and the scope ('currently loaded in a TradingView chart'). The parenthetical field list removes ambiguity and distinguishes it from quote or indicator retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently loaded in a TradingView chart' implies the intended use case, distinguishing it from broader market data tools. However, it does not explicitly name sibling alternatives like get_quotes or get_indicator_values, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that this is an external TradingView scanner API call and gives relevant domain conventions. However, it does not explicitly state whether the operation is read-only, whether rate limits or auth are involved, or what happens on API failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The market list and scanner-field examples are useful, though the market list partially duplicates the schema's example values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the well-described schema and the tool's relatively simple screening purpose, the contextual picture is mostly complete. The main gap is the lack of explicit output-shape information, but the schema's 'columns' parameter and the phrase 'symbols matching field filters' imply the return format adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 real value by explaining that filter fields use scanner names like 'RSI', 'close', 'volume', 'market_cap_basic', and 'Recommend.All', and by giving an example filter ('RSI < 30') that maps directly to the schema's operation enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Screen a market for symbols matching field filters') and the means ('TradingView's scanner API'), so an agent knows what the tool does. It does not explicitly differentiate from sibling watchlist/quote/snapshot tools, but the screening function is immediately recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use context: scanner-style market screening with filter examples and supported market names. It does not mention alternatives or when-not-to-use cases, but the examples and phrasing make the intended usage reasonably explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses a non-obvious behavior (missing bars are never forward-filled) and a scope limitation (closed bars must share exact UTC timestamps). It also frames the output as descriptive, which helps set expectations. It does not mention side effects or return format, but the core computational behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, data alignment requirement, and interpretive caveat. The most important constraint is front-loaded immediately after the purpose, and there is no filler or redundant schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 5 required, no output schema, no annotations), this description is not sufficient for an agent to invoke it correctly. It omits what the output looks like, how thresholds map to regimes, and how the required symbol/timeframe fields should be populated. The description gives a solid high-level orientation but lacks critical operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only references two charts and timestamp alignment. It does not explain count, window, strong_threshold, neutral_threshold, or the expected symbol/timeframe parameters. An agent is left to guess how rolling window and thresholds affect the classification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Classify') and a precise resource ('rolling return correlation between two explicitly bound layout charts'), making the tool's function immediately clear. It also introduces a defining constraint (exact UTC timestamp matching) that separates it from more generic correlation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: it works on two explicitly bound layout charts and requires exact timestamp alignment. It also gives a when-not-to-use signal by stating the output is descriptive evidence, not a trading signal, though it does not name specific alternative tools or explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the internal logic: combining first-seen policy rates with complete collection heartbeats, rounding evidence start onto the frozen anchor grid, and reporting heartbeat-gap status. This gives a solid picture beyond just saying 'read readiness', though it stops short of specifying side-effect-free guarantees or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and resource. The second sentence is dense and packs multiple behavioral details into one long clause, but every clause adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a strong overview of the algorithm, but with no output schema it does not describe what the readiness result contains or how heartbeat-gap status is represented. More importantly, the optional as_of parameter is left completely unexplained, so an agent invoking the tool cannot confidently decide whether or how to set it. These are meaningful gaps for a tool whose only configurable input is undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one optional parameter as_of with only a timestamp pattern and no description, and the description never mentions as_of or how it influences the result. The parameter name hints at a date, but the description does not explain whether it sets the evaluation time, affects the anchor-grid rounding, or is safe to omit. This is a clear semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') targeting a named resource ('frozen carry_core_primary_v1 collection readiness') and explicitly distinguishes itself from chart-manipulating workflows by saying 'without switching a chart'. This is precise and clearly differentiates from siblings like get_oanda_flow_collection_readiness or chart-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without switching a chart' provides clear context for when this tool is appropriate. However, it does not explicitly mention when not to use it or point to a specific alternative for other readiness or collection checks, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full safety-and-behavior burden. It discloses what gets captured (whole window including watchlist, or one chart at full resolution) but stays silent on important traits: it targets the 'TradingView desktop app', implying the app must be running/visible, yet that precondition is unstated; it also doesn't say whether the capture has side effects or how the image is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and roughly 40 words carry action, purpose, default behavior, and the parameter exception. It is front-loaded with the core action and every clause earns its place; no filler or unnecessary schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-parameter tool, parameter knowledge is complete via the schema. But with no output schema and no annotations, the description omits what the caller receives (image binary, base64, or URL) and any preconditions on the desktop app being open — both matters an agent needs to handle the result and failure modes correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 genuine value beyond the schema: it frames chart_index as for 'a multi-chart layout' and promises 'full resolution' capture, which the schema description does not state. The format parameter's trade-off (jpeg smaller vs png sharper) is already fully covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action ('Capture a screenshot of the TradingView desktop app') with a clear purpose ('for visual analysis'). The scope detail (whole window vs single chart) further disambiguates it from siblings like get_chart_context, get_mtf_overview, and get_execution_snapshot, which return data rather than images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (whenever a visual capture is needed) and offers clear parameter-level guidance (use chart_index for a single chart of a multi-chart layout; the index comes from get_chart_context). However, it never names alternatives or states when-not-to-use, leaving tool-selection distinctions to inference from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It explicitly states that CFTC data is delayed, the result is a proxy rather than realtime order flow, and 'it never changes the chart,' which addresses the main side-effect concern. It does not describe return shape, COT freshness details, or any non-chart side effects, so it stops short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences contain no filler: the first packs the exact resource and the four data components, and the second adds the decisive caveats about being a proxy and never changing the chart. Every part contributes to selection or safe invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter tool with no output schema and no annotations, the description gives a strong conceptual overview but leaves the return contract unstated — an agent does not know what the combined context looks like, such as normalized observations, OI quadrants, or roll flags. The rich parameter schema mitigates input ambiguity, but output semantics and sibling routing remain gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 94%, so the schema already documents most parameters and their defaults, constraints, and provider-specific behavior. The description adds high-level conceptual framing for groups of parameters — trailing volume z-scores, OI quadrant analysis, roll anomaly detection — but no parameter-level details beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: it combines one exact TradingView CME/COMEX/CBOT/NYMEX continuous-futures daily chart with delayed CFTC COT, volume z-scores, daily OI four-quadrant analysis, and roll-anomaly detection. It also labels itself a 'market-participation proxy, not realtime institutional order flow,' which helps an agent distinguish it from execution/order-flow and other context siblings. The composition is distinctive enough that the tool is not easily confused with watchlist, journal, or price-action tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates a clear context of use — futures market-participation context combining COT, OI, and volume — and gives one exclusion: it is not realtime institutional order flow. However, it never explicitly says 'use when X' or names an alternative sibling for other cases, so routing among the many related context tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states the tool is read-only, never recommends a direction, and does not mutate charts, Pine, alerts, orders, or journals. It also clarifies that decision_status reports only data and gate readiness, which is valuable beyond the schema. It omits potential failure modes or latency, but the core side-effect profile is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 core purpose and scope, and the second adds essential safety semantics. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 21 parameters, no output schema, and no annotations. The description gives a useful high-level overview and safety guarantees, but omits the return structure, how parameters shape the bundle, what 'gate readiness' means concretely, and how to handle failures or partial data. An agent would need significant additional inference to invoke this tool confidently for varied use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 21 parameters and the schema description coverage is 0%, yet the description only lists high-level data domains (OHLCV, key levels, events, COT, real yield, execution evidence). It does not explain critical parameters like expected_timeframe vs. timeframes, include_real_yield vs. require_real_yield, event blackout windows, or execution timing controls. The description cannot compensate for the complete absence of parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Build one read-only evidence bundle for trade analysis.' It enumerates the data sources included and explicitly states what it never does, which distinguishes it from mutation-oriented siblings and single-source getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when a consolidated, multi-source evidence bundle for trade analysis is needed. It also establishes exclusions by stating that it never produces a directional recommendation and never changes charts, Pine, alerts, orders, or journals, though it does not name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a key side effect: it temporarily switches the requested chart per pair, loads only the requested history, and restores the chart after every pair. It also clarifies it does not run other carry studies, giving good behavioral boundaries, though it does not describe return format or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, side-effect behavior second, and scope exclusion third. Every sentence adds distinct information with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear purpose, the absence of an output schema and any parameter-level guidance leaves an agent without enough to confidently invoke the tool correctly or interpret its results. The behavioral side-effect note helps, but the 8-parameter, 0%-coverage schema demands more completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 8 parameters, but it does not explain seed, iterations, block_length_anchors, horizon_business_days, count, confirm, or pairs beyond indirect references. It only loosely connects 'block-bootstrap design effect' and 'each pair' to the respective parameters, which is insufficient for 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: measure actual pairwise return correlation and block-bootstrap design effect for a fixed daily FX panel before a carry primary test. It also explicitly distinguishes the scope by saying it does not invent policy-rate vintages or run a carry-return study, separating it from related carry-research siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear context ('before a carry primary test') and states exclusions: it measures price-panel dependence only, not policy-rate vintages or carry-return studies. However, it never names an alternative tool or says 'use X instead', so the routing guidance is strong but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 well. It explicitly describes separate null-model runs, the candidate criterion, the returned metrics, and important non-behaviors such as not touching TradingView, not journaling, not ranking variants, and not establishing profitability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense, information-packed sentences with the purpose front-loaded. Every sentence contributes either scope, output, acceptance criteria, or side-effect boundaries; there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations and no output schema, the description covers core outputs, the candidate rule, and behavioral boundaries well. However, it omits one supported study type and does not explain how failures are represented or when to choose this over sibling falsification/power audit tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for models, synthetic folds, and the seed-range output, but leaves first_seed and volatility behavior implicit. It also underrepresents the study parameter by naming only FVG-retest and session-auction while the schema includes a third variant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Calibrate' and a specific resource—one frozen event-study decision rule against synthetic OHLC—and enumerates the key outputs. It also distinguishes itself from ranking/profitability tools, though it omits the event_aftershock_retest variant that appears in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use when a single frozen event-study rule needs falsification against synthetic data with separate null-model runs. Negative boundaries are given, but no explicit alternative tool or when-not condition is named, so the agent must infer routing from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden, and it does so well by stating that the tool uses deterministic synthetic null OHLC, applies a specific statistical rule set, and has no TradingView or journal side effects. It does not mention computational cost or output behavior, but the side-effect profile and methodology are clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: purpose, statistical criterion, and exclusions. Information is front-loaded and every sentence earns its place, with no redundant filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (24 parameters, 6 required, no annotations, no output schema), the description is too sparse to fully support correct invocation. It explains the high-level methodology but omits what the tool returns, how results are reported, and how to choose the six required parameters, making it incomplete for an agent facing novel inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool has 24 parameters, yet the description provides almost no parameter-level guidance. Terms like 'horizon-one' and '1,000-replication' hint at horizons and replications, but required parameters such as minimum_observations, minimum_effect_bps, and configuration_trials are not explained, leaving an agent without enough information to set values correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Calibrate the frozen feature-outcome candidate gate'), a precise target ('deterministic synthetic null OHLC'), and enumerates what the tool does not do, which distinguishes it from sibling tools such as event-study or ranking-related audits. This is far from a tautology and gives an agent a clear operational picture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: use this tool to calibrate a feature-outcome candidate gate against synthetic null data and apply specified falsification rules. It also provides explicit exclusions (does not read/change TradingView, journal, rank, or establish profitability), which helps an agent avoid misuse, though it does not name alternative sibling tools or state an explicit when-to-use formula.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses data scope ('using only the signal bar and prior OHLC'), behavioral non-actions ('without optimizing thresholds, changing the chart, or making a trade recommendation'), and output shape ('bucketed forward-return, upside, downside, and fold distributions'). This is substantial behavioral disclosure that helps the agent predict 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the central purpose, then method, then output and exclusions. No redundancy; every sentence adds distinct information and the description is compact for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 28-parameter analysis tool with no output schema, the description gives a solid high-level summary of what it computes and returns. However, it omits invocation prerequisites (e.g., data must be loaded on the active chart), does not explain the 'fold' concept or the signal_from/to fixed-window behavior, and does not tie the description to the required parameters. Adequate for tool selection, not for full invocation guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 39%, so the description must compensate, but it does not fully. It does map the six feature enum values and hints at signal-bar/lookback semantics, yet it leaves the majority of the 28 parameters unexplained—including required minimum_effect_bps, signal_from/to, the regime object, configuration_trials, and observation_limit. This is meaningful but insufficient compensation for such a large parameter surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Measure'), resource ('relationships between selected closed-bar price features and later observed returns'), and tight constraints ('point-in-time', 'one exact TradingView chart'). It enumerates the six feature classes and adds negative scope ('without optimizing thresholds, changing the chart, or making a trade recommendation') that distinguishes it from related falsification and audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use this tool to measure feature-outcome relationships on a single chart in a point-in-time, non-optimizing way. It does not explicitly name alternative sibling tools like run_feature_outcome_falsification_audit or run_feature_outcome_power_audit, so routing among similar research tools remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers strong behavioral context: results are locally journaled, evaluations are 'monotonic latest,' and 'a completed evaluation is never displaced by a later stale ongoing read.' It also clarifies that the tool does not access or change the TradingView chart, which is valuable for an agent deciding whether to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the primary purpose is stated first, followed by a key monotonicity guarantee and a useful exclusion. Every sentence adds meaningful information, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a strong behavioral and purpose overview, which is good given there is no output schema and no annotations. However, it omits any guidance on the three optional parameters, which are the only way to scope the read. The agent can probably call the tool without parameters, but cannot confidently know how to use filters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the three parameters: limit, symbol, and analysis_id. While the parameter names are somewhat self-explanatory, the description does not say how they filter the journaled analyses or what the limit applies to, so the agent has to infer this from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Read locally journaled analysis definitions and their monotonic latest evaluations.' It also differentiates itself from chart-related siblings by explicitly stating 'This tool does not access or change the TradingView chart.' This is sufficiently specific and clearly distinguishes the tool from nearby alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: this is for reading local journaled analysis evaluations, not for chart interaction. It explicitly states what the tool does not do, which provides a when-not signal. However, it does not name specific alternative tools such as get_analysis_performance or get_analysis_calibration, so the routing guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses defaults (next 7 days, medium+ importance, US/EU/JP/GB) and the data source, but does not mention rate limits, pagination behavior, update frequency, or whether values may be missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the resource, the returned data, the use case, and key defaults in just a few sentences. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with fully documented optional parameters, the description and schema together cover purpose, defaults, use case, and returned fields. Slightly more behavioral context (e.g., output structure or limitations) would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 every parameter and its default value. The description repeats some defaults but adds no new parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get') and resource ('economic calendar events') and enumerates concrete event types and returned fields. It is clearly distinguishable from the sibling tools, none of which target economic calendar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to check whether upcoming news could invalidate a technical setup.' It does not mention exclusions or name alternative tools, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly indicates this is a retrieval operation and specifies what data will be returned (names, current values, defaults, tooltips). It doesn't cover edge behaviors like missing studies or empty results, but for a non-mutating getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded, and includes a useful example. Every word earns its place, with no filler or redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two optional parameters and no output schema, the description adequately covers what the tool returns. It includes example output to clarify the format. The only minor gap is the lack of explicit mention of behavior when no study_id is provided, though the schema already documents 'Default: all indicators'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 doesn't add parameter-specific meaning beyond what the schema already states about study_id and chart_index defaults, although the example does contextualize the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the input parameters (settings) of indicators') and the resource (indicators on a TradingView chart). It also lists the output contents (names, current values, defaults, tooltips) with a concrete example, making it easy to distinguish from siblings like get_indicator_values or set_indicator_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description — if you need indicator settings, this is the tool. However, it does not explicitly mention alternatives or exclusion criteria, such as when to use get_indicator_values instead, which would have earned a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the tool creates no candidate, outcome study, chart change, or order, and it qualifies Bookmap flow as a single-venue futures proxy rather than spot-FX-wide flow. It stops short of describing failure modes or file modification behavior, but the main safety-relevant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences, each earning its place: purpose, data caveat, and safety guarantee. It is dense but not bloated, and the key constraints are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains purpose, data semantics, and non-mutation, but with no output schema it should also indicate what a successful verification returns or how mismatches are surfaced. Given the domain-specific jargon and six parameters, the description is not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, and the description only implicitly covers expected_symbol/expected_timeframe via 'EURUSD M1 or M5' and session_file via 'local Bookmap Collector session'. It does not clarify count, interval_seconds, or minimum_intervals, which are important to this verification workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Read' and 'verify' against a precise resource: a local Bookmap Collector session joined to the active EURUSD M1/M5 chart. It also explicitly states it creates no candidate, outcome study, chart change, or order, which sharply differentiates it from the many research and study sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It is clear this is a preflight verification step to run before relying on Bookmap flow as a proxy for EURUSD chart context. It does not explicitly name alternative tools or spell out when-not-to-use conditions, but the read-only preflight framing and data qualification give sufficient guidance for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the study is descriptive only, never ranks or adopts a branch, is separately frozen, and uses an exact audited proxy. It does not disclose operational side effects such as history loading, resource usage, or whether prior chart state is touched, but the core non-mutating, non-decision-making behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. It front-loads the tool's core purpose, then defines the signal and measurements, and ends with the key exclusions. Every sentence contributes distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is conceptually rich and clarifies what the study measures, which is helpful since there is no output schema. However, for a 10-parameter tool with no annotations and very low schema coverage, it lacks operational guidance on required identifiers, fold definitions, signal windows, and event limits. An agent could select the tool correctly but would still struggle to fill several parameters correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 10%, so the description should compensate for the ten parameters. It does not explain required fields like pine_id, study_id, expected_symbol, expected_timeframe, nor optional controls like folds, signal_from, signal_to, or event_limit. The description adds useful conceptual context about the signal and measurements, but it does not help an agent map concepts to specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact study to run (the separately frozen descriptive #61b 60-minute POC-reversion study), the data scope (CME exchange-volume chart bars and the audited Bushido Volume Profile Context proxy), and the signal definition. It also explicitly distinguishes itself from the VAH/VAL reaction study, so a reader can identify its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states a when-not condition: it is not the VAH/VAL reaction study and its evidence must not be combined with that population. It also says it is descriptive only and never ranks or adopts a branch, which prevents misuse for decision-making. However, it does not explicitly name a positive alternative tool or give a precise selection rule among the many study siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the primary effect (returning to real-time mode) and the key requirement that confirm=true is needed when replay or its toolbar is active. It does not detail edge cases such as calling it when no replay is active, but the core behavior is transparent enough for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the action and effect stated first and the parameter requirement second. It loses a point because 'Preview or stop' is slightly awkward and could be more direct, but there is no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple boolean parameter and no output schema, the description is largely complete: it states what the tool does, the condition under which confirm is required, and the resulting chart state. It could mention what happens when replay is not active, but that is a minor gap given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the confirm parameter at 100% coverage, so the baseline is 3. The description adds value by clarifying that confirm=true is required specifically when replay or its toolbar is active, which is a useful condition beyond the schema's 'Must be true to leave Bar Replay.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action on a specific resource: it stops or exits TradingView Bar Replay and returns the chart to real-time mode. This distinguishes it from sibling tools like start_chart_replay and step_chart_replay, though the phrase 'Preview or stop' introduces slight ambiguity about whether previewing and stopping are different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is used when Bar Replay or its toolbar is active and the chart should return to real-time mode. It does not explicitly name alternatives or state when not to use it, but the sibling tool names make the intended usage easy to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explicitly states 'Read-only and does not access TradingView', which discloses side-effect profile and external dependencies. It also describes a behavioral constraint: no ranking or combining. It does not mention what happens with invalid references or duplicate entries, but the core transparency is above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and scope, followed by essential constraints. Every clause earns its place: count range, no ranking/combining, required fields, and read-only guarantee. No redundancy or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only comparison tool with one parameter and no output schema, the description covers invocation requirements and behavioral boundaries well. The only notable gaps are the lack of explicit sibling differentiation and no hint about the return format, though 'compare' implies a comparative result. Overall, it is sufficiently complete for a capable agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: it explains the references array accepts 2–20 items and each reference must contain both experiment_id and evidence_hash. It omits the exact object shape but the schema itself provides the pattern constraints, so the textual guidance is meaningful and adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compare' and the resource 'saved experiment-evidence records', and adds a scope of 'two to twenty'. It also notes what the tool does not do ('without ranking or combining incompatible populations'). However, it does not explicitly name or distinguish the closely-related sibling tool 'compare_research_evidence', so it falls just short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear conditions for use: 'exact saved experiment-evidence records' and 'References must include both experiment_id and evidence_hash'. It also provides an exclusion, noting the tool works 'without ranking or combining incompatible populations', implying those operations are not appropriate here. It stops short of explicitly naming alternative tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it discloses real methodology: 'resamples whole anchor-date cross-sections in circular moving blocks, preserving same-date pair dependence and serial dependence.' It also states its role boundary as a planning diagnostic rather than an adoption rule or return-study runner. It does not disclose output format or explicitly flag stochasticity (despite the required seed), which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose, methodology, then role boundaries. Each sentence earns its place and the purpose is front-loaded. The statistical method disclosure is dense but compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what, how, and when well, but there is no output schema and no mention of return semantics — for a stochastic estimator the result shape (point estimate, distribution, confidence bound?) matters. It also leaves seed/iterations unexplained and does not state prerequisites or runtime characteristics. Solid on the conceptual side, incomplete on the invocation side.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it partially does: 'circular moving blocks' hints at block_length_anchors and 'resamples' hints at the stochastic role of seed/iterations. However, no parameter is explicitly mapped or explained — seed, iterations, and observations receive no direct semantic treatment. The methodology language adds some meaning beyond the schema but does not fully cover the 4-parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Estimate the precision-equivalent sample size of an already fixed carry panel.' The timing qualifier 'before its primary test' and scope 'already fixed carry panel' sharply distinguish it from siblings like run_carry_core_primary_test (which runs the test) and measure_carry_panel_dependence (which measures dependence). No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context ('before its primary test') and explicit when-not-to-use boundaries ('a planning diagnostic only, never an adoption rule or a return-study runner'). It does not name sibling alternatives by name, but the exclusions implicitly route the agent away from adoption and return-study tools. Missing only explicit alternative tool names for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it declares read-only status, explains how missing/non-binary/cost data are handled (excluded with counts, not zero-filled), and clarifies the population boundary. It omits details like rate limits or response format, but the key behavioral traits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences with the core purpose front-loaded and exclusions stated efficiently. Every sentence adds meaningful information and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only aggregation tool with six optional filters and no output schema, the description gives a solid picture of scope, exclusions, and data handling. Some gaps remain around return shape and how grouping affects output, but overall it is substantially complete for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, and the description does not compensate by explaining the meaning or usage of most parameters. It only indirectly relates to cost_assumptions; bias, symbol, group_by, timeframe, and strategy_version remain dependent on schema enums/names for understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Aggregate'), a clear resource ('live analysis-journal outcomes'), and the exact metrics produced (win rate, gross/net R, MFE/MAE, timing). It also differentiates itself from backtest-related tools by explicitly stating it never mixes Strategy Tester backtests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this for live analysis-journal performance aggregation, and it explicitly excludes backtest data. However, it does not name specific sibling alternatives or state direct when-to-use versus other performance and journal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully covers behavioral side effects: it states the observation is appended to local first-seen history and explicitly says the call never changes a chart, Pine script, alert, or order. This goes well beyond a basic function summary and tells the agent exactly what persistent effects to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the primary purpose, the second clarifies scope and history behavior, and the third draws the safety boundary. There is no redundant or promotional language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers source, scope, persistence behavior, and non-effects. It does not explicitly describe the return shape, but the simple aggregate value is strongly implied; this is a minor gap only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema description coverage, there are no parameter semantics for the description to clarify. The baseline of 4 applies, and the description still adds context about the specific data source and scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Get CME's Daily Bulletin aggregate open interest for COMEX Gold futures (TOTAL GC FUT).' It clearly identifies the data as exchange-wide and independent from TradingView chart indicators, so an agent knows what this tool is for. It does not explicitly compare against sibling tools such as reconcile_gold_open_interest, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'exchange-wide ... total, independent from TradingView chart indicators' gives useful context for when this tool is appropriate, and the note about appending to first-seen history implies later analytical use. However, it does not explicitly state when to use this tool instead of an alternative, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals that the underlying records are 'append-only,' implying immutability, and explicitly states the tool 'never accesses a chart,' which is a useful behavioral constraint. It does not detail output format or error behavior, but it provides meaningful transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the primary listing behavior comes first, the conditional comparison mode follows, and the key exlusion is in a short final sentence. Every sentence adds useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough to understand the two invocation modes and the tool's relationship to charts, given the absence of an output schema and annotations. However, it does not explain what the returned records look like, how hypothesis_id affects behavior, or what exactly 'compare' returns, leaving some important context missing for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the conditional role of study_ids and evidence_hashes in compare mode, but it does not describe hypothesis_id at all, and the exact meaning of 'compare exact selected records' is only partially specified. This is adequate but leaves a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it 'List[s] append-only market-event and observational feature-study evidence records' and can also 'compare exact selected records'. It also disambiguates itself by stating 'It never accesses a chart,' which separates it from chart-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear mode-selection logic: listing is the default behavior, while comparison is used 'when both study_ids and evidence_hashes are supplied.' It also states a clear when-not condition: it never accesses a chart, so it should not be chosen for chart access. It does not explicitly name alternative tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds meaningful context: the history is separately stored, officially revised, and the tool never asserts historical availability. This goes beyond a generic read description, though it does not discuss error cases or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all the essential information with no filler. The primary purpose is front-loaded, and the caveat is placed immediately after, making the description easy to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 is mostly complete: it defines the data source, scope, and critical limitations. However, it does not describe what the returned history contains or any response format details, which would be useful given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter usage. It does not mention the 'currencies' parameter at all, leaving the agent to infer from the schema alone. The tool name hints at policy-rate history, but the description adds no meaning about how to supply currency selections.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a specific resource ('separately stored official revised policy-rate history'), and a clear scope ('for exploratory research only'). It also distinguishes the data from prospective or out-of-sample carry evidence, which helps differentiate it from related carry and policy-rate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly limits usage to exploratory research and explicitly warns against using it as prospective or out-of-sample carry evidence. It provides clear context and exclusions, though it does not name a specific alternative tool to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 fail-closed verification of source, study, symbol, and timeframe, the 'completed prior-session' constraint, and the 'only' limitation. It also warns that results are volume-derived, not direct order-flow evidence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences, front-loaded with the main result, then verification behavior, then an important caveat. Every clause adds information and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description reasonably defines the data scope and fail-closed behavior. However, it does not describe the actual return shape or units of POC/VAH/VAL, and chart_index remains unaddressed, leaving some ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 40% of parameters have schema descriptions, so the description must compensate. It does map saved source/study placement/symbol/timeframe to the main inputs, but chart_index remains unexplained and exact format constraints for expected_symbol/expected_timeframe are absent. The description adds some meaning but not complete parameter coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and resource ('completed prior-session POC, VAH and VAl only from the exact audited ... Pine template'). It clearly distinguishes from siblings like get_volume_profile_context_template and get_chart_context by narrowing scope and adding what it is not ('not direct large-order, Bid/Ask, or order-flow evidence').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use: reading saved volume profile levels for the prior session with a verified template. It tells the agent what the tool is not for, though it does not explicitly name alternative tools or state when-not-to-use relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses read-only semantics, closed-bar usage, the point-in-time regime join, the signal-bar-close-is-not-a-fill caveat, the lack of silent multiple-testing adjustment, and the absence of side effects such as ranking, chart changes, or order placement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence earns its place, front-loading the core purpose and then covering condition semantics, outputs, statistical honesty, and side-effect limitations. It could benefit from bulleted structure given the number of distinct behavioral claims, but the length is justified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong for the aspects it covers, including return metrics, exclusions, confidence intervals, and regime behavior, but it omits two condition types present in the schema: fair_value_gap_retest and composite_condition. Given the high complexity and absence of an output schema, these omissions leave the description somewhat incomplete for full autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite low schema description coverage, the prose adds meaningful semantics to the most complex parameters: it explains each major condition type, the regime split's lookahead safety, non-overlapping time folds, and caller-declared configuration trials. It does not elaborate on simpler required parameters like horizons or target_return_bps, but those are reasonably inferable from their names and schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Run a bounded, read-only market event study on closed OHLC bars from the active chart.' It clearly explains what the tool produces and enumerates several condition types, but it does not explicitly distinguish itself from related sibling studies such as run_event_study_falsification_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context by specifying that it operates on the active chart, is bounded and read-only, and never ranks parameters, changes the chart, or places orders. This helps the agent understand when to use it, though it does not explicitly name alternatives or state when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and handles it exceptionally well. It discloses that strategies are temporarily added and removed, chart restoration is verified, the operation reads closed OHLC, dry-run is the default, confirm=true is required, and saved Pine source is never changed nor orders placed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four focused sentences with no filler: purpose, process, output, and safety constraints each occupy a distinct and necessary sentence. Key operational facts such as 'Dry-run by default; confirm=true is required' are front-loaded and impossible to miss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity, absent output schema, and no annotations, the description is unusually complete: it covers behavior, side effects, safety guarantees, and the high-level return content. It does not detail return structure or error conditions, but for agent selection and invocation the provided context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 35%, so the description must compensate, but it only indirectly clarifies a few parameters such as confirm, jobs, symbols, and timeframes. The many regime thresholds, lookback windows, session configurations, and ratio parameters remain unexplained by the description, leaving the agent to infer their meaning from names and schema constraints alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run'), a concrete resource ('a bounded serial matrix of exact saved Pine Strategies'), and a clear scope ('across explicit symbols and timeframes'). It also distinguishes itself by noting the output is descriptive and 'without ranking or automatic adoption', which separates it from related analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance: it is a dry-run by default, confirm=true is required, and ranking/adoption are intentionally excluded. However, it does not explicitly name alternative sibling tools or state precise conditions for choosing this tool over them, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the audit is static/source-level and explicitly warns that it is not proof of non-repainting. It also reveals an important pipeline constraint: results remain restricted until restart-difference validation is recorded. This is meaningful behavioral context beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the action, target, and purpose; the second adds the critical limitation and downstream validation dependency. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for an agent to understand when to call the tool, what it does, and what constraints apply to its results. There is no output schema, but the description's mention of 'constructs that can repaint' and the restriction on results gives the agent a reasonable mental model of the output. It could go further by describing the shape of the audit findings, but this is not a serious gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have useful descriptions: pine_id references list_pine_scripts and version includes a default and regex pattern. The tool description adds no parameter-specific meaning, but it does not need to because the schema already explains both parameters adequately. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Statically audit one of the user's Pine scripts for constructs that can repaint or make realtime values differ from historical values.' This clearly distinguishes the tool from siblings like get_pine_source or list_pine_scripts, which fetch rather than audit. It also names the exact concern the audit addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: check a user's Pine script for repaint or realtime/historical divergence risks. It also sets expectations that this is a source-level screening step, not definitive proof, and that results stay restricted until validation is recorded. It does not explicitly name alternative tools for non-repaint proof, but the distinction between screening and validation is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the behavioral burden and does well: it discloses that the computation is deterministic, non-directional, has no side-effect of fetching or gap-filling, and does not emit trade recommendations. It does not mention error handling, insufficient observation behavior, or return formatting, but the core side-effect profile is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two purposeful sentences: the first states what the tool computes and with what inputs; the second states three important exclusions. Every clause earns its place and the key scoping appears immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for an agent to select and call the tool: it explains the input provenance, the computation scope, and the main outputs. The lack of an output schema means the description could have added more about return shape, but the listed features plus full parameter schema provide sufficient operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a semantic description. The tool description reinforces that observations are aligned closed bars from get_aligned_history and that primary_symbol is the object of the return/volatility/ATR computation, but it adds no new parameter-level meaning beyond the schema, which is the baseline expected at this coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('compute'), a precise resource ('deterministic, non-directional features from exact-time-aligned closed OHLCV observations'), and enumerates the concrete outputs (close-to-close return, realized volatility, ATR, return correlations). It also distances the tool from data retrieval by pointing at get_aligned_history, which disambiguates it from the many sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the intended context: use it on observations 'typically returned by get_aligned_history' and not to fetch data, fill gaps, or generate trade recommendations. It stops short of explicitly naming alternative tools for those adjacent tasks, so it misses the top anchor for explicit when-to-use routing, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 richly: it discloses no-lookahead behavior ('uses only that bar and earlier evidence'), determinism ('deterministic', 'Thresholds are explicit', 'no future-fitted quantiles'), and side-effect absence ('no ... chart changes, or trade recommendations'). It also reveals the underlying methodology (efficiency ratio, ATR-normalized directional movement, ATR vs trailing median), which is non-obvious and highly useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: purpose first, then methodology, then boundary disclosures. Each sentence earns its place, though the final sentence's negation list ('no future-fitted quantiles, ranking, chart changes, or trade recommendations') is slightly dense and could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no annotations and no output schema, the description covers purpose, methodology, and behavioral guarantees well, but it omits the return contract entirely: observation_limit implies a rows-plus-aggregates result and minimum_classified_bars implies a status concept, yet neither is explained. It also doesn't clarify why expected_symbol/expected_timeframe are 'expected' (presumably validation against the loaded chart), which is a meaningful behavioral gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 85%, so the baseline is 3, but the description adds genuine conceptual glue: it explains how parameter groups map to the classification logic (efficiency ratio → trend/range thresholds, ATR-normalized movement → directional_move_atr_threshold, ATR vs trailing median → volatility ratios and baseline lookback). This helps an agent reason about parameter interactions beyond the per-field defaults and constraints in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Classify deterministic directional and volatility regimes from closed OHLC bars') and enumerates the exact labels produced (trend/range/transition, low/normal/high volatility). It distinguishes itself from siblings like compute_correlation_regimes and compute_market_features by specifying its scope: point-in-time deterministic classification from chart bars only, with no future-fitted quantiles or trade recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states clear prerequisites ('bars already loaded on the active chart', 'closed' bars) and implies when the tool is appropriate, but it never explicitly names alternatives or states when-not-to-use in favor of another sibling. The determinism and 'no trade recommendations' disclosures hint at boundaries, but an agent must infer the routing decision rather than having it spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses idempotency, transactional ordering, migration, verification, old-instance removal, fail-closed checks, and preview-only behavior without confirm=true. This is exceptionally transparent for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and every sentence adds crucial behavioral detail. There is no filler or unnecessary repetition; it reads as a tight, information-dense spec.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex transactional tool, the description is highly complete: it explains the idempotent flow, transactionality, fail-closed validation, and preview gating. The main omission is chart_index semantics and any indication of return/result shape, which would improve completeness but are not fatal given the strong behavioral coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate. It adds meaning for confirm (preview-only), expected_symbol/expected_timeframe (checked), and pine_id (checked), but chart_index is left unexplained. This is a clear gap, though most parameters gain some context from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: idempotently ensure the audited Bushido Analysis Overlay is present once at the latest Pine version. It further explains the exact mechanisms (reuse, add, transactional migrate, verify, remove old), which distinguishes it from sibling tools like add_pine_to_chart or apply_analysis_overlay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when the overlay must be present exactly once and at the latest version. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer the distinction from the behavior described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and it provides useful details: most recent primitives first, and extrapolated times flagged timeEstimated. These are real behavioral traits beyond the basic 'get' semantics, though it doesn't discuss errors or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct value: what it returns, when to use it, and ordering/flag behavior. No filler or repetition, and 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with three optional, fully-described parameters, the description covers the key context: primitive kinds, use case for drawing-only indicators, ordering, and extrapolation flagging. Without an output schema it could specify return structure more, but the given detail is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description including defaults and constraints. The tool description adds only redundant ordering context already present in limit_per_kind, so it provides no meaningful additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does: retrieves drawing primitives (labels, trend lines, boxes/zones) from a Pine indicator on a TradingView chart. It also differentiates itself from numeric-plot tools by calling out drawing-only indicators, which clearly separates it from siblings like get_indicator_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says this is how to read drawing-only indicators with no numeric plots, giving clear context for when to use it. It does not explicitly name alternative tools for numeric plots, but the contrast with 'no numeric plots' implies the boundary well enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that cosmetic plots are excluded by default, that plot names come from the indicator's own style titles, and that long-history requests require plot_titles for readability. These are meaningful behavioral details beyond the schema, though it does not describe return formatting or explicitly confirm read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no fluff. The core purpose is front-loaded, and each sentence adds relevant operational context: style titles, cosmetic exclusions, the prerequisite get_chart_context, and the plot_titles condition with rationale.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers the key invocation needs: how to discover indicators, how to narrow plots, and when plot_titles is required. The schema handles parameter defaults and constraints. A brief statement of the return shape would make it fully complete, but nothing critical for actually calling the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds some context, such as plot titles coming from style titles and the default exclusion of cosmetic plots, but mostly reinforces what the schema already states, e.g. the above-500 plot_titles requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Get recent plot values of indicators (studies) on a TradingView chart', with concrete examples like signal levels and oscillator readings. It clearly distinguishes this from sibling tools such as get_indicator_graphics or get_indicator_tables by scoping to plot values, and it further narrows scope by noting cosmetic plots are excluded by default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit pre-requisite guidance: 'Use get_chart_context first to see which indicators exist' and explains when to narrow with plot_titles, including the condition that plot_titles is required above 500 bars. It does not explicitly name alternative value-adjacent tools or say when not to use it, but the context provided is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states the operation does NOT touch the user's chart and that it batches multiple timeframes and symbols into one call. It does not discuss return format, rate limits, or data freshness, but the key non-mutating behavior is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated; every clause adds information. It front-loads the core distinguishing trait (no chart mutation) and packs the default fields and multi-symbol comparison into the first sentence. The second sentence provides a concrete use case. Minor readability loss from the long dash-connected first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it, and how to use it. However, since there is no output schema and no annotations, the agent is left without explicit information about the response shape, how results are organized, or whether any read-related caveats exist. This is a moderate gap for a tool intended to support analysis decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 semantics beyond the schema by listing the default indicator fields (close, RSI, ADX, ATR, EMA20, SMA50, SMA200, Recommend.*), explaining that the same fields appear across timeframes, and clarifying that multiple symbols can be compared in one call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a multi-timeframe overview of indicator fields for one or more symbols in a single call, without touching the user's chart. It explicitly differentiates itself from set_timeframe and other chart-focused tools by emphasizing the non-mutating behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: use for top-down analysis before or instead of set_timeframe, and pass multiple symbols to compare majors side by side. It names an alternative and provides context, though it does not enumerate when-not-to-use cases with other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and covers key behavior: read-only, no editing/saving, and refusal of published/protected third-party scripts. It does not go into error cases, rate limits, or response format, but the core constraints are explicit and not hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The core action and scope lead off, followed by compact restriction and read-only statements. Every sentence adds a distinct, necessary fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, read-only fetch with no output schema, the description is nearly sufficient: it covers the target object, eligibility, read-only nature, and parameter constraints via the schema. Missing explicit error behavior or return format are minor for this simplicity, keeping it a step below complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces the pine_id eligibility rule (USER-only, third-party refused) and the version default is already in the schema. The 'revert a bad save' insight appears in the schema, not the description, so the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Get the full Pine source code') scoped to the user's OWN saved scripts, clearly distinguishing it from siblings like list_pine_scripts (which lists script metadata) and save_pine_script (which writes). The added restriction against published/protected third-party scripts sharpens the tool's identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the eligibility rule: only 'USER;...' ids from list_pine_scripts are accepted and third-party scripts are refused. It also disclaims editing/saving support. It does not name a specific alternative tool for editing, but the read-only note and referenced list_pine_scripts give enough context for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It meaningfully discloses that the data is a proxy, weekly, delayed, and not a realtime order-flow signal, which protects against misinterpretation. It does not describe output shape, units, or failure modes, but the most important behavioral caveats are addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main action is front-loaded and the critical caveat about data frequency and non-realtime nature follows immediately. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with a fully described schema, the description is mostly self-contained: it covers data source, frequency, delay, scope, and the key non-realtime limitation. The lack of an output schema means a brief note on the returned positioning proxy shape would make it fully complete, but nothing essential is missing for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description does not add semantic detail beyond what the schema provides: symbol support and weeks meaning are already in the property descriptions. This is the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action and resource: getting the latest or recent public CFTC COT positioning proxy. It scopes this to supported FX or gold symbols and adds a differentiating caveat that this is weekly, delayed futures data, not a realtime order-flow signal. This makes the tool's purpose clear and distinguishable from realtime flow-oriented sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need COT positioning context for supported FX or gold symbols. It explicitly warns that the data is weekly, delayed futures data, not a realtime order-flow signal. It stops short of naming a specific alternative for realtime order flow, so it lacks full when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 does so well by disclosing the exact date-matching rule and the handling of missing dates as quality evidence. It could additionally state whether the reconciliation writes records or is read-only, but the disclosed behaviors are materially useful and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The primary action and data sources are front-loaded, and the crucial matching rigor is stated immediately in the second sentence. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient to understand the tool's purpose, input semantics, and date-handling philosophy. The main gap is that it does not describe the shape or format of the reconciliation output, and there is no output schema to compensate; however, the tool's expected behavior is still clear enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are fully described in the schema: as_of as a point-in-time cutoff and weeks as the COT report weeks to inspect. The description adds no parameter-specific detail beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action ('Reconcile') with a specific source pair: CFTC Gold COT open interest against local first-seen CME Daily Bulletin TOTAL GC FUT open interest. This clearly differentiates it from related tools like get_cme_gold_open_interest, which presumably returns raw data rather than performing reconciliation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational constraints: only identical report/observation calendar dates are compared, and missing dates are never matched or filled. This tells an agent when the tool is appropriate (strict date-aligned reconciliation) and what to expect about date handling, though it does not explicitly name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the entire burden of behavioral disclosure. It does this exceptionally well: temporary strategy addition, immutable ledger, dry-run by default, mandatory confirm, strategy removal, chart fingerprint verification, and explicit no-op guarantees (no ranking, no source changes, no orders).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet compact. Each sentence delivers distinct value: the action and ledger, the returned metrics, the dry-run/confirm requirement, the cleanup/fingerprint verification, and the negative guarantees. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 23 parameters, no annotations, and no output schema, the description provides a strong high-level overview and return metrics, but leaves many configuration semantics unexplored. The schema covers some parameters, but the overall context is not fully sufficient for reliably invoking such a complex tool with correct optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, so the description should compensate, but it only clarifies the confirm parameter ('confirm=true is required') and the generic regime-join concept. Most parameters (atr_lookback, trend_lookback, event_proximity, correlation_regime, thresholds, lookbacks) are not explained in the description and some lack schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Run one exact saved Pine Strategy temporarily'), the resource, and the analysis pipeline (join trades to regime bars). It also distinguishes itself by explicitly saying it 'never ranks regimes', which separates it from siblings like run_strategy_regime_matrix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use: for analyzing one saved strategy's trades against regimes. It provides key preconditions like 'Dry-run by default; confirm=true is required' and exclusions ('never ranks regimes... or places orders'). However, it does not explicitly name alternative tools for different use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds important behavioral context beyond the name: the replay cursor must advance with each step, and autoplay/Replay Trading orders are unsupported. It could mention failure modes, but the core behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, information-dense sentences with no filler. The core action is front-loaded, and each sentence provides a distinct piece of necessary guidance: what the tool does, its state prerequisite, and its limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential invocation context: state prerequisite, step range, and unsupported modes. It does not specify error behavior or return value shape, but the information provided is sufficient for correct use in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema fully documents the 'steps' parameter including min, max, default, and a descriptive label. The description adds little beyond restating 'by 1-100 bars', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Advance') and resource ('TradingView Bar Replay'), and further clarifies the exact operation (advance by 1-100 bars) and the required state (already started, paused). This clearly distinguishes it from sibling tools like start_chart_replay, stop_chart_replay, and get_replay_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the prerequisite condition ('already started, paused') and explicitly lists unsupported modes ('Autoplay and Replay Trading orders are not supported'). It does not name alternative tools explicitly, but the conditions make the intended use case clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does so well. It discloses the read-only default, the confirmation gate, the verifications performed (Pine source, chart binding, analysis_id, current price, existing owned alerts, post-create readback), and exclusions such as no webhooks, email, SMS, broker APIs, or orders. This is rich behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: purpose, verification behavior, and safety boundaries. The key safety information about confirm=true is front-loaded. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not explain what the return value looks like, though it hints at 'post-create readback.' For a 9-parameter mutation tool, the description covers core invocation and safety but leaves return format and exact failure conditions unspecified, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44%, so the description needs to compensate for undocumented required parameters. It adds meaning around confirm=true and mentions analysis_id and Pine source/chart binding verification, but it does not explicitly explain pine_id, expected_symbol, expected_timeframe, chart_index, or output behavior. The schema patterns and 'expected_' prefix provide partial semantics, so the description adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 previews or creates bounded, one-shot TradingView price alerts for Confirmation, Invalidation, and Target 1 from an audited Bushido Analysis Overlay. It also distinguishes itself from pure listing tools by emphasizing creation and verification, so an agent can tell it apart from list_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the preview-versus-create behavior: 'Without confirm=true it is read-only.' This gives the agent an explicit condition for invoking mutation versus safe preview. It does not name sibling alternatives or explicitly state when not to use the tool, but the context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does so well. It explicitly states the operation is read-only ('without changing the chart'), explains internal validation behavior (resolving by USER pine_id, verifying Pine version source and input contract), and enumerates what the response contains: analysis metadata, expiry, current-price relations, risk/reward references, and drawing integrity. It also discloses the limitation about level states vs. historical touch order.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently sized at three sentences and front-loads the most important fact ('Read... without changing the chart'). Some phrasing is dense and jargon-heavy, such as 'context-bound input contract,' but every sentence contributes substantive information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a solid inventory of returned content and read-only behavior. It could be more complete by addressing the optional chart_index parameter and potential validation failure modes, but for a status-read tool the core selection and invocation context is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description should compensate. It does add meaning by mentioning that the study is resolved by USER pine_id and that expected_symbol and expected_timeframe form a 'context-bound input contract,' which helps clarify their role as validation constraints. However, it does not explain chart_index at all, and the individual parameter semantics remain mostly implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Read the current Bushido Analysis Overlay state without changing the chart.' This clearly identifies the tool as a read-only status inspection and distinguishes it from mutation-focused siblings like apply_analysis_overlay and ensure_analysis_overlay. It also names the key entity (Bushido Analysis Overlay) and the kind of data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: it is for reading current overlay state without mutation, and it explicitly warns that level states do not reflect historical touch order, directing the agent to 'a future outcome tool' instead. This is a useful exclusion, though no sibling tool is named by name, so routing is slightly less explicit than it could be.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly says 'Read-only,' which is important, and adds that the template reads confirmed DXY daily data with lookahead_off. This is meaningful behavioral context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no filler. It front-loads the action ('Return'), names the resource, and includes the key behavioral qualifiers without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only template getter, the description fully covers what the tool does, what the template contains, and its read-only nature. No output schema is present, but the description usefully identifies the exposed plots, so an agent knows what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 100%, so there is no parameter documentation burden. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a fixed Pine Study template specifically for DXY context gate, naming the exact outputs (dxy_return_20 and dxy_gate plots). This distinguishes it from sibling template tools like get_volume_profile_context_template and get_price_action_context_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs the DXY context gate Pine template and notes it is read-only. However, it does not explicitly state when to prefer this tool over alternative template getters or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that the operation is a read of tables, describes the exact return shape (grid[row][column] plus on-chart position), and clarifies the table-only scope. It does not discuss potential errors or rate limits, but for a read-only tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly packed sentences. The first sentence front-loads the action, the resource, and the output format; the second adds a decisive scoping fact. There is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers what is returned, how it is structured, and when this tool is uniquely necessary. The optional parameters are fully documented in the schema, so the description plus schema is sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already fully documented in the schema with descriptions and defaults, giving 100% schema description coverage, so the baseline of 3 applies. The description adds no parameter-level detail, but none is needed because the schema already explains study_id and chart_index adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('tables drawn by Pine indicators on a TradingView chart'), and precisely describes the output form as text grids with row/column plus on-chart position. The phrase 'only way to read table-only summaries that have no plots or drawings' distinguishes it from sibling tools like get_indicator_values and get_indicator_graphics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to read Pine-indicator tables, especially table-only summaries without plots or drawings. It adds a strong exclusivity signal ('This is the only way'), but it does not explicitly name or compare alternative sibling tools, so it stops short of a full when/when-not matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses the key side effect (visible chart view unchanged) plus the return payload (bars added and new earliest bar time). It omits permissions, failure modes, or repeated-call behavior, but what is stated is enough for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first provides action and purpose, the second clarifies a non-effect and the return value. There is no filler and 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully orients an agent: why to call it, what side effect it does not have, and what it returns. With no output schema, the stated return values are sufficient for an agent to invoke the tool and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both count and chart_index already have descriptions in the input schema. The tool description adds no new parameter-level semantics, so the baseline score of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific verb ('Load'), a resource ('historical bars into a TradingView chart'), and a clear goal ('so that get_ohlcv and get_indicator_values can see further back'). It also distinguishes behavior from ordinary chart scrolling by noting the visible chart view is not changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context is provided: use this tool when get_ohlcv and get_indicator_values need older history. It also gives a useful when-not signal by stating the visible chart view is not changed, though it does not explicitly name an alternative tool or exclusionary condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 an excellent job: it discloses temporary chart reuse, restoration after each read, optional history loading, lack of persistent symbol/timeframe changes, and the strict counting rule. This gives the agent a clear picture of side effects and non-effects beyond what any schema could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and well-structured: purpose first, then mechanics, then exclusions and limitations. Every sentence adds distinct value, and the most important behavioral constraints are front-loaded without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, and no output schema, so the description must do more heavy lifting. It covers side effects and scope well, but it omits definitions for 'count' and 'minimum_aligned_bars' and does not specify the return shape beyond implying an intersection count. For a tool an agent must invoke with correct parameter values, these are important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description must compensate. It does clarify the roles of target_chart_index and auxiliary_chart_index, the expected symbols, the timeframe, and load_more_bars behavior. However, 'count' and 'minimum_aligned_bars' are never mentioned or explained, even though they are likely central to the preflight logic, leaving a meaningful semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a coverage preflight for the cross-asset shock study and specifies exactly what it does: bind an EURUSD or USDJPY target chart, temporarily reuse an auxiliary chart for DXY/US10Y/XAUUSD, and count exact UTC closed-bar intersections. It also explicitly distinguishes itself from outcome-producing tools by stating that no shock threshold, direction, outcome, order-flow claim, or trading instruction is produced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining this is a preflight/coverage-checking operation and explicitly lists what it does not produce, which helps an agent avoid using it for outcome analysis or trade instruction. However, it does not name alternative sibling tools directly or state explicit conditions like 'use this before running classify_cross_asset_shocks.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 clearly communicates immutability, append-only journaling, non-execution of tests, no TradingView access, and rejection of reused hypothesis IDs with different definitions. These are concrete behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, with the core purpose front-loaded. Every sentence adds a meaningful constraint or clarification, and there is no redundant restatement of the tool name or schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a rich nested schema, the description appropriately focuses on purpose, side effects, and constraints rather than repeating schema details. It clearly establishes that this is a registration-only action, not a test runner, and explains immutability and ID uniqueness. The main gap is the lack of explicit guidance on how this tool fits into the larger workflow with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain parameter meanings, but it only generically references 'hypothesis' and 'evaluation contract'. It does add one useful semantic for hypothesis_id (reuse with a different definition is rejected), but it leaves title, thesis, evaluation_contract fields, and parent_experiment_id unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Register'), a specific resource ('one immutable strategy-research hypothesis and its evaluation contract'), and a specific destination ('a local append-only journal'). It also differentiates itself from siblings like register_event_study_hypothesis and run_backtest by clarifying that this is for strategy research and does not run a test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: to persist a hypothesis and its evaluation contract before testing. It also gives a when-not signal by stating it does not access TradingView or run a test. However, it does not explicitly name alternative tools such as run_strategy_experiment or run_backtest for those testing needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does so thoroughly. It discloses the entry rule, exit horizon, absence of stops/targets/filters, the use of Pine template default rules, the description-only IID normal-approximation interval, and the session-boundary caveat that prevents a common misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense but well-structured single paragraph. It front-loads the core purpose, then adds methodology, output details, and a valuable interpretive caveat without filler. Every clause earns its place given the complexity of the study.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a research tool with no output schema, the description explains the study design, what is reported, and how to avoid misreading the results. Minor gaps remain around which three patterns are studied, the exact meaning of 'h', and chart_index semantics, but the required parameters and study behavior are largely inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only 'count' documented. The description does not explain expected_symbol, expected_timeframe, or chart_index, so it does not compensate for the coverage gap. It only implicitly references the chart through 'chart's own bars,' which is not enough parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb, 'Measure', and a specific object: what the three price-action patterns are worth as naked entries on the chart's own bars. It adds concrete entry/exit rules, which makes the tool's distinct purpose clear relative to the many sibling event-study and audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the intended use: evaluating price-action patterns with no stop, target, or filter, and comparing them against the same hours' baseline behavior. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to select this tool over sibling studies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden and does substantial work: it declares the operation read-only and static, limits scope to 'one exact saved Pine strategy version', lists all audit checks, and discloses non-actions. It stops short of describing the result/verdict format or whether the validation outcome is persisted, which is meaningful for an adoption-decision tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero filler, purpose front-loaded in the first sentence, the audit checklist packed efficiently into the second, and the non-goal exclusions isolated in the third. Each sentence earns its place and the structure makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, nested objects, no annotations, and no output schema, the description is rich on purpose and inputs but silent on what the agent receives back — there is no return-value or verdict-structure hint, and failure behavior is unstated. Since the tool exists to inform adoption decisions, the absence of output expectations is a notable gap that the description could not offload to annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: nearly every audit dimension maps to parameter groups (minimum trades → minimum_trades, explicit costs → costs, forming-bar use → closed_bars_only, candidate multiplicity → candidate_ids, definition changes after OOS access → definition_frozen_at/definition_last_changed_at, IS/OOS and future windows → windows). Observed_trades is the one parameter not conceptually referenced, and the description doesn't explain how to structure nested objects beyond the schema, but the compensation is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Validate a frozen strategy-research protocol before adoption decisions') and enumerates the exact audit dimensions (IS/OOS overlap, future windows, forming-bar use, candidate multiplicity, minimum trades, explicit costs, restart-difference evidence, definition changes after OOS access). It also distinguishes itself from siblings by explicitly listing what it is not ('does not run a backtest, inspect the chart, or prove non-repainting'), which differentiates it from run_backtest, get_chart_context, and repainting audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context ('before adoption decisions') and explicit when-not-to-use exclusions (does not run a backtest, inspect the chart, or prove non-repainting). However, it never names an alternative sibling to route the agent to when those non-goals are actually needed, so the guidance stops at exclusion rather than active redirection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden and delivers: the fail-closed guardrail, the read-only preview behavior without confirm=true, the precise mutation boundary ('changes only that overlay's inputs'), the post-write verification readback, and the explicit exclusion 'It never places orders or alerts.' This is exemplary behavioral disclosure for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, safety guardrail, mode semantics (split into two tight clauses), and side-effect exclusion. Purpose is front-loaded, and the structure flows logically from what the tool does to how it behaves safely. Zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (19 params, 12 required, no output schema, no annotations), the description covers the essential behavioral contract thoroughly: modes, guardrails, mutation scope, verification, and side-effects. It gives partial return information ('returns a preview', 'reads them and its drawing totals back for verification'). What remains absent is error-response detail and explicit analysis-payload semantics, but the description is sufficient for safe selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 32%, so the description must compensate. It does meaningfully for the most behaviorally critical parameter (confirm, going beyond the schema by describing the readback/verification contract) and for expected_symbol/expected_timeframe by placing them in the fail-closed matching logic. However, 13 of 19 parameters (bias, entry_low, entry_high, invalidation, stop, targets, confidence, etc.) receive no description-level meaning beyond their names, leaving the analysis payload semantics partially to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb pair and resource: 'Preview or apply a structured market analysis to an existing Bushido Analysis Overlay study.' It clearly distinguishes the two operating modes and the specific target (an existing overlay), which separates it from sibling tools like ensure_analysis_overlay (creation) and get_analysis_overlay_status (read-only status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear invocation context: it applies to an existing overlay, requires symbol/timeframe/contract matching (otherwise fails closed), and explains the preview-vs-commit decision via the confirm flag. It does not explicitly name alternatives or state when not to use it, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden and does so excellently. It explicitly discloses that missing values never match, and that the tool does not read files, authenticate hashes, execute code, persist records, or certify compatibility, calibration, unused OOS, or candidate eligibility. This is unusually transparent and prevents false assumptions about side effects and guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences with no filler. The main action and resource are front-loaded, what it reports follows immediately, and the non-behaviors are listed compactly. Every sentence earns its place and the structure makes the tool's boundaries easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description does a strong job: it covers the input kind, the comparison axes, the report contents, and important caveats. It could add a bit more about the exact output shape or the meaning of 'unknown axes', but what is missing is minor given the schema already defines the input structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names the six compared axes (data, code, runner, candidate rule, parameters, environment) and clarifies that manifests are caller-supplied, but it does not explain how the 'previous' and 'current' objects map to the schema fields beyond enumeration. The 'Missing values never match' statement adds useful semantic, but the parameter semantics are only partially fleshed out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compare') and identifies the exact resource ('caller-supplied SHA-256 manifests for previous/current research data, code, runner, candidate rule, parameters and environment'). It also states what the tool reports ('changed and unknown axes plus required revalidation checks'), making it clearly distinguishable from sibling comparison tools like compare_strategy_experiments or compare_indicator_observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 comparing previous and current research manifests to identify changes and required revalidation. It does not explicitly name alternatives or exclusion conditions, but the context is strong and the negative boundaries ('Does not read files...') help an agent understand what this tool is not for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so thoroughly: exact UTC timestamp matching, no forward-filling, v3 causal RMS scaling, per-lag interval/stability output, no best-lag selection, disabled eligibility/journal promotion due to calibration, and descriptive-only status. This goes well beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries distinct information and the primary purpose is front-loaded. There is no repetition of schema fields or filler; the technical constraints are ordered logically from alignment to scaling to output to calibration implications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with no output schema and no annotations, the description covers a remarkable amount: alignment behavior, defaults, output characteristics, calibration restrictions, and evidence status. It still lacks explicit guidance on the return payload shape beyond interval/stability and on the semantics of some parameters like confidence_level, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 47% and the description compensates for some parameters (symmetric lag range maps to max_lag_bars, prior-20 RMS scaling maps to return_standardization, exact UTC alignment maps to alignment_mode, per-fold stability maps to folds). However, several parameters such as count, confidence_level, folds structure, and the required expected_* fields receive no semantic explanation in either the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Scan return correlation') on a specific resource ('two explicitly bound layout charts') with a clear investigative goal (whether reference market leads primary). It also distinguishes itself from audit siblings by emphasizing 'Descriptive evidence only, never a trading signal' and by noting no best lag is selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear intended-use context: use this to explore lead-lag correlation via symmetric lags, and explicitly warns it is descriptive evidence, not a trading signal. It does not name alternative tools or give explicit when-not-to-use conditions beyond the descriptive-evidence caveat, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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: quantity 'is always rounded down,' the tool 'fails closed when conversion evidence or minimum-size capacity is missing,' and it is side-effect-free regarding accounts/orders. These are precisely the behavioral traits an agent cannot infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler; the core operation is front-loaded, then deterministic behavior and safety exclusions follow. Every sentence contributes distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter calculator with no annotations and no output schema, the description covers the operation, key input classes, fail-closed behavior, and side-effect safety. The main gaps are the missing risk-parameter relationship and precise return payload, which are mitigated by the clear 'instrument quantity' phrasing and self-descriptive parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 6%, so the description must compensate. It adds useful semantic grouping: 'explicit execution cost,' 'quantity constraints,' and 'fresh quote-to-account currency evidence' map to several optional parameters, and 'risk-budgeted' signals the risk inputs. However, it does not explain the risk_amount/risk_percent choice, contract_multiplier, or which constraints are min/max/step, leaving real invocation ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise operation: 'Compute a risk-budgeted instrument quantity' from a specific set of inputs. It also disambiguates from execution/order tools by stating it 'does not access an account or place an order.' This is a verb+resource statement that separates it from the many compute_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: pure pre-trade calculation using entry, stop, cost, constraints, and currency evidence, and explicitly excludes account access/order placement. It does not name a specific sibling alternative or provide a when-not condition beyond that behavioral exclusion, so it falls one step short of explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states non-actions ('does not change the chart, optimize session definitions, or make a trade recommendation') and discloses a data quality caveat: volume is 'clearly labelled as unverified tick-or-exchange volume.' It also specifies use of closed minute bars and deterministic profiles. It does not mention side effects like API-side computation cost or rate limits, but the main behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: the main purpose, timezone/boundary support, the list of computed outputs, and explicit non-goals. Key qualifiers like 'deterministic,' 'closed minute bars,' and 'one exact TradingView chart' are front-loaded. No filler or repetition is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description lists the major return components—coverage, OHLC range, return, opening-range extension, high/low timing, VWAP, PDH/PDL/PDC reactions, and volume—which gives an agent a good sense of what to expect. It also clarifies that observation limits apply only to returned sessions while aggregates use all rows. It does not provide a precise output structure, but for invocation purposes it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining session semantics: caller-specified IANA timezones, daylight-saving and cross-midnight boundary support. It also maps to outputs like 'opening-range extension' (relating to opening_range_bars) and 'coverage' (relating to minimum_coverage). This extra context enriches parameter understanding without being redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair: 'Summarize deterministic session-day profiles from closed minute bars on one exact TradingView chart.' This clearly distinguishes it from sibling tools like get_ohlcv or compute_market_regimes. The scope is explicit via 'one exact TradingView chart' and 'deterministic,' making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: analyzing session-day profiles with caller-specified IANA timezones, daylight-saving, and cross-midnight boundaries. It also states exclusions—'does not change the chart, optimize session definitions, or make a trade recommendation'—which helps agents understand what not to expect. However, it does not name specific sibling tools to use as alternatives for those excluded tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It explicitly states the tool 'never changes charts and never forward-fills' and describes how edge cases are handled: 'forming bars, different resolutions, missing bars, and retrieval failures are reported as quality conditions.' This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose is first, behavioral caveats second, and usage prerequisite last. Every sentence contributes distinct, needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, side effects, quality reporting, and usage prerequisites, which is strong given the parameter schema. The only notable gap is that there is no output schema and the description does not describe the shape of the returned aligned data, so an agent still has some uncertainty about the exact response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents count, chart_indexes, and max_missing_ratio. The description adds context about prerequisites and quality conditions but does not meaningfully extend parameter-level semantics beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Align'), resource ('closed OHLCV bars already loaded in two or more TradingView layout charts'), and a precise criterion ('exact UTC timestamps'). This clearly differentiates the tool from data-loading siblings like get_ohlcv and load_more_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite: 'Use a layout where each required market is already open.' It also implies data must already be loaded and that forward-filling will not happen, which shapes when this tool is appropriate. It does not explicitly name alternatives or list when-not-to-use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It explicitly discloses that the overlay does not fetch or infer CFTC data, orders, stops, or execution flow, and that COT values are supplied externally. This is meaningful transparency beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences with no filler. The main action and resource are front-loaded, followed by a precise behavioral clarification. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema template tool, this description is nearly complete: it names the artifact, its inputs, and what it excludes. The only minor gap is not explicitly stating the return format, but the name and description strongly imply a Pine Script overlay.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to document. The description adds useful context by clarifying that COT values are explicit inputs to the overlay rather than tool parameters the caller must pass to this MCP call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('audited Pine overlay'), and clearly defines what the overlay renders: a supplied COT crowding context plus the chart's prior daily structure range. This differentiates it from siblings like get_cot_crowding_unwind_context, which fetches context, and get_analysis_overlay_template, which is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: use this when you have a COT crowding context to supply and need the corresponding Pine overlay. It does not explicitly name alternatives or state when not to use it, but the boundary between this tool and data-fetching tools is implied well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and discharges it exceptionally well. It discloses that the operation is read-only and point-in-time, that the result explicitly reports missing data, request-time timestamps, and quality status, that it never emits a trade instruction, and the subtle data-quality caveat that TradingView scanner values lack a common source timestamp so intraday timing is partial-quality evidence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with zero filler: purpose is front-loaded in sentence one, output behavior and exclusions in sentence two, and the data-quality caveat in sentence three. Every sentence earns its place and the total length is appropriate for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description covers the essential behavioral surface: what data is fetched, what the result reports, what it does not do, and the quality limitation. It stops short of enumerating the exact response structure, which would further reduce uncertainty for an agent, but this is a minor gap alongside the highly informative input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 high-level framing by grouping parameters into target vs. auxiliary symbols and 'optional economic events' and stressing that the overview and fields are 'shared', but it provides no per-parameter detail beyond what the schema already states. It reinforces the schema's semantics without meaningfully extending them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Build a read-only, point-in-time market data snapshot' that 'fetches quotes and a shared multi-timeframe overview' plus optional economic events. This composite scope clearly differentiates it from siblings such as get_quotes (quotes only), get_mtf_overview (overview only), and get_economic_events (events only). The phrase 'does not produce a trade instruction' further separates it from decision-oriented siblings like get_trade_decision_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use context ('for environment analysis') and an explicit exclusion ('it does not produce a trade instruction'), which helps an agent avoid misusing it as a decision tool. However, it does not name concrete alternative tools or spell out the when-not conditions beyond the trade-instruction exclusion, so the routing guidance stops short of explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden. It discloses that the template is audited, that marks and alerts are gated on bar close, and that nothing appears intrabar and then disappears. This adds meaningful behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, followed by a key behavioral guarantee, then a concise usage workflow. Every sentence earns its place and there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter template retrieval, the description covers what the template does, its behavioral guarantees, and the expected next steps. It does not explicitly state the exact return format, but the reference to save_pine_script implies the template is a script object, so no critical gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies because the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('audited Pine template') and states exactly what the template marks: pin bars, engulfing bars, and 20-bar sweeps. It also distinguishes itself from the sibling get_price_action_context by explicitly naming that tool as the later consumption step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear workflow: save it with save_pine_script, add it once with add_pine_to_chart, then use get_price_action_context. This tells an agent when this tool fits in a sequence, though it does not explicitly state when not to use it or compare it to alternative template getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It adds useful context: the data comes from TradingView's scanner API, no chart interaction occurs, default columns are specified, and the meaning of the 'Recommend.All' rating is explained with its range and interpretation. It does not cover response shape or rate limits, but it discloses the key operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 action, resource, and key constraint; the second explains defaults and column extensibility. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provides a reasonable high-level picture of what is returned and how to customize it. It covers the required symbols format via the schema, default columns, and rating meaning. Minor gaps like exact response structure and limits are either in the schema or not critical for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 beyond the schema by providing concrete examples of supported columns ('MACD.macd', 'EMA50', 'price_earnings_ttm'), clarifying the default column set, and explaining the semantics of 'Recommend.All'. This helps agents form valid requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('current quotes and technical data for specific symbols'), and the method ('TradingView's scanner API'). It also explicitly notes 'no chart interaction', which distinguishes it from chart-related sibling tools like get_chart_context and get_chart_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when current quotes and technical data for specified symbols are needed, and explicitly excludes chart interaction. It does not name sibling alternatives or provide when-not-to-use conditions, but the stated scope is enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly discloses the read-only nature ('This is read-only') and explicitly lists the actions it does not perform. This is strong transparency for a status tool, though it doesn't mention edge cases like whether a replay must be active or what happens if none is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and object are front-loaded, and the list of included state elements adds precision without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description still tells the agent what data will be available (state, binding, cursor time, resolution) and confirms non-mutating behavior. It could add a note about return format or preconditions, but for a simple read-only status tool the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter documentation. The description logically covers what state is read, which serves as implicit context for why no parameters are needed. Per the baseline for 0 parameters, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with a clear resource: 'current TradingView Bar Replay state', and enumerates exactly what is read (active chart binding, historical cursor time, replay resolution). It also explicitly states what it does NOT do ('never starts, advances, or stops replay trading'), which clearly differentiates it from sibling tools like start_chart_replay, step_chart_replay, and stop_chart_replay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to inspect the current replay state rather than mutate it. By stating it 'never starts, advances, or stops' replay, it signals that this is not the tool for controlling replay. It does not name alternatives explicitly, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it delivers: 'Read-only' declares the safety profile, 'user's own saved' restricts scope, and the usedBy cross-referencing behavior is disclosed. For a zero-parameter list operation, the key behavioral traits are covered, though details like pagination or empty-result behavior are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: the first states purpose and return payload, the second routes to the downstream consumer, the third declares safety. The main purpose is front-loaded and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 carries the burden of explaining return values (pine_id, kind, version, usedBy), and it also covers scope and safety. For a simple, parameterless list tool the definition is complete enough, though it doesn't mention potential pagination limits or behavior when the user has no saved scripts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object with zero parameters, so the baseline of 4 applies. There are no parameter semantics to clarify; the description instead uses the space to explain what the output contains, which is the more relevant information for this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (List), resource (user's own saved Pine scripts), and the exact return fields (pine_id, kind, version, usedBy). The chart cross-reference detail ('usedBy shows which on-chart indicators are rendered from each script') makes the purpose precise and naturally distinguishes it from siblings like get_pine_source or save_pine_script.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to find the pine_id for get_pine_source' gives an explicit, concrete use case and routes the agent to the downstream sibling that consumes this tool's output. It provides clear context but stops short of explicit when-not-to-use guidance or named alternatives to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden and does so well. It explicitly reveals verification against list_pine_scripts and the hidden Pine id, fail-closed behavior on symbol/timeframe mismatch, and the confirm=true requirement before any removal. This gives an agent critical safety-relevant behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no filler. The main action and ownership constraint are front-loaded, followed by safety mechanisms. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description covers the essential safety context: ownership verification, fail-closed guards, and confirmation requirement. It does not describe return values or preview output details, but those are less critical than the removal safeguards and the description is strong enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully explains confirm as the removal gate, pine_id as the user's own verified id, study_id as related to the study's hidden Pine id, and expected_symbol/expected_timeframe as guards that must match current chart context. chart_index is only implicitly covered by 'one on-chart instance', but overall the description adds substantial parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the specific action: preview or remove one on-chart instance of the user's own saved Pine script. It differentiates itself from sibling tools like add_pine_to_chart, save_pine_script, and list_pine_scripts by emphasizing ownership verification and chart-scoped removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to preview or remove an owned saved Pine script from a chart, with confirm=true required for actual removal. It does not explicitly name sibling alternatives or state when not to use it, but the ownership and chart-context guardrails make the intended scenario clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses that the Pine source is untouched, that changes are live chart edits persisting until reset, that TradingView layout autosave may capture them, and that strategy backtests recalculate. This gives an agent accurate expectations about side effects without relying on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver action, side-effect transparency, use case, and follow-up guidance with no filler. Key scoping ('Pine source untouched') is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong for a mutating tool: it covers scope, persistence, autosave caveat, strategy workflow, and restoration. It does not describe the return value or failure behavior, and with no output schema that small gap keeps it just shy of complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions already explain study_id, inputs, and chart_index with examples and source hints. The description adds overall workflow context but not additional per-parameter semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Change input values of an indicator or strategy already on a chart,' and immediately labels itself 'the write counterpart to get_indicator_inputs,' making the read/write distinction explicit. This clearly differentiates it from sibling tools like get_indicator_inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case ('A/B-test parameters without re-saving the script each time') and says to restore original values when done. It also notes the strategy-specific follow-up with get_strategy_report. However, it does not explicitly name an alternative like save_pine_script for cases where permanent source changes are needed, though 'Pine source is untouched' implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral burden. It discloses side effects and safeguards: every temporary Strategy is removed, the chart fingerprint is checked before continuing, and results explicitly exclude ranking, adoption, fabricated fills, and orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the purpose, then describe the execution flow, then cover safety and result content. There is no filler and no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 13-parameter tool with no output schema and no annotations, the description covers the execution lifecycle, scenario taxonomy, cleanup behavior, and result summary. It omits exact output structure and some required parameter semantics, but the schema names and constraints fill much of that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It adds meaning for scenario kinds, bootstrap, confirm, and rerun overrides, but it does not explain required parameters like protocol_id, expected_symbol, expected_timeframe, evaluation range, minimum_trades, or top-level inputs. Significant value added, but a clear gap remains for several required params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation: 'Run bounded robustness tests' on 'one exact saved Pine strategy,' with explicit scenario types and result exclusions. This clearly distinguishes it from sibling tools like run_backtest or run_strategy_experiment by emphasizing non-adopting, bounded stress testing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear invocation workflow: dry-run preview first, then confirm=true to execute, with a limit of eight rerun input-override scenarios. It does not explicitly name alternative tools or when-not-to-use conditions, so it stops just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 behavioral traits: it uses the latest version, is additive only, never removes or replaces existing studies, and the user can remove the study from the chart UI. This is strong, though it does not mention persistence, error behavior, or whether adding the same script twice creates duplicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and resource. Every sentence adds value: the purpose, the additive-only guarantee, the manual removal path, and the strategy alternative. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple side-effecting tool with no output schema and fully documented parameters, this description covers purpose, scope, side-effect safety, and the primary alternative. An agent has enough context to invoke it correctly and understand the consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have meaningful descriptions: pine_id is 'Script id from list_pine_scripts' and chart_index is a chart index defaulting to the active chart. The tool description adds little parameter-specific detail beyond implying the script must be user-owned and saved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Add one of the user's OWN saved Pine scripts (latest version) to a TradingView chart as a study.' It clearly distinguishes this from siblings by restricting scope to user-owned scripts and emphasizing additive-only behavior, which contrasts with remove_owned_study and run_backtest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: after save_pine_script, to show an improved indicator. It also gives a clear when-not and alternative: 'For strategies prefer run_backtest, which cleans up after itself.' This is direct, actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though no annotations are provided, the description carries the full behavioral burden and does so thoroughly. It discloses the read-only default, the temporary timeframe change with restoration, explicit reporting of restoration failures, and the non-guessing policy for same-bar ordering, gaps, and incomplete history. This is genuinely informative beyond any structured annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: the core purpose appears first, followed by scoping constraints, edge-case handling, and side-effect behavior. Every sentence contributes a distinct constraint or behavioral guarantee, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers many edge cases and side effects, which is valuable for a tool with no output schema. However, it never states what the evaluation actually returns—e.g., an outcome label, a confidence level, or a structured result object. It says results are 'reported as ambiguous or incomplete' and that restoration failures are 'returned explicitly,' but the return contract remains underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, so the description does not need to compensate entirely, but it adds real value for evaluation_timeframe by explaining that it temporarily changes only the selected chart, captures evidence, and restores afterward. It also ties expected_timeframe to verification semantics. A few parameters like chart_index remain unelaborated, but their meaning is reasonably inferable from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Evaluate') and names a precise resource: 'the first confirmed Target-versus-Stop outcome of an audited Bushido Analysis Overlay.' It clearly delimits the scope with constraints like 'only loaded, closed OHLCV bars after the analysis time' and distinguishes itself from batch or status tools like evaluate_due_analyses by focusing on a single overlay's first confirmed outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when this tool applies: after an analysis, with loaded closed bars, and excluding forming bars. It gives an explicit exclusion for calendar-month charts. It does not name alternative sibling tools, so the routing is implied rather than stated, but the prerequisites and non-evaluable cases are concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It explains what the tool returns, including the format for indicators and the fact that the id is consumable by get_indicator_* tools. It implies a read-only state inspection without side effects, which is clear enough for this tool type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the core purpose and output contents; the second adds practical guidance. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully covers what an agent needs: what the tool returns, the shape of indicator entries, and when to invoke it. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so no parameter explanation is needed. The description correctly focuses on output meaning rather than parameter details. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('current TradingView layout state'), and enumerates exactly what is included: symbol, timeframe, active indicators as {id, name}, and active chart. This makes the tool's purpose immediately clear and distinguishable from sibling tools like get_chart_screenshot or get_ohlcv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first to know what the user is looking at,' providing a clear usage cue. It does not explicitly name alternative tools or exclusion conditions, but for a state-introspection 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It reveals the data source ('official U.S. Treasury 10-year par real yield'), the update cadence ('latest', 'end-of-day'), and the meaningful point-in-time behavior ('read only locally persisted versions first seen by that time'). It does not describe failure modes or whether network access occurs, but the output schema reduces the need to spell out return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words, with the core purpose front-loaded. The second sentence adds a crucial usage boundary, and the third sentence explains the one optional parameter. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter, no required parameters, and an output schema, so the behavioral burden is small. The description covers what the tool returns, its cadence, its macro-context role, and the as_of semantics. An agent has enough to decide when to call it and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents as_of fully with format and a clear description, and schema coverage is 100%. The description adds value by clarifying that as_of reads 'only locally persisted versions first seen by that time,' which refines the schema's 'point-in-time cutoff' phrasing with concrete semantics. This extra nuance justifies moving above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a precise resource ('U.S. Treasury 10-year par real yield'), and a clear scope ('latest official'). It also states that this is end-of-day macro context, not an intraday trigger, which separates it from the many chart/intraday/context siblings. This is specific enough for an agent to distinguish it from tools like get_policy_rate_context or get_market_snapshot without opening their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it for macro-level real-yield context at end-of-day frequency, and do not treat it as an intraday trigger. It also explains the optional as_of behavior. However, it does not explicitly name alternative sibling tools or give an exclusion such as 'if you need the policy rate, use get_policy_rate_context instead,' so it falls just short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 a failure mode (no strategy on chart), a data-format nuance (percent-style fields are fractions), and the chart-bound dependency. It does not cover authentication or stale-report freshness, but the critical operational behaviors are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: core purpose and content, fraction formatting caveat, and failure/alternative. The purpose is front-loaded, and each sentence adds necessary operational information without fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter read tool with no output schema and no annotations, the description provides all needed context: what is read, what metrics are included, the fraction convention, the failure condition, and the fallback tool. An agent can safely invoke this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for trades_limit; the schema already documents the maximum, minimum, and default. The description's 'most recent trades' phrasing aligns with this parameter but adds no new semantic information beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and resource ('backtest report of the strategy currently on the active TradingView chart'), and enumerates the exact contents (net profit, win rate, profit factor, drawdown, Sharpe/Sortino, most recent trades with entry/exit details). This clearly differentiates it from siblings like run_backtest or get_strategy_trade_ledger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when this tool is appropriate ('currently on the active TradingView chart') and provides an exclusion/alternative: 'Fails if no strategy is on the chart — use run_backtest to test a saved strategy without leaving it on the chart.' This gives the agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and covers meaningful behavioral traits: the template is audited, limited to a completed exchange-trading day, exposes only prior POC/VAH/VAL as readable plots, and makes no claim about Bid/Ask flow or institutional activity. It doesn't discuss side effects or return format, but the 'get template' nature and follow-up save/add instructions make the expected behavior clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry the resource identity, scope limitation, caveat, and a concise step-by-step usage path without fluff. The key discriminator ('audited Pine template' and 'prior POC, VAH and VAL') is front-loaded before the workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter template getter with no output schema, the description is complete: it states what the template contains, what it deliberately does not contain, how to install it, and how to consume it afterward. No critical missing information is needed for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema covers 100% of them, so there are no parameter semantics for the description to clarify. The baseline for no parameters is 4, and the description adds no conflicting or additional parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: it retrieves an audited Pine template for a prior day's volume allocation profile, naming exactly which values (POC, VAH, VAL) are exposed. It also differentiates itself from related tools by explicitly stating it does not claim order-flow or institutional-activity data, so an agent can distinguish it from get_volume_profile_context and other template tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage workflow: save with save_pine_script, add once with add_pine_to_chart, then use get_volume_profile_context. It implies the tool is the setup step before the context tool and its caveat about order flow tells the agent when not to rely on it, though it does not explicitly name an alternative for Bid/Ask order flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It discloses that the tool uses the logged-in session, which is an important dependency, and it describes the return output in terms of watchlist names, symbols, and section-header grouping. A 'Get' verb implies a read operation; it does not detail failure modes, but for a simple zero-parameter read this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states what the tool does and what it returns; the second adds the important session dependency. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description is complete: it tells the agent what data is returned (watchlist names, symbols, section-grouped) and the key runtime prerequisite (logged-in session). No output schema is provided, but the description covers the essential return structure well enough for an agent to decide whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and the input schema is empty, so there is no parameter semantics for the description to add. The zero-parameter baseline of 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the exact resource (user's TradingView watchlists), and explains what is included (names, symbols, grouped by section headers). This clearly differentiates it from the many sibling market-data and analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that this tool is for retrieving the current user's watchlists and that it relies on the app's logged-in session, which is a useful prerequisite. It does not explicitly name alternatives or say when not to use it, but no sibling tool appears to target watchlists, so the usage context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states the tool is read-only and does not create, modify, restart, or delete alerts, which is essential safety-relevant behavior for an agent. It does not discuss authentication, rate limits, or return format details, but for a zero-parameter listing tool the key behavioral trait is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary purpose is front-loaded, key output fields are listed, and the exclusion of mutation behavior is stated explicitly in the second sentence. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only list tool with no output schema, the description is complete: it specifies what is listed, what fields are returned, and what side effects the tool does not have. Nothing an agent needs to safely invoke this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema contains no properties, so there is no parameter documentation burden. The description provides context about what the returned list contains, which is useful semantic information even though it relates to output rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('List'), the specific resource ('the user's TradingView price alerts'), and the scope of returned data (symbol, condition, active state, last fire time). It also explicitly differentiates itself from mutation operations by stating it does not create, modify, restart, or delete alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes this as a read-only listing tool and explicitly excludes mutation operations, which helps an agent know when not to use it. However, it does not name any alternative tool for creating or modifying alerts, such as the sibling create_analysis_alerts, so the routing guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 well. It discloses that the strategy is temporarily applied, that the tool waits for the Strategy Tester report, that the report has the same shape as get_strategy_report, that the strategy is removed afterward to leave the chart unchanged, and that keep_on_chart overrides cleanup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet efficient: the first sentence covers action, scope, workflow, return shape, and cleanup; the second covers the prerequisite; the third covers companion tools. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, referencing get_strategy_report's shape is valuable and sufficient. The description also covers prerequisites (list_pine_scripts), optional persistence (keep_on_chart), cleanup behavior, and how to extend to other symbols/timeframes. Nothing critical for calling the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all three parameters, including the pine_id format and trades_limit bounds. The description reinforces keep_on_chart's meaning and the source of pine_id, adding modest context, but it does not substantially extend parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Backtest'), a specific resource ('the user's OWN saved strategies'), and a precise scope ('active chart's current symbol and timeframe'). It also references get_strategy_report's shape, which helps the agent understand what this tool produces and how it relates to a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit guidance on where to get valid strategy IDs ('Get strategy pine_ids ... from list_pine_scripts') and how to test other markets ('Combine with set_symbol/set_timeframe'). It does not explicitly contrast this tool with run_backtest_matrix or run_strategy_walk_forward, but it provides clear context for the common workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses that the target pane is read back and failures are rolled back, which is meaningful for a mutating tool. It does not mention permissions or persistence, but the core side effects are sufficiently transparent for this simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the core action front-loaded, useful examples, and no redundant filler. Every clause contributes either to scope, parameter behavior, or failure handling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutating tool with no output schema, the description is complete: it specifies what changes, acceptable symbol formats, how to target a pane, the default behavior, and the rollback guarantee. 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.
Parameters4/5
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 value by giving real symbol format examples and clarifying that chart_index selects a pane in multi-chart layouts with the active chart as default. This goes beyond the bare schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Change one TradingView chart to a different symbol.' It gives concrete symbol format examples ('BTCUSD', 'OANDA:EURUSD', 'NASDAQ:AAPL') and is clearly distinct from sibling set_timeframe, which changes a different chart property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains chart_index usage and the default behavior for the active chart, giving an agent enough context to invoke the tool correctly. It does not explicitly name alternatives or exclusions, but the operation is unambiguous and no competing sibling performs the same symbol-change task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so excellently. It discloses side effects (temporary chart changes, recording results, restoration), the conditional nature of those effects, and failure semantics: 'Individual failures do not stop the batch; a chart restoration failure stops all remaining work.' This is transparent and actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, execution flow, and failure handling. It is front-loaded with the core action and avoids redundant restatement of schema details. No filler or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description covers the essential behavior, side effects, and failure modes. It states what preview returns (candidates and estimated chart changes) and what execution does (records results and restores charts). It does not describe the return format after execution or prerequisites like having a chart selected, but the schema covers parameter details, making this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 86%, so the baseline is already 3. The description adds real semantic value beyond the schema by explaining that confirm=true is what triggers chart mutation and result recording, tying the parameter to observable behavior. It does not cover all parameters, but the schema already documents most of them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Preview or evaluate due analyses directly from the local analysis journal.' It clearly distinguishes two modes—preview without confirm and execution with confirm—so an agent understands exactly what the tool does and can tell it apart from analysis-retrieval and study-runner siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use each mode: 'Without confirm=true it only lists candidates and estimated chart changes' vs. 'With confirmation it temporarily changes...'. It does not name alternative sibling tools or explicitly state when not to use it, but the preview/confirm distinction serves as clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses critical behavior: normalization of spread and tick/pip units, rejection of crossed quotes and delayed data, and the readiness condition (only ready after a streaming bid/ask change). It also explicitly states it does not access accounts or place orders. This is rich, non-obvious behavioral context that an agent could not infer from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: what it observes, critical filtering/normalization behaviors, and explicit exclusions. The most important scoping ('read-only', 'one or more symbols') is front-loaded. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only observation tool with 4 parameters and no output schema, the description covers the key behavioral guarantees (data quality checks, readiness condition, no account access). It could have mentioned what the return value looks like (e.g., aggregated bid/ask per symbol) since there is no output schema, but the readiness semantics effectively inform the agent what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description adds context around timing parameters ('polling interval while waiting for an update', 'how long to poll for a post-request bid/ask change'). The main parameter 'symbols' has pattern constraints in the schema but the description adds the semantic that these are scanner symbols. Coverage is good, but the description could have clarified the units/meaning of max_quote_age_ms beyond 'chart lp_time'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Observe') and resource ('read-only TradingView scanner bid/ask conditions for one or more symbols'), clearly distinguishing itself from order-execution or account tools. It even states what it does not do ('does not access accounts or create, modify, or execute orders'), which eliminates ambiguity and reinforces its read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool for observing scanner bid/ask conditions and explicitly says it is read-only, which signals against using it for trading actions. It names no direct alternative among siblings, but the contrast with execution tools is implicit. It does not state explicit exclusions like 'use get_quotes for ...', so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries full responsibility for behavioral disclosure. It discloses what is included (level-named plots, horizontal lines, box/zone edges, label prices), what is excluded (oscillator panes, generic OHLC mirrors), that results are tagged with source indicator, and that output is sorted by distance from current price. This is rich, specific behavioral context beyond a bare 'get' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four purposeful sentences, each earning its place: scope definition with examples, explicit exclusions, ordering behavior, and usage guidance versus alternatives. The most decision-relevant information is front-loaded, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey output nature. It does: levels are tagged with source indicator and sorted by distance. It also covers inclusion criteria, exclusions, and the alternative approach. Minor gaps remain, such as not explicitly stating the return type (e.g., array/table) or behavior when no levels are found, but for a read-only aggregation tool this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with individual parameter descriptions already present, so the baseline is 3. The description adds conceptual context like 'near the current price' for range_percent and clarifies what 'level-named' means (relevant to include_all_plots), but it does not add syntax, formatting, or behavior details that go substantially beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb ('Aggregate') and a specific resource ('key price levels near the current price from ALL price-scale indicators'), and further details what counts as a level (S/R, pivot, VWAP, bands, BOS/CHoCH, horizontal lines, box/zone edges, label prices). It also explicitly contrasts this with manually combining get_indicator_values and get_indicator_graphics, making the tool's purpose unmistakable among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence directly prescribes the use case: 'Use this instead of manually combining get_indicator_values and get_indicator_graphics when you need a support/resistance table.' This is an explicit when-to-use statement that names the alternative approach it replaces. The exclusion of oscillator panes and generic value plots further clarifies what the tool is optimized for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does it well: it discloses fail-closed verification of source/placement/symbol/timeframe, refusal of Confirm On Bar Close off due to mutable signals, reporting of departures in settings/qualityIssues, and the meaning of 0 on unconfirmed bars. This is substantial transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then essential caveats; no filler or repetition of schema patterns. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only context tool with no output schema and no annotations, the description covers invocation semantics, failure behavior, and a key return-value nuance (0 on unconfirmed bars). Minor omissions are the response shape and the optional chart_index parameter, but these do not prevent correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, but the description adds meaning to all required parameters by mapping pine_id/study_id/expected_symbol/expected_timeframe to 'saved source, study placement, symbol and timeframe' and explaining they are verified fail-closed. It does not explain the optional chart_index, but the required-parameter semantics are significantly enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Read'), a precise resource ('latest bar's pin-bar, engulfing and sweep readings'), and a strict scope ('only from the exact audited Bushido Price Action Context Pine template'). This clearly differentiates it from get_price_action_context_template and run_price_action_pattern_study by stating it reads existing audited readings rather than returning a template or running a study.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for reading from the exact audited template and emphasizes fail-closed verification, which tells an agent when this tool is appropriate: when audited price-action readings are needed. It does not name sibling alternatives explicitly, but the 'only from' constraint and refusal of non-conforming studies provide clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it does so exceptionally. It reveals that zero lag is refused, horizons count subsequent observed bars so weekends do not void daily series, label correctness belongs to the caller, signal-bar close is not an assumed fill, and the tool never ranks labels, changes the chart, or places orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence carries specific operational information. The core purpose is front-loaded, and the subsequent caveats about lag, horizons, timeframes, and side effects are all necessary for correct invocation. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with no annotations and no output schema, the description provides strong contextual grounding around the data join, lag behavior, timeframe support, and non-effects. It is not fully complete because it never describes the return shape or how fold/journal/confidence configurations interact, and some required quantitative parameters are left to inference. Still, it is far above the minimum viable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description must compensate. It does add real meaning for the central concepts: observation lag, horizons, labels, and accepted label directions. However, required parameters such as target_return_bps, minimum_events, folds, and journal settings receive little or no descriptive help, and expected_symbol/expected_timeframe matching against the active chart is implied rather than stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Measure forward outcomes for caller-supplied point-in-time labels on the active chart', giving a specific verb, resource, and input type. It also explicitly distinguishes itself from run_market_event_study by noting daily/weekly timeframe support, so an agent can tell which tool is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the intended use case: testing external series such as open interest, settlement statistics, or survey data with the same machinery as built-in conditions. It directly names the main alternative, run_market_event_study, and explains the differentiator that this tool accepts daily and weekly timeframes, effectively providing 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds: 'Never places orders,' 'Without confirm=true this only previews the plan,' 'Selection uses train metrics only; only the selected candidate's test metrics are exposed,' and the explicit list of failure conditions that are 'not silently ignored' are all material disclosures beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six short sentences, each adding unique information. The main purpose is front-loaded, and there is no filler or tautology; even the list of failure conditions is compressed into one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 12-parameter tool with no output schema and no annotations, the description covers the execution model, preview behavior, data source, and safety profile. Remaining gaps are minor: no explicit guidance on mode, expected symbol/timeframe, or alternative tool routing, though the schema partially fills those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds meaning to core required parameters: candidates are 'exact saved strategy/input candidates collected serially,' folds are explicit partitions with train/embargo/test windows, and confirm controls preview versus execution. It does not explain anchored vs rolling mode or expected_symbol/timeframe, so it is not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Run a bounded Pine Strategy walk-forward evaluation from full, immutable trade ledgers.' It further differentiates the tool by describing candidate collection, train/embargo/test partitioning, and selection semantics, making it clearly distinct from the many backtest and experiment siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: bounded walk-forward evaluation using exact saved candidates and explicit train/embargo/test folds. It does not explicitly name alternatives or state 'use run_backtest instead,' so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that no recorded overlap means unknown rather than unused or approved OOS, that declared-unused assertions are user-supplied and cannot prove unused status, and that the tool has no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences, each earning its place: scope, negative-result semantics, and side-effect clarification. There is no filler, no repetition of schema patterns, and the most important distinguishing information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong given the absence of annotations and output schema, covering behavior, parameter semantics, and limitations. However, terms like 'journal' and 'OOS' are unexplained domain jargon, and the description does not specify the result shape beyond implying overlap findings, which matters more without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by defining the UTC half-open interval [from,to), the search key series_id across data versions, and the meaning of a declared-unused assertion. The optional prior_usage_declaration parameter is not named explicitly, but its semantics are clearly captured by the explanation that a declared-unused assertion is user supplied and cannot prove unused status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('Check recorded research data usage for a UTC interval [from,to)') and states the exact search scope: overlapping use of the same stable series_id across all research IDs and data versions. It also distinguishes the tool from the recording sibling by explicitly saying it does not record an access or reserve a period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a read-only lookup and explicitly states what the tool does not do ('Does not record an access or reserve a period'), which implies when not to use it. However, it does not name the alternative tool such as record_research_period_usage or provide an explicit 'use this when...' condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states 'Read-only,' which is the most important behavioral trait for this zero-parameter getter. It also clarifies that the returned source is meant for a one-time setup, adding useful lifecycle context beyond a bare 'get template' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the resource, its content, its read-only nature, and the entire setup workflow without wasted words. The key identifying information is front-loaded, and the follow-up tool references earn their place by preventing misuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter template getter with no output schema, the description is complete: it explains what the tool returns, that it is read-only, and how the returned value should be used across the intended Pine overlay lifecycle. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema description coverage is 100%, so there are no parameter semantics to document. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the return value and downstream usage rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('audited generic Pine overlay'), and the overlay's purpose: rendering a structured market analysis with entry zone, confirmation, invalidation, stop, targets, confidence, and expiry. It clearly distinguishes this tool as the template-getter in the Pine overlay workflow, separate from save_pine_script, add_pine_to_chart, and apply_analysis_overlay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines the intended workflow: pass the returned source to save_pine_script, add_pine_to_chart once, and use apply_analysis_overlay for subsequent analyses. This gives the agent clear when-to-use and when-not-to-use guidance, including the correct alternative for updating existing studies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full behavioral burden. It explicitly discloses that the tool makes no network request and exposes no credentials, and 'Read' signals a non-mutating operation; the source limitation adds further behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences: the first names the operation and its safety properties, the second scopes the data source. Every sentence contributes essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter local readiness check with no output schema, the description is complete: it states what is read, the scope of data, and the key safety/reliability characteristics. The word 'whether' adequately conveys the expected boolean-like return without needing an explicit output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to elaborate; per the zero-parameter baseline this is a 4. The description's focus on local/no-network behavior complements rather than needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Read') and resource ('whether the local OANDA retail-flow collector is configured'), clearly stating what the tool reports. It also distinguishes the source from market-wide order flow, separating it from related sibling flow/context tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: a local configuration check that avoids network calls and credential exposure. It does not explicitly name sibling alternatives or state when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 that the ledger is stable and paginated, that pages fail closed if the strategy recalculates, that certain fields are returned only when TradingView exposes them, and that the operation is read-only with an active-strategy prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose stated first, followed by pagination behavior and prerequisites. Every sentence earns its place without redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated read tool with no output schema and no annotations, the description covers the essential context: what data is returned, how to paginate, consistency guarantees, and the active-strategy requirement. No critical information an agent would need 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful behavioral context beyond the schema: it explains the intended pagination flow of offset and expected_ledger_id, including the fail-closed behavior on recalculation. This goes beyond merely restating parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('stable, paginated ledger of every trade available in the active Strategy Tester report'), making the tool's function immediately clear. It also distinguishes itself from related sibling tools like get_strategy_report and summarize_backtest_ledger by focusing on the trade-level ledger rather than summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit pagination guidance: start with offset 0 and pass the returned ledgerId as expected_ledger_id on later pages. It also states the prerequisite of an active strategy and confirms the operation is read-only, giving clear context for when to call it, though it does not explicitly name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the entire burden, and it does so thoroughly. It discloses the append-only nature, idempotent retries for the same access_id, conflict failure, the exact interval semantics [from,to), the requirement for confirm:true, and the absence of side effects like chart access, orders, or file paths.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense. Each sentence adds necessary context: the core purpose, required confirmation, key parameter guidance, interval semantics, idempotency behavior, and explicit non-goals. It is front-loaded with the primary action and avoids redundant restatements of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 required parameters and no output schema, the description is complete enough for an agent to understand what this tool does, what side effects it has, what constraints apply, and how it differs from journaling or validation workflows. The mention of idempotency and conflict failures covers the practical outcome expectations, and the explicit non-goals prevent misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description-level parameter explanation is essential. The description explains series_id stability, data_version as a content hash, confirm:true, the [from,to) interval, purpose, accessed_at, and access_id idempotency. It does not explicitly define research_id, but most critical parameters gain meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Record a user-reported research data access in a local append-only journal.' It clearly identifies the resource and behavior, and it is distinct from related siblings like check_research_period_usage or validate_research_protocol because it emphasizes the write/record nature and the journaling behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: this is for user-reported data access recording, requires confirm:true, and has explicit exclusions such as 'No chart access, orders or file paths.' It also clarifies what the tool is not for ('not preregistration or proof of an unused OOS period'). However, it does not explicitly name sibling alternatives or state when to prefer one over another, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so excellently. It discloses the 24-job cap, soft runtime budget, temporary strategy add/remove lifecycle, full-ledger SHA-256 id binding, chart-state restoration, handling of failures/insufficient samples, non-ranking of results, confirm-gated execution, and that it never places orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each dense with critical operational information. The main purpose is front-loaded, and the safety-related behavior ('never places orders', 'confirm=true') is positioned where it matters. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex matrix execution tool with no output schema and no annotations, the description covers execution planning, confirmation semantics, safety (no orders), state restoration, job bounds, runtime limits, and result-row behavior. An agent has enough to decide whether and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already high at 83%, so the baseline is 3. The description adds meaningful meaning on top by explaining job lifecycle semantics, the confirm execution-plan gate, the soft runtime budget, and the meaning of insufficient samples relative to minimum_trades. This goes beyond the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run') and a precise resource ('a bounded, serial matrix of saved Pine strategies across explicit symbol, timeframe, and input combinations'). This clearly distinguishes it from single-run tools like run_backtest, and the matrix framing is unique among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: when running multiple saved Pine strategy jobs across explicit combinations. It also explains the confirm=true gate and the non-order-placing behavior, but it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it does so thoroughly. It explains that strategies are temporarily added, resolved to exact saved Pine versions, applied serially, bound to full-ledger ids, removed after collection, and that the tool never places orders. This gives an agent a clear safety and side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler. It front-loads the core purpose, then provides constraints, cleanup behavior, output characteristics, preview semantics, and a critical safety guarantee. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description adequately covers outputs ('Returns metric deltas without a synthetic score'), execution requirements, cleanup, and the confirm prerequisite. The tool is complex with nested objects, but the description gives enough context for an agent to understand what happens and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds meaning beyond the schema by explaining baseline-versus-candidate semantics, optional input overrides, exact saved Pine version resolution, and the confirm gate. It does not fully describe every parameter, but it enriches the less-documented nested baseline/candidate objects and the overall experimental flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run one bounded baseline-versus-candidate Strategy Tester experiment on the active chart.' It clearly distinguishes this tool from siblings like run_backtest or run_strategy_walk_forward by emphasizing the comparison structure, boundedness, and absence of a synthetic score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, especially the preview-versus-execute distinction: 'Without confirm=true it only previews the experiment.' It also gives safety guidance by stating 'It never places orders.' It does not explicitly name sibling alternatives or when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so exceptionally. It explicitly discloses read-only behavior, bounded execution, as-of join without forward-fill, no assumed fill at signal-bar close, explicit exclusions, and states it never changes charts, ranks parameters, or places orders.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with no filler. The opening sentence front-loads the core purpose and safety profile, and each subsequent sentence adds distinct value: event logic, join and output semantics, fill reference, and side-effect guarantees.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (25 parameters, no output schema, no annotations), the description is unusually complete. It explains the study mechanics, the optional gate variants, the join behavior, the returned metrics, and the tool's non-mutating guarantees, giving an agent enough context to invoke it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 24%, and no output schema is present, so the description must compensate. It supplies essential semantics for many required parameters by defining the driver impulse, signal-bar close timing, as-of join behavior, optional third-chart gate, and the output metrics. It does not enumerate every parameter, but the conceptual model it provides is substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Run a bounded, read-only cross-asset event study over two exact TradingView charts." It further distinguishes itself by naming the nonconfirmation logic, optional DXY gate, and the fact that it is a study rather than a chart-mutating action, which separates it from the many sibling event-study tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate: when analyzing a driver impulse against a target nonconfirmation with an optional regime gate. It does not name sibling tools or explicitly state when not to use it, but the event pattern and read-only bounded study framing give an agent enough context to select it over unrelated tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and succeeds. It explains PF recomputation, baseline/subset/complement outputs, filter selection semantics, missing outcomes, research_id journal side effects, usage_access_id idempotency, recording failure behavior, and the exact scope of call counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded and dense: core action and filters appear first, then requirements, outputs, and side-effect caveats. A few phrases are minimally redundant, but no sentence is filler for a tool this complex.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema and no annotations, this is remarkably complete. It covers prerequisites, return populations, cost semantics, limitations, and side effects, so an agent can invoke it correctly and interpret results without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every schema parameter is effectively explained in prose: artifact_id, round_trip_cost_bps, symbol filters, direction, from/to inclusivity, group_by values, research_id, and usage_access_id. This is especially valuable because the schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb+resource: 'Summarize a locally registered immutable backtest ledger by SHA-256 artifact ID.' This clearly distinguishes the tool from siblings like get_strategy_trade_ledger and compare_research_evidence, and the filtering/grouping details further pin down its exact function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides solid invocation context: requires the evidence to be locally registered via the import CLI first, requires an explicit round-trip cost, and states what the tool does not do or guarantee. It doesn't explicitly name alternative tools for other use cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it delivers: it discloses the dry-run behavior, non-destructive design, versioning semantics, compile-error reporting with line numbers, and the fact that a version is stored even on compile failure. This goes far beyond a typical tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It front-loads the single most important fact (write tool with confirm flow) and then layers mode details, versioning, error behavior, and a workflow example without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers what an agent needs: the write path, the dry-run path, error behavior, version retention, and the recommended surrounding workflow. It is sufficiently complete for correct invocation and user-facing behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaning above the schema: confirm defaults to false and is required for actual writes, name is needed for new scripts while pine_id targets an existing script for a new version, and older versions remain retrievable. This helps the agent understand the relationship between parameters and side effects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Save Pine source to the user's script library.' It explicitly marks itself as 'the ONLY write tool' and distinguishes the two modes of operation (new script vs new version), making it easy to differentiate from read-oriented siblings like get_pine_source and list_pine_scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The confirm-flow is clearly explained: call once without confirm=true to get a dry-run preview, then call again with confirm=true only after user approval. It also gives explicit guidance on when to omit pine_id (new script) versus provide it (new version), and even provides a typical PDCA loop: get_pine_source -> edit -> save_pine_script -> run_backtest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

TradingView-MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![TradingView-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/tedorigawa001/TradingView-MCP/badges/card.svg)](https://glama.ai/mcp/servers/tedorigawa001/TradingView-MCP)

Score Badge

Copy to your README.md:

[![TradingView-MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/tedorigawa001/TradingView-MCP/badges/score.svg)](https://glama.ai/mcp/servers/tedorigawa001/TradingView-MCP)