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

No annotations exist, so the description carries the full burden. It discloses the key behavioral trait that it returns 'standards and base figures' rather than computed amounts, which prevents misuse. It stops short of describing data coverage, currency/validity year, or 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.

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

Three tight clauses: capability, example use cases, and the return-value caveat with handoff. Front-loads the resource definition and wastes nothing.

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, so the description must convey return nature, which it does by stating it returns standards and bases rather than amounts. It could say more about the structure or scope of the returned data, but it is sufficient for correct invocation.

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

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

Schema coverage is 100% and both parameters are already fully documented, including the enum mapping. The description's mention of the three categories and provincial scope mirrors the schema's own fields without adding syntax or format detail. Baseline 3 is appropriate.

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

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

States a specific resource ('分省赔偿标准与法定基数') with its scope split into three named categories (traffic, injury, personal injury). It explicitly contrasts itself against run_calculator, so an agent can distinguish it from that sibling without opening its schema.

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

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

Gives concrete when-to-use examples ('安徽十级伤残赔多少', '江苏工伤死亡赔多少') and names the follow-up tool explicitly: to compute actual amounts, use run_calculator. This routes the agent correctly across a two-step workflow instead of leaving the boundary implicit.

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

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

With no annotations, the description carries the full behavioral burden. It does usefully disclose the categories of content returned, which matters since there is no output schema. But it says nothing about read-only nature, source/authority, freshness, or limits of coverage, leaving notable gaps for an unannotated tool.

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

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

Two compact sentences: the first front-loads the returned content, the second immediately grounds it in example user questions. No filler, no redundancy with the schema field.

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 lookup with no output schema, the description adequately communicates scope and return categories, so an agent can judge relevance without opening anything else. It is only slightly thin on authority/source and boundary against neighbors like get_law_article.

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

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

Schema coverage is 100%: the single 'q' parameter already documents that full names, abbreviations, and colloquialisms (跑分) are accepted, and the description repeats rather than extends that. Baseline 3 applies when the schema does the heavy lifting and the description adds no new input semantics.

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

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

The description names a specific resource (罪名/criminal charges) and enumerates the four content types it returns: constitutive elements, sentencing tiers, filing-amount thresholds, and common Q&A. That is far more specific than a restated name. It does not, however, distinguish itself from siblings such as get_law_article, search_law, or kss_lookup that also cover legal content, so it stops short of a 5.

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

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

The clause '用于「盗窃罪判几年」「偷 3000 够不够立案」「帮信罪怎么构成」这类问题' gives concrete triggering question shapes, which is genuine when-to-use context. It offers no explicit exclusions or alternative tools for adjacent needs (e.g. article text vs. charge elements), so it is not a full 5.

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

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

With no annotations, the description carries the burden and does well: it discloses the return scope (target article only, plus one-sentence neighbor hints), and imposes a citation-integrity rule ('引用法条必须以本工具返回的原文为准，不得凭记忆编造条号或条文'). It still omits the response shape/pagination, so it is not fully exhaustive.

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

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

Three front-loaded sentences plus ★-marked rules; each clause earns its place (trigger, scope limit, anti-hallucination, slug sourcing). Slightly dense but no filler.

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

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

For a 3-param, no-annotation, no-output-schema tool, it covers the essentials: what is returned (article text + neighbor hints), when to call it, how to source the identifier, and the citation rule. Only the exact output formatting is left unspecified.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine cross-field meaning: slug must be the verbatim value from search_law's items[].slug, and slug takes precedence over law. This is dependency information the schema alone does not convey.

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: read the original text of a named law's specific article, plus a preceding/following article hint. It also declares the aggregating scope explicitly ('只回目标条，不整部下发'), which separates it from search_law/search_articles without needing the schema.

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

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

Gives a concrete trigger with examples ('用户给了条号时用，例如「民法典第 584 条」') and names search_law as the source of slug, implying the upstream step. It stops short of an explicit 'if the user gave no article number, use search_law instead' exclusion in the description (that lives only in the schema).

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals the returned content (address, navigation coordinates, region) and the fuzzy/province-browsing behavior, but says nothing about result limits, pagination, or completeness of the index — meaningful gaps for a lookup tool with zero annotation coverage.

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 clauses with zero filler: the first front-loads purpose, scope, and return fields; the second handles sibling differentiation. Every phrase earns its place.

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

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

With no output schema and no annotations, the description does disclose what the tool returns and its search modes, which is the critical missing piece. It remains slightly incomplete on result volume/pagination behavior, but for a 2-optional-param read-only lookup it is largely sufficient.

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

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

