Thai Legal

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

Goes far beyond the annotations: quota accounting (1 per unique citation, max 50, min 1, deducted before the run), no refund on stopped_early, database outage yields cannot_verify while sections still get checked, non-Pro rejected before deduction, and the distinction between timeout errors (already charged) and queue errors (not charged). It even warns that not_found is not proof of a fake citation. Minor tension: idempotentHint=true while each re-run consumes quota again, but that is metering rather than resource mutation, so it is not a hard contradiction.

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 purpose, then the Pro gate, then the verify_citation alternative, then cost and result semantics in short line-per-idea blocks. It is long, and the enumeration of the 21 resolved law codes reads more like reference material than selection guidance, but nearly every line carries operational value for a high-stakes tool.

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

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

Given the complexity, an output schema, and quota consequences, the description covers everything an agent needs: which statuses exist and what each means, retry policy (retry only the individual item, never resend the whole document), truncation/nesting flags (unique_citation_limit_exceeded, stopped_early, extractor_capped), and a privacy warning on evidence_snippet.

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

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

There is a single required parameter and schema coverage is 100%; the schema already documents the 1–50,000 character bound and that empty/oversized input is rejected before the Pro check and before quota deduction. The description reinforces

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 (batch-audit every section/ruling citation in a single document) and lists the document types it applies to. It also draws a crisp line against the sibling verify_citation, so an agent can pick 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?

Explicit routing rules: single citation → verify_citation (any package, any law in the corpus); unresolved law name → call verify_citation yourself with a known law_code. It also states the Pro-only gate up front, so the agent knows when this tool will be rejected.

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

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

Annotations already cover read-only/idempotent/closed-world, but the description adds material context beyond them: no quota consumption, single-call full return with no pagination, and a documented degraded state (empty law_abbreviations + reason="temporarily_unavailable" means the deka service is down, not that no abbreviations exist). That last detail prevents a serious misreading of an empty result.

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 primary directive, then a compact per-kind routing table, then edge cases. Dense and mostly waste-free, though 'อ่านอย่างเดียว' partly restates the readOnlyHint annotation and the coverage/temporary-unavailable caveats are stated twice.

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?

An output schema exists so return shapes need not be described, and the description still covers the two things an agent cannot infer: what to do with each result set next, and how to interpret an empty or degraded response. Nothing needed for correct invocation is missing.

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

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

Schema coverage is 100% and the kind parameter is already well documented there, so the description need not repeat it. It still adds value by mapping each kind to the downstream call site and by explaining the ordering semantics (sorted by citation count) and the caveat that some law documents have no subject.

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

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

Opens with a specific verb+resource: fetch the actually-usable filter values and corpus statistics. It explicitly distinguishes itself from search_law and deka_by_section by positioning itself as the prerequisite lookup step rather than a search.

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 conditions ('call before search_law/deka_by_section when unsure which filter value to use', 'when the user asks about coverage') and names the exact alternative being avoided (guessing branch/type/abbreviation). Each kind is then routed to its downstream tool with argument syntax.

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

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

Beyond the annotations (which already declare read-only/idempotent), the description discloses quota policy (1 call per Pro-gated invocation, empty/`reason` results still charge quota, malformed input and section_format_unsupported do not), Pro entitlement gating with rejection without charge, result ordering (newest decision first), and a full error taxonomy with meanings. That is exactly the operational context annotations cannot carry.

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

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

