POKT Agent tools

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's job is narrower. It adds real context: the two accepted input shapes (TradingView 'List of trades' CSV vs JSON trade list), that commission settings are applied during recomputation, and that output is a per-metric MATCH/MISMATCH verdict. It does not say what happens if no input is supplied, but nothing contradicts the annotations.

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

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

A single dense sentence with the action and inputs front-loaded and the output contract at the end. Every clause carries information, though it reads as a run-on that could be split for scanning.

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

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

With no output schema, the description correctly states the return shape (per-metric MATCH/MISMATCH), which is what an agent most needs. The remaining omission is the meaning/role of initial_capital and the expected structure of the trades array, both of which are left to inference.

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

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

Schema coverage is 60% and the description partially compensates: it clarifies that drawdown is closed-trade only, that commission settings affect the math, and that trades_csv is specifically the TradingView Strategy Tester export. However, initial_capital is never mentioned and the trades array items are untyped, so gaps remain.

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

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

States a specific verb+resource: recompute four named metrics (net profit, win rate, profit factor, closed-trade drawdown) from a TradingView CSV or JSON trade list, then label each claimed metric MATCH/MISMATCH. The sibling set (pine_lint, pine_integrity, kr_*) is in unrelated domains, so no differentiation is needed.

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

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

The reconciliation framing implies the use case (verifying claimed backtest metrics against raw trades), but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool. Guidance is inferable rather than stated.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description adds useful behavioral context about the output: it labels stale values as STALE and returns the corrected value and filing. However, it says nothing about the scope of the correction lookup, latency, or how withdrawals differ from corrections in the response.

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

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

It is a single dense sentence with the scope ('For a Korean listed company') front-loaded, and no filler. The nested parenthetical and question framing make it slightly harder to parse than necessary.

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

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

For a five-parameter tool with no output schema and only partial schema coverage, the description should clarify which inputs are required and what the result looks like. It hints at STALE labeling but leaves parameter usage and return shape largely unexplained.

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

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

Schema coverage is only 40% across five parameters, and the description does not name or explain any of them. It is unclear from the text whether the tool takes a company (corp/corp_code), a report text, a date (since), or specific filing numbers (rcept_nos), so the description fails to compensate for the coverage gap.

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

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

The description states a specific analytical task: identifying cited DART filings that were later corrected or withdrawn, and flagging values that equal a corrected value as STALE. That distinguishes it from siblings like dart_events (event listing) and kr_figure_check (figure verification), though the question-style phrasing is convoluted.

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

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

There is no guidance on when to use this tool versus dart_events, kr_figure_check, or backtest_reconcile, and no indication of prerequisites such as needing a corp identifier or an existing report. Usage must be inferred entirely from the one-line purpose.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful domain behavior: that corrections are linked to originals with before/after values and that a point-in-time view is available. It still omits return shape, pagination, and result-size limits, so it is a solid but partial addition.

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

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

Two short sentences with no filler, and the resource scope is front-loaded before the language note. The colon-list packs several distinct capabilities into one clause without padding.

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

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

With no output schema and three totally undocumented parameters, the description should carry more weight than it does — it never explains what a returned disclosure record contains or how the natural-language question maps to results. It is adequate for an agent to know the domain, but not enough to invoke confidently with date filters.

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

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

Schema description coverage is 0% for all three parameters. The description only hints that the input is a natural-language question in Korean or English; the 'since' and 'to' bounds are never explained as date filters, and no format or syntax guidance is given for any parameter.

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

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

Names a specific resource (Korean listed-company disclosures from OpenDART) and enumerates the content types it covers: filings, corrections with before/after values, point-in-time view. It does not, however, differentiate itself from the sibling dart_correction_impact, which the 'corrections linked to originals with before/after values' clause appears to overlap with.

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

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

The only guidance is 'Ask in Korean or English,' which is an input hint, not a when-to-use rule. Nothing says when to choose this over dart_correction_impact or kr_figure_check, and no exclusions or prerequisites (e.g. date range required, listed-company scope only) are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile and the fact that data comes from an external register are covered. The description adds the concrete source (MOLIT register) and the granularity of results (district/month, trends, single complexes), but says nothing about data freshness, the period covered, or response size.

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

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

One compact sentence plus a short input instruction; the domain and granularity are front-loaded and nothing is padded. It could be marginally more efficient by folding the language note into the same sentence.

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

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

For a single-parameter natural-language query tool with no output schema, the description covers the data domain, source, granularity, and input language. It still omits the historical coverage window, output shape, and any limits on the question, which an agent would want before committing a query.

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

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

With a single 'question' parameter at 0% schema description coverage, the description must carry the burden. It partially does: it signals a natural-language question, permits Korean or English, and enumerates the dimensions the question can address (district, month, trends, complexes). It does not clarify length limits, how ambiguity is resolved, or how to phrase multi-condition queries.

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

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