Schema description coverage is 100%, so both q and prov are already documented in the schema, including the example keywords. The description only restates the lookup axes (名称/属地) at a high level, adding no syntax, format, or interaction detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (查询), a concrete resource (全国看守所), the lookup keys (名称或属地), and the returned fields (地址、导航坐标、所属地区). It also explicitly distinguishes itself from the sibling sifa_lookup, so an agent can route between them without opening either schema.

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

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

The description names the alternative (sifa_lookup 的 kanshousuo) and states the distinguishing capability — dedicated index with fuzzy search and per-province browsing — which implies when to prefer it. It stops short of an explicit when-not rule or trigger phrasing, so it is clear context without full exclusion guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses the corpus size (56), the return content (each calculator's required fields), and the slug dependency for run_calculator, which is genuinely useful behavioral context. It does not mention pagination, output ordering, or auth, so it falls short of fully self-describing.

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 dense sentence for the inventory plus a starred routing instruction. The critical workflow guidance is front-loaded and no sentence 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, the description still tells the agent what the listing contains and why it matters (to get slugs for run_calculator), which covers the essential call path. It omits details such as result structure/pagination for a 56-item list, a minor 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 100% for the single q parameter, so the schema already documents the keyword filter and the return-all default. The description adds no filtering syntax or matching behavior beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource (list the site's 56 legal calculators) and enumerates the covered categories (litigation fees, compensation, penalties, child support, work injury, sentence credit). It also distinguishes itself from the sibling run_calculator by naming the slug handoff, so an agent can tell the two apart without opening either schema.

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

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

Explicitly prescribes the workflow: to perform a calculation, call this tool first to obtain the slug, then call run_calculator. This names the alternative tool and the condition that selects it, leaving nothing to inference.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses that the tool returns both a result and its legal basis. However, it says nothing about behavior on an invalid or unknown slug, whether args is optional, or any error handling — meaningful gaps for a tool with no annotation coverage.

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

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

Three compact sentences, front-loaded with the purpose, with the critical constraint flagged by a ★ marker for scannability. Nothing is obviously wasted, though the example list is slightly verbose.

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

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

Given no output schema, the description usefully notes it returns result plus legal basis and explains the cross-tool dependency on list_calculators. It is nearly complete for a calculator runner, lacking only failure-mode guidance.

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

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

Schema description coverage is 100%, and the description largely restates what the schema already documents (slug from list_calculators, args keys matching fields). It adds no syntax, format, or example key/value detail beyond the structured field descriptions.

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

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

The description states a specific verb+resource ('执行一个法律计算') and its output ('返回计算结果与依据'), then anchors it with concrete example queries (litigation fees, severance multiples, child support). An agent can distinguish this from lookup siblings like sifa_lookup or get_law_article at a glance.

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

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

It clearly states the prerequisite workflow: slug must come from list_calculators and args keys must match that tool's fields, plus example questions that show the applicable contexts. It stops short of explicit exclusions or naming which sibling to prefer for non-calculation queries.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the corpus scope, the exact fields returned, and the critical limitation that only 摘要+链接 are provided (no 正文), plus an instruction not to infer details from the summary. It does not cover permissions, rate limits, or pagination behavior, so it falls short of 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.

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

Front-loads what the tool is and what it returns before the usage rules, and the ★ markers make the two critical constraints skimmable. Slightly dense with bold emphasis and a repeated caveat about 摘要, but every sentence carries actionable information.

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

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

There is no output schema, so the description compensates by listing the returned fields and the no-full-text limitation, and it explains how the agent should use the results. Combined with the sibling routing rule, an agent has everything needed to call and apply this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters including the 'use keywords not whole sentences' guidance and the limit cap of 10. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource (检索本站原创法律文章), quantifies the corpus (~4,600 篇, 执业律师主笔), and enumerates what is returned (标题、摘要、栏目、发布日期、原文链接). It also names the sibling it is not (search_guides), so an agent can separate it from alternatives without opening a schema.

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

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

Gives explicit triggering conditions (用户问某个法律问题、想找分析或说法、问「有没有写过……」) and an explicit exclusion with the replacement tool: how-to/materials/steps/template queries go to search_guides. Nothing 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.

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

No annotations are provided, so the description carries the burden and largely meets it: it discloses the two-step call pattern, what the second step returns (摘要 + 小标题清单), and critically that 正文 is NOT returned. It does not discuss auth, rate limits, or pagination, so a small gap remains.

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

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

Front-loads what it does, then intent-based triggers, then the two-step mechanics, with no wasted clauses. The ★ markers and mixed parenthetical asides make it dense, but every sentence adds actionable content rather than 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 fully-documented parameters, the description supplies the missing return-value context (abstract + section skeleton, no body) and the two-call workflow. Nothing essential for correct invocation is absent, though it could say more about the shape of the entry list returned in step one.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining how q and key relate as a two-step workflow (先传 q 列条目，再回传 key) — information the schema documents per-parameter but not as a sequence. It also clarifies the empty-q behavior for each parameter's role.

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

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

States a specific verb (检索) and resource (本站「教程类」内容) and enumerates the seven content types it covers (办事指南、流程、证据清单、问答、判例、模板、合同), which lets an agent distinguish it in domain from search_articles/search_law. However, it never names a sibling tool, so differentiation is by content domain rather than explicit routing.

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

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

Gives explicit trigger phrases (「怎么办理、要带什么材料、走哪些步骤、有没有范本/清单、类似案子怎么判」), an explicit prioritization rule for procedural/material questions, and a default for the kind enum (不确定就用 guide). This is as actionable as usage guidance gets.

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

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

With no annotations, the description carries the behavioral burden, and it does add value: it discloses the corpus size (17,484 laws) and the category scope of the database, plus the exact fields returned. However, it says nothing about ordering, deduplication of similarly named laws, or how limiting/filtering behaves beyond the limit param, so meaningful behavioral gaps remain for an unannotated tool.

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

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

Front-loads the purpose and return payload, then the database scope, then the trigger and alternative. Every clause earns its place, though the parenthetical category list and corpus count make it slightly denser than strictly necessary.

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

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

There is no output schema, so the description must explain returns, and it does so concretely (name, abbreviation, category, status, dates, article count). Combined with the sibling routing, an agent has enough to call it correctly; only the absence of ordering/pagination behavior keeps it short of full completeness.

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

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

Schema description coverage is 100%, so q, cat, and limit are already fully documented in the schema, anchoring this at the 3 baseline. The description reinforces that the query should be a specific law name rather than a generic word, but adds no syntax or format detail beyond what the schema provides.

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

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

States a specific verb+resource ('locate which law in the legal database') and enumerates exactly what is returned (full name, abbreviation, category, validity status, dates, article count). It names the sibling get_law_article as the alternative for retrieving article text, so an agent can distinguish it from search_articles and get_law_article without opening any schema.

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

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

Explicitly states the trigger ('★用户提到具体法律名…或问哪部法规定的时用') and routes to the alternative ('要条文原文再调 get_law_article'). The when-to-use and when-to-use-something-else conditions are both spelled out, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden. It does disclose the return payload (名称、地址、电话) and implicitly signals a read-only lookup. It says nothing about authentication, rate limits, or what happens when no results are found, leaving real gaps for a no-annotation tool.

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

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

Front-loaded with the resource scope, followed by the return fields and concrete example queries. No sentence is wasted and nothing is buried.

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

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

For a simple filtered lookup with fully documented parameters and no output schema, the description supplies scope, return fields, and usage examples. Only the sibling overlap with kss_lookup and the empty-result behavior remain uncovered.

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

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

Schema description coverage is 100%, so the schema already documents q, cat, city, and limit including the enum label mapping. The description's enumeration of categories duplicates the enum rather than adding new meaning, 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 names a specific resource (全国司法资源) and enumerates the exact entity types covered (法院、检察院、看守所、监狱、司法鉴定机构、公证处), which maps to the cat enum. It is clear what the tool does. However, it never differentiates itself from the sibling kss_lookup, which likely overlaps on 看守所, leaving a real ambiguity for the agent.

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?

Two example queries (「XX 市看守所在哪」「XX 区法院地址电话」) imply the intended use context well. But there is no explicit when-not guidance and no mention of how this differs from kss_lookup or the other *_lookup siblings.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the nature of the content returned (site scale and channel map) and implies a read-only, zero-side-effect call, but says nothing about the structure of the output or how sections are enumerated. Adequate but thin for an unannotated tool.

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

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

Two short sentences with no filler: the resource identity and content come first, then the routing guidance. Every clause earns its place and the reader can stop after the first sentence if they only need to know what the tool does.

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

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

For a parameterless, annotation-free tool with no output schema, the description supplies both the purpose and a usable sketch of the return value (scale + section map), which is what an agent needs to decide to call it. Only the concrete shape of the overview content is left implicit.

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

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

The tool takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate, and the empty schema is self-explanatory. No additional parameter meaning is needed.

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 (site overview of wjorg.com) and states exactly what it returns: the site's scale and a map of its sections/columns. This distinguishes it from the operational siblings (search_articles, run_calculator, get_law_article), which all act on content rather than describing the site itself. It stops short of a crisp single verb, but the reader knows precisely what the tool produces.

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

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

Gives explicit triggering conditions: when the user asks 'what do you have' or 'what can you help me do', and whenever the agent needs to decide which tool to route to, call this first. That is clear context for use. It does not state an exclusion case or name a specific alternative to avoid, so it falls short of the 5 bar.

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