Front-loaded with the two things an agent must know first (what it searches, and that it is Pro-gated), then organized by lookup mode, result shape, and error codes. It is dense and long, and the field-by-field enumeration of results overlaps with the existing output schema, but nearly every line carries semantics rather than 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 lookup tool with quota, entitlements, fallbacks and a rich error surface, nothing an agent needs is missing: quotas, refusal behavior, retry rules, ordering, match_level interpretation, and the critical caveat that count=0 is not proof of absence (plus the instruction to copy attribution/disclaimer verbatim). Return-value detail is redundant with the output schema but the semantic notes on matched_citations.origins and outcome_summary are not.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining cross-parameter behavior that the schema does not — that section is paired with law, that a section_not_found falls back to law-level results in the same call, and that law_requested/section_requested are echoes to compare against match_level before drawing conclusions. The number/section input formats largely restate the schema 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 first line names the exact resource (คำวินิจฉัยชี้ขาดอำนาจหน้าที่ระหว่างศาล) and the two lookup keys (ruling number, or law + section), and immediately excludes an adjacent use case ('ไม่ตอบว่าคดีหนึ่งต้องฟ้องศาลไหนจากข้อเท็จจริง') with a sibling pointer to search_law(corpus="court_ruling"). An agent can distinguish this from browse/search_law/verify_citation 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?

Explicit when-to-use (number vs law+section), explicit when-not (fact-pattern jurisdiction questions → search_law corpus="court_ruling"), and it even rules out needless retries ('section_not_found ... ไม่ต้องเรียกซ้ำ') while mandating retry in other cases ('law_not_found/ambiguous_law + candidates = เลือกชื่อแล้วเรียกซ้ำ').

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 read-only/idempotent/non-destructive, and the description adds substantial behavior beyond them: quota cost of 1 per call, no quota charged when the service is temporarily down (count=0 + reason), ambiguous_law / law_not_found / section_format_unsupported handling, and the important caveat that an empty result is not evidence of no precedent (incomplete corpus, best-effort related_laws).

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?

Purpose and sibling routing are front-loaded, then results shape, then error/edge-case bullets — a sensible order with high information density. It is long and dense (nested parentheticals, multiple bullet groups), which costs some scannability, but nearly every line carries operational meaning.

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

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

Despite an output schema being present, the description still spells out the result fields (no, year_be, verdict, department, doctitle), ordering (newest first), absence of full_text with a pointer to get_deka, and the verdict=None interpretation. Combined with the error-state taxonomy, an agent has everything needed to call and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds value by tying parameter outcomes to behaviors — abbreviated law names, names with vs. without พ.ศ. producing ambiguous_law, and section formats that are accepted vs. rejected (วรรค/อนุมาตรา → section_format_unsupported). Most of this is echoed in the schema text, so it is enrichment rather than new 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?

Starts with a concrete verb+resource: a list of Supreme Court judgments citing a given section, and explains the retrieval mechanism (citation-reference table extracted from judgments, more precise than keyword search). It explicitly distinguishes itself from search_law, get_deka, and verify_citation, so an agent can route 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?

Gives explicit when-to-use ("use when you already know the law name + section"), explicit when-not with a named alternative ("don't know the section / want fact-based search → search_law(corpus=\"deka\")", "know the deka number → get_deka", "check whether a judgment actually cites it → verify_citation"). The routing decision is fully determined.

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?

Goes well beyond the annotations: quota cost of one call per invocation, no quota deduction during service downtime, and precise meaning of found=False plus reason="temporarily_unavailable". It also warns that case-number-combined records must be checked manually and forbids concluding a judgment does not exist from found=False.

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 purpose and routing, then cleanly separated into an "อ่านผล" (reading the result) section. It runs long, but nearly every line carries operational meaning; a small amount of overlap with the schema's format note could be trimmed.

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

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

Even though an output schema exists, the description supplies the interpretation an agent actually needs: verdict=None is normal, appellant is the filing party or None, full_text is chunk-stitched with possible spacing loss at seams, and cited entries carry law_code usable with get_law_document. Privacy handling is flagged via deka_privacy_note.

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

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

Schema coverage is 100% and the schema already documents the "number/year BE" format, so heavy lifting is done structurally. The description adds provenance guidance (where the number comes from) and reinforces that the lookup is an exact match with no normalization, which is marginally useful beyond 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?

States a specific verb and resource: fetch one full Supreme Court judgment by its deka number, including the full facts/reasoning/judgment text. It explicitly distinguishes itself from search_law, deka_by_section, and verify_citation, so an agent can route 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?