The description names a specific resource (Korean apartment sale prices), its source (the MOLIT real-transaction register), and its queryable dimensions (district, month, trends, single complexes). This is enough to distinguish it from sibling market-data tools like kr_fx, kr_rates, and kr_export_pulse, though no sibling is named explicitly.

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

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

The only guidance is the input hint 'Ask in Korean or English'; there is no statement of when to reach for this tool versus another, no prerequisites, and no exclusions. An agent must infer the use case entirely from the purpose statement.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: the data comes from Korea Customs Service and the totals are provisional (10-day, revised later), which affects how an agent should trust and present the numbers. It says nothing about update cadence beyond that or response format.

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

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

A single efficiently packed sentence with the source and scope front-loaded and no filler. It could be tightened slightly, but there is no wasted text.

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

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

This is a free-form natural-language query tool with no output schema and one uncommented parameter, so the description must carry the burden of explaining expected inputs and returns. It describes the data domain but not the answer shape (tables? single figures? charts?) or how to scope a question, leaving an agent under-informed about invocation.

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

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

Schema description coverage is 0% and the single 'question' parameter has no description in the schema. The description does not compensate — it never explains what form the question should take, whether HS codes, country names, or date ranges can be embedded, or what phrasing yields best results. Only the general topic list hints at acceptable subject matter.

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

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

Names the specific data domain (South Korea export statistics), the source agency, and the granularity (10-day provisional totals, HS code and country breakdowns), which clearly separates it from siblings like kr_apartment_trades, kr_fx, and kr_rates. It lacks an explicit verb (retrieve/query), but the resource is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternative tools for adjacent Korean economic data (kr_fx, kr_rates). The agent must infer from the data-domain sentence alone when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description usefully reveals that verification is against official sources (BOK base rate, KTB yields, DART filings) and distinguishes consolidated vs separate statements, but says nothing about tolerances, how mismatches are reported, or coverage limits.

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

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

A single front-loaded sentence: verb+resource first, then a compact enumeration of the specific checks. Dense but every clause carries domain information; only mild criticism is that the enumeration could be slightly better structured as a list.

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

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

No output schema exists, and the description never says what the check returns – a pass/fail verdict, a list of discrepancies, corrected values – which is central for a validation tool. The input side is reasonably covered, but the missing output behavior leaves a real gap.

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

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

Schema description coverage is only 25% (only as_of is documented). The description implicitly clarifies that corp refers to a listed company, year to a fiscal period, and the sources behind as_of, but it never explicitly maps any parameter, leaving half the semantics to inference.

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

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

States a specific verb ('check') plus the resource ('numbers in a Korean finance text') and names the authoritative sources (Bank of Korea, KTB, DART, KRW rates). The enumeration of checks (percent vs percentage point, 조/억, consolidated vs separate) makes the scope unmistakable and separates it from data-fetching siblings like kr_fx and kr_rates.

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

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

Usage is implied by the scope statement – verify figures in Korean finance prose – but there is no explicit when-to-use/when-not guidance or naming of alternative tools. An agent can infer the context but gets no routing help against siblings such as dart_events or kr_law_article.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-dependency profile is covered. The description usefully specifies that results are deal-basis plus telegraphic buying/selling rates, which tells the agent what the payload contains. It says nothing about freshness, default date behavior, or the upstream API's rate limits.

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

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

A single front-loaded sentence with no filler; the source and the data content are stated up front. It is arguably too terse for a data-retrieval tool, but nothing in it is wasted.

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

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

With no output schema and a half-documented parameter set, the description carries the burden of explaining defaults and return shape. It never says what happens with no arguments (both params optional), how the date is formatted, or whether results are a time series or a single snapshot.

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

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

Schema coverage is only 50%: ccy is documented as comma-separated ISO codes, but date has no description in the schema and none in the tool description either. With both parameters optional (0 required), the agent gets no explanation of what happens when date is omitted or what format date accepts.

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

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

The description names a specific resource (KRW exchange rates), its authoritative source (Export-Import Bank of Korea), and the exact rate types returned, so the agent knows precisely what data this yields. It does not distinguish itself from the sibling kr_rates, so an agent cannot tell from text alone which of the two rate tools to pick.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative (kr_rates) despite it being a sibling. The agent must infer selection purely from the resource name.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description still adds real behavioral value by disclosing the return content (verbatim article text, paragraph/item structure, promulgation and enforcement dates, official link) and by emphasizing 'quoted verbatim', which tells the agent the text is not summarized or paraphrased.

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

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

Two compact sentences: the return contents come first, the accepted input forms second. Every clause carries information and nothing is padded.

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

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