Gives a positive precondition (you already know the number, from the user or from search_law/deka_by_section, and need the full text) and an explicit negative list routing to the correct siblings with the condition that selects each. 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?

Annotations already cover read-only/idempotent/non-destructive, but the description adds real operational context: quota cost of 1 per call including each page turn, 50 documents per page, the fact a single book/section can hold thousands of documents, the meaning of truncated=true, the available_categories fallback, and the deliberate PII masking of national IDs. None of that is recoverable from annotations or schema.

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

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

Purpose is front-loaded in the first clause and each subsequent line carries a distinct fact (alternatives, quota, page size, truncation, category fallback, PII). It is dense and slightly long, but no sentence is filler.

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

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

Covers everything an agent needs: when to call it, cost model, pagination mechanics, how to recover when the category is wrong, and the expected availability of an output schema for return shape. Nothing material is missing for a paged, quota-metered read tool.

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

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

Schema coverage is 100% so a 3 baseline is warranted, but the description goes further: it explains the offset/paging strategy, the category narrowing workflow, and the non-obvious mapping where 'พิเศษ' belongs in category while section takes only the number. That adds genuine meaning beyond the schema text.

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

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

States a specific verb+resource ('ดึงเอกสารเต็มจากราชกิจจานุเบกษา') and scopes it to corpus='gazette', then explicitly contrasts with get_law_document and get_deka for other document types. An agent can distinguish it from every sibling 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 an explicit trigger ('ใช้หลัง search_law เจอเอกสารราชกิจจาฯ แล้ว') and names the two alternatives with the condition that selects each (ตัวบทกฎหมาย → get_law_document, คำพิพากษา → get_deka). It also advises narrowing with category/no before paging, which is a concrete usage 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?

Beyond the readOnly/idempotent annotations, the description discloses the quota cost (1 call per invocation) and the guidance for partial results: full_text=None on long acts means choosing a section from section_index and calling again with unit_label. The remaining return-value notes (found=False, citation.unit_scope, law_freshness_note) are useful, but an output schema exists and likely repeats much of this field-level detail.

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 structure is strong and front-loaded: purpose first, then sibling routing, then result-reading bullets. The 'อ่านผล' block is comparatively long, but each bullet conveys a distinct recovery or interpretation step 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?

For a read-only three-parameter fetch tool with full schema coverage and an output schema, the definition covers prerequisites, alternatives, quota, and the failure/recovery path. What an agent needs in order to call it correctly and act on a partial result is present.

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

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

Schema coverage is 100%, and the schema already documents the 'มาตรา' prefix requirement, the whole-act default, and that timeline_code comes from get_law_versions. The description's mention of the three parameters adds only marginal meaning 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 first sentence states a specific verb and resource (fetch the full legal text by law_code), plus its two scoping options (whole act vs. a specific section, and selecting an amendment version). It is immediately distinguishable from search_law, get_gazette_document, get_deka, and verify_citation, which are all named.

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

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

It gives an explicit prerequisite (use after search_law yields a law_code) and routes to each alternative by condition: gazette documents go to get_gazette_document, supreme-court rulings to get_deka, and mere existence-checking of a cited section to verify_citation, which it notes returns a clearer status.

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 readOnly/idempotent/non-destructive, but the description adds quota information ('ไม่นับโควตา') that is not in the annotations, plus a non-obvious counting rule: only versions where the section appears in the main body are counted, so count=0 does not mean the content is absent. That said, it does not explain ordering guarantees beyond 'old→new' or whether is_current is always exactly one entry.

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 purpose, then usage, then a compact result-reading note separated by line breaks; no filler sentences. It is dense with parenthetical asides, which slightly slows scanning but each clause 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?

With an output schema present, the description need not restate the return shape, yet the count=0 caveat and the 'main body only' semantics are genuinely non-derivable from the schema and are exactly what prevents a wrong conclusion. Nothing an agent needs to interpret the result correctly is missing.

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

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

Schema coverage is 100% and both parameters are documented there, including the citation-derived provenance and the 'มาตรา'/'ข้อ' prefix requirement. The description only indirectly touches parameter meaning via the main-body restriction on unit_label matching, so 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 verb+resource: the list of all amendment versions of one section, ordered old→new, and explicitly frames the output as the timeline_code needed for get_law_document. It also distinguishes itself from search_law/get_law_document by noting those return the latest version by default.

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

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

Gives an explicit trigger condition (when historical wording in force at an earlier time is needed) plus the alternatives that default to the current text. It also names the correct follow-up path (verify_citation/get_law_document) when count=0, so the agent knows what to do next rather than retrying this tool.

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

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

Goes well beyond the readOnly/idempotent annotations: one quota unit per call regardless of sub-searches, up to ~60s runtime, limited concurrency, queue-full rejection that does not charge quota, and — critically — timeout errors that occur after quota is charged and are non-refundable, with advice to narrow the query. That is exactly the kind of non-obvious operational behavior an agent cannot infer from structured fields.

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?

Purpose and the sibling alternative are front-loaded, and the cost/caveat blocks are well-delimited with bullets. However the bulk of the text is return-value interpretation (case_law_by_section vs semantic, via/relation_origins, court_rulings_note) despite an output schema existing, making it long and dense for a 5-parameter tool.

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

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

Covers cost, latency, concurrency, partial-failure semantics, and the interpretive warnings that matter most — do not treat semantic matches as equal evidence, do not conclude 'none' when evidence_gaps.notes is populated, and only cite court rulings when the issue is jurisdictional. Nothing needed to call it correctly or to report results faithfully is missing.

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

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

Schema description coverage is 100%, and each top_k parameter is fully documented with defaults and maxima in the schema itself. The description adds no per-parameter meaning beyond the blanket statement that the dossier has no filters, 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 ('รวบรวม "สำนวนวิจัย" ของประเด็นเดียว') and enumerates exactly what the dossier bundles: statutes, Supreme Court judgments, and Council of State opinions. It also positions itself against named siblings — a shortcut replacing repeated search_law calls plus per-section deka_by_section — so the agent can distinguish it 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 names the alternative and the condition that selects it: use search_law instead when filtering by category/year/subject/law_type or when a single source is wanted, and notes the dossier has no filters and does not search the Royal Gazette. It also names case_law_by_semantic_search for non-core statutes, giving a full routing map.

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 read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely non-annotated context: quota costs 1 call per invocation, re-searching costs more quota, non-Pro court_ruling requests are rejected without consuming quota, and result fields like degraded_note, version_count, is_repealed and quota.notice must be interpreted and relayed to the user. Some of this duplicates the output schema, and the field-by-field reading guide is longer than the behavioral disclosure itself, so it sits at adequate rather than exemplary.

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 core purpose and quota cost in two short lines, then organizes the rest into a corpus list, an alternatives block, and a result-reading block. Dense but scannable; the result-reading section is the longest and partly restates output-schema fields, which costs some tightness.

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 9-parameter multi-corpus search, the description covers source scope, quota, plan gating, temporal/version caveats, privacy caveats, fallback routing, and even how to forward citation.law_code / section_no into downstream tools. An agent has everything needed to call it and to interpret and route the results correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds meaning the schema does not carry — that omitting corpus searches the first four sources and silently excludes court_ruling, and that law results may lag recently published amendments and must be checked against the official text. It also warns that a degraded_note mentioning partial steps means the agent must not conclude 'not found'.

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

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

Opens with a specific verb+resource: hybrid (semantic + keyword) search of Thai law across 4 source corpora, and explicitly frames itself as the starting point when the document number is unknown. It enumerates each corpus with what it contains, so an agent can tell exactly what this returns versus get_law_document or get_deka.

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?

Contains an explicit routing block ('use another tool instead when') naming four siblings — get_deka, deka_by_section, research_dossier, verify_citation — each with the condition that selects it. It also states when court_ruling is and is not searched by default and who is allowed to request it.

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?