With no output schema, the description usefully characterizes the returned article and its metadata, and it fills the gap left by the undocumented `law` parameter. For a simple two-parameter lookup tool this is close to sufficient; it could be strengthened only by a short usage cue.

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

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

Schema coverage is only 50% (the `law` parameter has no schema description), so the description must compensate, and it does: it explains that `law` accepts official names, abbreviations such as 자본시장법, and common English names. The `no` parameter is already documented in the schema.

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

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

The description names a concrete resource (one article of a Korean statute) and states exactly what is returned: verbatim text with paragraphs and items, promulgation/enforcement dates, and the official link. The retrieval verb is implied rather than stated outright, but the scope is unambiguous and no sibling tool covers this domain.

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

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

There is no guidance on when to use this tool versus alternatives, nor any stated prerequisites or exclusions. The only hint at usage is that certain input name forms are accepted, which is an input concern rather than a when-to-use rule.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower, but the description adds only one behavioral detail — that each series carries its own observation date. With no output schema, there is no disclosure of units, staleness, holiday behavior, 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.

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

One front-loaded sentence with no filler; the long series list is the highest-value content because it defines coverage, and the trailing 'each with its observation date' delivers a key caveat in a single clause.

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

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

For a single-parameter read with no output schema, listing every returned series plus the observation-date caveat is nearly enough. It falls short only on units (percent vs. basis points), update frequency, and what happens on non-business days or future dates.

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

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

Schema description coverage is 100% and the single 'date' parameter already documents 'YYYY-MM-DD, default today'. The phrase 'on a date' in the description adds nothing beyond the schema, so the baseline 3 applies.

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

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

The description states a specific resource (official Korean interest rates on a date) and enumerates the exact series returned — BoK base rate, call, KOFR, CD, CP, MSB, KTB 1y-50y and spreads. That enumeration clearly separates it from siblings like kr_fx, though no sibling is named explicitly.

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

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

Usage is only implied: the enumeration of a full rate curve signals this is the tool for Korean won interest rates rather than FX or other data, but the description never says when to prefer it over kr_fx or how to interpret a partial curve. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the analytical basis of the checks and, notably, that the output includes 'what was not checked' — an unusually transparent statement about tool limitations that an agent needs when judging confidence in the verdict.

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

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

The purpose is front-loaded in the opening clause, and the body is a tight enumeration followed by a compact return-value sentence. The parenthetical aside about lookahead_on without offset is dense but earns its place as a concrete rule example; nothing is gratuitous.

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

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

With no output schema, the description correctly compensates by naming the return shape (verdict, findings with line and rule, and unchecked areas). Combined with the check taxonomy, an agent knows what it gets back. The only gap is the absence of guidance on interpreting or acting on the verdict relative to pine_lint.

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

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

Schema description coverage is 100% and there is a single required 'source' parameter already documented in the schema. The description adds no format or syntax guidance beyond that, so the baseline 3 for full schema coverage applies.

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

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

The description states a specific verb ('Check') plus resource ('TradingView Pine Script v5/v6') and enumerates the exact class of defect targeted: future data, unconfirmed HTF values, past-bar signals, realtime-only state, fill/cost assumptions, and alerts on unconfirmed bars. This scope is distinct enough from the sibling pine_lint (style/static linting) that an agent can disambiguate on the description alone.

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

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

The domain is clear — this is a backtest-fidelity/realism audit — but the description never explicitly states when to reach for it instead of pine_lint, nor any prerequisites (e.g. source must be complete/compilable). Usage is implied by the enumerated check list rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, non-mutating analysis call. The description adds the analysis scope (which classes of defects are detected), which is useful, but says nothing about what is emitted (errors vs warnings), severity levels, or whether linting can be partial.

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

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

A single front-loaded sentence with the verb and resource first, followed by a dense but informative list of checks. No filler sentences, though the trailing list is long enough to border on inventory-dumping.

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

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

For a read-only analyzer with no output schema, the description should convey what the caller receives (diagnostics, warnings, error list). It describes what is checked but not what comes back, which is the main remaining gap.

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

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

Only one parameter with 100% schema description coverage ('Pine Script source'), so the schema fully carries the parameter burden. The description adds no syntax or format guidance beyond the schema, which is the expected baseline at this coverage level.

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

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

States a specific verb (lint) and resource (TradingView Pine Script) and enumerates the concrete check categories it performs, so an agent knows exactly what analysis it runs. Sibling differentiation is weakened by 'plus all integrity checks', which overlaps with the pine_integrity sibling rather than drawing a boundary against it.

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

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

The enumerated checks imply the use case (validate Pine source before running it), and 'plus all integrity checks' hints that this tool is a superset of pine_integrity. However, it never explicitly says when to pick this over pine_integrity or what input conditions are required, leaving routing to inference.

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