Adds substantial behavior beyond the annotations: it records data for the team, does not count against quota, has per-user rate limits, and explains ok/reason/support_email/reply/duplicate outcomes. The description also warns against fabricated or softened reports and explains the duplicate flag.

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

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

The description is front-loaded with purpose and when-to-call rules, then structured into clear constraints and result behavior. It is longer than strictly necessary and repeats some `query` guidance already present in the schema, but the length is largely justified by the privacy and reporting requirements.

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

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

Given a five-parameter write tool with an output schema, the description covers the important gaps: auth requirement, reporting constraints, privacy redaction, rate limiting, duplicate detection, and failure reasons. Nothing essential for correct invocation appears missing.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description still adds meaningful semantics: include `query` only for search-result reports and omit it for quota/pricing/feature requests, and preserve the user's actual words in `message` while removing identifying details.

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 precise verb and resource: send the user's feedback/problem reports back to the Thai Legal team, and adds the prerequisite that the account must be connected. This is clearly distinct from the sibling search/research tools.

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

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

Gives an explicit ranked list of when to call, including direct user requests and confirmed reports of missing/wrong content. It also states a clear when-not rule: do not call merely because the user changes search terms or asks a new question.

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?

Goes well beyond the annotations: deterministic (non-AI) checking, one quota unit per call, rejection-before-quota-charge on invalid mode combos, no quota charge when the ruling service is down, and the important limitation that it does not judge the direction of a holding. Also flags privacy handling of full_text defendant names and warns that status values are not proof of non-existence.

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 purpose and alternatives in the first two paragraphs, then a scannable mode list and a result-reading list. It is dense and slightly long because the result-status block partly overlaps the output schema, but no line is filler.

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

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

Covers everything an agent needs for a 6-parameter, mode-switched verification tool: input modes, quota behavior, failure modes, how to read verified/not_found/cannot_verify, title_marked_repealed and unit_scope caveats, and the privacy note before reusing text.

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

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

Schema coverage is already 100%, so the schema carries per-field meaning; the description adds cross-parameter semantics the schema lacks, namely the two selectable modes and the rule that deka_no combines with cited_law/cited_section and/or quoted_text while law_code requires unit_label. It stops short of restating field-level formats, which is fine given 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?

Starts with a precise verb+resource: verify that one citation actually exists in the corpus, and states the motivating use case (checking before quoting a statute/ruling to a user). It also distinguishes itself from siblings by name: batch_citation_audit for multiple citations and get_deka/get_law_document when full text 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?

Explicitly says when to use it (before presenting a มาตรา/ฎีกา/quote to a user), and spells out the two mutually exclusive input modes with their required field pairings, warning that mixing modes or omitting paired fields is rejected. Alternatives are named with the condition that selects each (batch_citation_audit for multi-citation documents, get_deka/get_law_document for reading content).

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?

Despite annotations already declaring readOnlyHint/idempotent/destructive=false, the description adds genuinely non-structured behavior: it does not consume quota, and authenticated=False still returns support_email as a fallback. Those are the exact facts an agent needs to interpret a negative result without retrying or escalating.

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 outcome, then usage, then caveats — good ordering and no filler sentences. It loses a point for mild redundancy: 'ไม่นับโควตา' appears both as a quota redirect and again in the trailing characteristics list, and the parenthetical asides make the middle section denser than needed.

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?

An output schema exists and the tool has no inputs, so the description only had to cover purpose, routing and the negative-result semantics — all present. Nothing an agent needs in order to call this correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description instead documents the shape of the response (user_id + scopes), which is useful but sits outside this dimension's scope.

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 verb+resource: reports whether this connection is authenticated and which account, enumerating the returned fields (user_id, OAuth scopes, support_email). No sibling tool in the list touches identity/auth, and the description makes the boundary obvious.

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 triggers ('when the user asks whether the account connection is correct', or a permission/login error from another tool) and an explicit anti-trigger ('no need to call before using other tools, they check permissions themselves'). It also redirects quota questions to the quota field in counting tools' results, so an agent cannot route that question here by mistake.

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