Indian Legal MCP

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

With no annotations, the description carries the full burden and discloses rich behavioral details: it returns the corresponding section number, amendment status values ('Retained', 'Change', 'Deleted', 'New Section', 'New Sub-Section'), a mapping statement, and both full statutory texts. It does not discuss error handling or confirm the operation is read-only, but the conversion nature and extensive return description provide strong transparency.

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 return values in the first sentence, followed by six compact examples that illustrate edge cases (deleted sections, new provisions). The examples are informative and earn their place, though the description is longer than strictly necessary.

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

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

With no output schema, the description adequately explains return values and amendment statuses, and the examples demonstrate typical and edge-case outputs. It is nearly complete for an agent to call correctly, though it omits behavior for invalid act/section inputs.

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 act_code, section_number, and include_text. The description's examples reinforce valid act_code and section_number values but add no new semantic detail beyond what the schema provides; baseline 3 is appropriate.

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

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

States a specific verb (map/convert) and resource (criminal law sections) with clear scope: old IPC/CrPC/IEA to new BNS/BNSS/BSA in either direction. It distinguishes itself from sibling tools like get_section by focusing on inter-code mapping rather than simple retrieval.

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

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

Provides clear context through examples showing when to use it (e.g., converting an IPC section to its BNS equivalent, checking if a section was repealed). However, it does not explicitly name alternatives such as get_section or state when not to use this tool, keeping it below a 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 full behavioral burden, and it does disclose the return payload's most consequential element: whether the Act is still current law or has been repealed and replaced. It does not cover failure behavior for an unknown act_code or confirm the operation is a pure read, so it is good but not 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?

One front-loaded sentence that names the resource first and then the returned fields, with zero filler. Nothing could be cut without losing information.

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

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

For a single-parameter read tool with no output schema, the description covers both what goes in (an Act) and what comes back (name, year, repeal status). Handling of an invalid or unsupported act_code is the only meaningful omission.

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 parameter and schema description coverage is 100% – the schema already lists example codes and the count of supported Acts. The description adds no syntax, casing, or fallback detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get metadata about one specific Act') and enumerates what the metadata contains: full name, year enacted, and current/repealed status. This clearly separates it from list_acts and get_full_act, though it never names a sibling explicitly, 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?

Usage is only implied: an agent can infer this is the tool for looking up a single Act's metadata, and 'one specific Act' hints it is not the bulk-listing tool. There is no explicit when-to-use guidance, no statement of when to prefer resolve_act or get_full_act instead, and no prerequisites.

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 usefully discloses that output includes full text and that unsupported acts degrade to an informative message, but it omits pagination, response size, or rate-limit behavior for a potentially large chapter dump.

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

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

Front-loaded with the core purpose, then formats, then the edge case. The long list of act codes (BNS, BNSS, BSA, IPC...) is somewhat excessive and could be trimmed, but the structure remains efficient and each sentence adds usable information.

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

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

With no output schema, the description adequately explains the return ('every section... with full text') and covers the notable exception case. It is complete enough to invoke correctly, missing only finer details like output size or ordering.

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 both parameters and baseline is 3. The description adds genuine value by enumerating accepted chapter_number formats (Roman numeral, Arabic numeral, or title keywords) with concrete examples, which meaningfully expands on the schema's terse hint.

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 ('Get every section within one chapter (or Constitution Part) of an Act') and clarifies scope with 'full text.' This clearly distinguishes it from siblings like get_section, get_section_range, and get_full_act.

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

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

Provides clear context: which acts are supported and the accepted query formats. It also discloses a boundary case (CPC and MVA return an informative message). It stops short of explicitly naming when to prefer a sibling like get_section_range, so it is clear but not fully routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does signal that the return is complete text rather than a summary and pins the edition (2026), but says nothing about read-only nature, output format, size, or error behavior for invalid appendix numbers.

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 sentences, front-loaded with the action, and the enumeration of appendices earns its space by doubling as scope documentation. Dense but with 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 single-parameter, no-output-schema retrieval tool, the description covers purpose and valid values well. It is slightly thin on return format and failure behavior, but an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining what each accepted value ('I', 'II', 'III') actually refers to (100th Amendment/Land Boundary Agreement, J&K Order 2019/C.O. 272, Article 370(3) Declaration). That mapping genuinely helps an agent pick the right value.

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

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

The description gives a specific verb and resource ('Get the full text of an Appendix to the Constitution of India') and enumerates exactly what the three appendices contain, making scope unambiguous. It does not explicitly name the neighboring list_constitution_appendices or get_constitution_schedule tools, so sibling differentiation is implied ('full text' vs. listing) rather than stated.

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: fetch the appendix body given a number. There is no explicit statement of when to use this rather than list_constitution_appendices or get_constitution_schedule, and no preconditions (e.g., call the list tool first) are mentioned. Adequate but with a clear gap.

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 disclose what is returned ('full text and tables'), which implies a read-only fetch, but says nothing about return size, pagination, or permissions for potentially large Schedules, and there is no output schema to cover that gap.

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

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

The core purpose is front-loaded in the first sentence, and the examples are compact and readable. The '7' example largely restates the 'Seventh' example, which is a minor redundancy rather than waste.

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 tool with no output schema, the description covers what the tool returns and the full range of schedules. It omits any note on response size or how the returned Schedules relate to the appendices and schedule-listing siblings, which leaves an agent slightly under-informed.

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 parameter is already documented. The examples reinforce that '7' and 'Seventh' are equivalent ('Same as Seventh'), which is a small confirmation of the schema's claim rather than new syntax or constraint detail, so the baseline 3 holds.

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 ('Get the full text and tables of a specific Schedule of the Constitution of India') and bounds the scope ('all 12 Schedules'). This clearly separates it from the list-style sibling (list_constitution_schedules) and from get_constitution_appendix, though it never names those siblings 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 examples imply how the tool is called but never state when to use this tool versus list_constitution_schedules or get_constitution_appendix. There are no exclusions, prerequisites, or alternative-routing guidance, leaving usage 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 provided, the description carries the burden and does well: it discloses the pagination behavior (50 sections per page) and the graceful empty-sections-with-note response for out-of-range pages. It does not address permissions or anything beyond that, so it stops 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?

Three tight sentences with no filler: the core action comes first, then the usage constraint, then the edge-case behavior. Every sentence earns its place.

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

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

For a two-parameter read tool with no output schema and no annotations, the description covers action, chunking, and the out-of-range edge case. It could note that content is read-only or whether section text/IDs are included, but nothing critical to calling it is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully augments the 'page' parameter by stating the 50-sections-per-page chunk size, which the schema does not. That extra semantic detail on page sizing justifies the bump.

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 ('Get an entire Act, in full') and scopes it against whole-Act retrieval versus section-level tools, so it is distinguishable from siblings like get_section and get_section_range. It does not name an alternative explicitly, which keeps it just 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?

'Use only when genuinely needing the whole Act' gives clear when-to-use guidance and implicitly steers the agent toward the section-level siblings for narrower needs. No alternatives are named directly, so it's clear context rather than a full routing 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?

With no annotations, the description carries the burden and does disclose notable behavior: repealed acts (IPC, CRPC, IEA) return a note that they no longer apply to new cases along with their replacement, and section_number='0' returns the Preamble. It does not describe output shape, pagination, or behavior when a section number is not found.

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 prerequisite is front-loaded in a bracketed orchestration note, followed by the core action and examples. The ALL-CAPS bracketed preamble is slightly heavy for the payload, but every sentence contributes usage or behavioral information.

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

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

For a two-parameter read tool with no annotations or output schema, the description covers prerequisites, special cases (Preamble, repealed acts), and trigger scenarios adequately. It could say more about not-found behavior, but an agent has what it needs to call it correctly.

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

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

Schema description coverage is 100%, so both parameters already have documented formats and examples. The description reinforces semantics by tying act_code to real acts (BNS, IPC, COI) and restating the '0'/Preamble convention, but adds little beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource: retrieve the exact text of ONE section or Constitution article by number. It is clearly distinguished from siblings that handle ranges (get_section_range), keyword lookup (search_keyword), and cross-act mapping (convert_section).

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 prerequisite sequencing — use only after search_keyword has surfaced the exact section number, or when the user supplied it. It also gives concrete trigger phrasing ('what does BNS Section 103 say', 'show me IPC 302'), 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. It usefully discloses one non-obvious trait — reversed start/end are silently corrected and a note is added to the response — but says nothing about result size, what happens for nonexistent sections, or error behavior on an invalid act_code.

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 sentences, purpose front-loaded ahead of the edge-case behavior, with no filler or restatement of the title. Every clause adds 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?

Adequate for a simple read tool with 100% parameter coverage, but with no annotations and no output schema the description should cover return shape (does it include section numbers/titles?), pagination or size limits, and how missing sections are handled. Those gaps keep it at minimum viable.

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

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

Schema description coverage is 100%, so the baseline is 3; the description earns above baseline by specifying that the range is inclusive and that reversed inputs are tolerated, which the schema's bare 'e.g.' parameter descriptions do 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 and resource ('Get all sections between a start and end number') plus scope qualifiers ('inclusive', 'with full text'). This cleanly separates it from sibling get_section (single section) and list_sections (likely IDs only), though it never names those siblings 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?

No guidance on when to choose this over get_section, list_sections, or get_full_act. Usage is only implied by the name and the 'range' semantics; an agent must infer that this is the bulk-retrieval option and that act_code must already be resolved.

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 content type returned (procedural instructions, domain workflow, reference files) and the special _core payload, but says nothing about read-only semantics, permissions, or what a returned file looks like.

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

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

Three tightly packed sentences, the core purpose front-loaded, then the prerequisite, then the special-case value. Every sentence earns its place with 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 two-parameter read tool with no output schema and no annotations, the description covers purpose, sequencing, and the critical _core special case. It could be slightly stronger by describing the returned structure (workflow text vs. reference files), but nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning by explaining what skill_id='_core' retrieves, which the schema only lists as an opaque example. The file parameter's purpose is left to the schema, which already documents it fully.

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 ('Retrieve') and resource ('procedural instructions and domain reference files for a legal skill'), which is clearly disjoint from the act/section/constitution siblings. An agent can tell it apart from the other fifteen tools 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?

It gives explicit sequencing ('Call this tool after checking list_skills') that names the prerequisite tool and the condition for calling. It also carves out a special case, skill_id='_core', for global legal reasoning/citation rules, so the agent knows exactly when this tool is the right one.

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 return shape ('metadata and descriptions') and a scope fact ('Currently supports 102 official Acts of India'), which is useful for an agent judging completeness. It omits pagination/ordering behavior, a minor gap for a zero-parameter read-only list.

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 tight sentences with the action and scope front-loaded, then the purpose. Every clause earns its place with no redundancy.

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

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

For a simple no-param list tool with no output schema, the description adequately covers what is returned and how many items exist. The only minor omission is the exact metadata fields, which matters somewhat since no output schema documents them.

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 the baseline of 4 applies; there is no argument syntax for the description to explain.

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 ('List') and resource ('Acts in the database') and notes the payload ('with metadata and descriptions'). It is distinguishable from sibling list tools (list_sections, list_constitution_schedules), though it does not explicitly contrast with resolve_act or get_act_info which also relate to Act lookup.

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

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

Provides a clear use case: 'Use this to see which legal codes are supported or find short codes.' This gives context for discovery tasks, but it does not name alternatives (e.g., resolve_act) or state exclusions.

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

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

No annotations are provided, so the description bears the full disclosure burden. It does tell the agent that the result is a complete enumeration ('all 3') returning numbers and titles, which is useful, but it says nothing about read-only behavior, ordering, or response structure beyond that.

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 scope (all 3) and the returned fields (numbers and titles) both arrive immediately.

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 the important work of stating how many items come back and what each contains, which is sufficient for a zero-parameter listing call. The only gap is the absence of any read-only/safety framing, which is minor for an obvious lookup 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?

The tool takes zero parameters and the schema is trivially covered, so per the rubric this earns the baseline of 4. There is no parameter meaning the description could add.

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 gives a specific verb (List), resource (Appendices of the Constitution of India), and scope (all 3, with numbers and titles), which is far more precise than a bare 'list' label. It implicitly separates itself from the singular get_constitution_appendix sibling by being a listing operation, but it never explicitly names or contrasts with that sibling.

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

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

There is no statement of when to use this tool versus get_constitution_appendix or list_constitution_schedules, nor any prerequisites or exclusions. Usage is only inferable from the verb 'List' and the absence of parameters.

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, but for a zero-parameter enumeration tool the risk surface is minimal. It discloses the return shape (numbers and titles), which is the main behavioral fact an agent needs, yet says nothing about ordering, completeness guarantees, or that it is a pure read with no side effects.

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

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

A single front-loaded sentence with no filler, and every clause (count, subject, returned fields) earns its place.

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

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

Given zero parameters, no annotations, and no output schema, the description supplies the essential facts: the fixed count of 12, the collection, and what each entry contains. A brief note pointing to get_constitution_schedule for detail would make it fully complete.

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

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

The tool takes no parameters, so there is nothing for the description to explain beyond what the empty schema already conveys; baseline 4 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 (list) and resource (all 12 Schedules of the Constitution of India) plus the returned fields (numbers and titles). It is clearly distinct from the sibling get_constitution_schedule (singular lookup), though it never names that sibling explicitly to reinforce the 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?

Usage is only implied: the plural 'list all' versus the singular sibling get_constitution_schedule makes the enumeration-vs-detail split inferable, but the description never says when to use this instead of fetching a single schedule.

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

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

With no annotations, the description carries the behavioral burden and does so reasonably: it discloses the return shape (numbers and titles only, body text excluded) and the cost tradeoff versus get_full_act. It says nothing about pagination, ordering, or failure modes for an invalid act_code, which keeps it from a 5.

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

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

Two sentences, zero filler, with the scope constraint ('without the full body text') front-loaded before the usage guidance. Every clause earns its place.

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

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

No output schema exists, so the description must carry the return semantics, and it does by specifying section number and title only. Minor gaps remain on ordering, pagination, and behavior for unknown act codes.

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?

'in one Act' implies the single act_code selects exactly one Act, adding mild meaning. Schema coverage is 100% and the act_code description already supplies examples, so the baseline of 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?

Specific verb (list) plus resource (section numbers and titles within one Act) and an explicit scope limit ('without the full body text'). It also names the sibling it contrasts with (get_full_act), so an agent can distinguish it from the heavier fetch tools without reading 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?

Explicitly states when to use it: to browse what exists in an Act before deciding which section or chapter to fetch in full. It names get_full_act as the heavier alternative. It does not address the other listing siblings (list_acts, get_act_info) or state exclusions, so it stops just short of a full 5.

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

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

No annotations are provided, so the description carries the full burden, and it does a solid job: it discloses the exact shape of the returned registry and explains that the query keyword-matches against skill ID, title, trigger keywords, and act codes. It stops short of stating that the operation is non-mutating or what an empty/no-match result looks like.

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

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

Three sentences, zero filler: purpose first, return payload second, filter semantics third. Every clause carries information an agent needs and the front-loading is correct for a discovery 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?

With no output schema and no annotations, the description must explain return values and it does so thoroughly, plus it covers the single parameter's filter behavior. It is only slightly short of complete because it does not indicate result volume, ordering, or empty-result behavior.

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 than the schema by specifying the matching fields (ID, title, trigger keywords, act codes) rather than only giving example keywords. Minor inconsistency: the schema marks 'query' as required while the param description calls it optional, but that is a schema-internal issue.

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

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

The description states a specific verb and resource ('Discover... workflows', 'Returns the skills registry') and enumerates what the registry contains (skill IDs, titles, triggers, act codes, tool sequences, reference files). This clearly separates it from retrieval-style siblings like get_skill or search_keyword, though it never names an alternative 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: 'available in the system' suggests this is the entry-point discovery call before invoking a skill. There is no statement of when to prefer this over get_skill, search_keyword, or the list_* siblings, and 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?

No annotations are provided, so the description carries the full burden. It does disclose the return payload (compact list of act_code, official name, enactment year) and the token-optimization intent, which is valuable given there is no output schema. However, it says nothing about no-match behavior, result completeness, or error handling.

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 routing instruction is front-loaded in a bracket prefix, and the return shape follows immediately. The six examples are somewhat repetitive but do usefully illustrate the topic-to-code mapping behavior.

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 explains the return values and their compactness, which is the key missing structured information. It is nearly complete for a single-parameter resolver, lacking only failure/no-match semantics.

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 'query' parameter, so the schema already documents it. The description's examples ('environment', 'hindu', 'cheque') largely restate the schema's own examples and add no new syntax or format constraints, 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 ('find the exact act_code(s)') and explicitly names the sibling it replaces ('Use this instead of list_acts'). An agent can distinguish it from list_acts and search_keyword 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 routes the agent: use this instead of list_acts for resolving a topic/statute to act codes. The bracket prefix and the six worked examples make the intended call pattern unambiguous.

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

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

With no annotations, the description carries the full burden and does well: it discloses the ranking scheme (exact title #1, partial #2, body-text #3 via BM25), robustness to phrases/punctuation/citations, and dynamic suggestion of other Acts when a filtered Act yields no matches. It does not state return format, pagination, or result limits, so not quite full marks.

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

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

The bracketed orchestration directive is front-loaded and high-value, followed by search behavior and fallback semantics in tight sentences. The bracketed 'AI TOOL ORCHESTRATION INSTRUCTION' framing is slightly noisy but the content 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?

No output schema and no annotations, so the description must cover behavior, and it covers ranking and fallback logic well. It omits what a result contains (fields, snippets vs. full text) and any result-count limits, which would help an agent use the output 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, but the description adds meaning beyond the schema: the act_code filter's fallback behavior (dynamically detecting and suggesting other Acts when the filtered Act has no matching provisions) is not derivable from the schema. Query examples reinforce expected input shape.

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 ('Search section titles and text across all 102 Acts') and delimits scope by enumerating the covered codes. An agent can distinguish it from siblings like get_section (which requires a known identifier) without opening the schema.

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

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

The description gives an explicit, unconditional when-to-use rule ('ALWAYS use this tool FIRST when the specific section number is unknown. Never guess section numbers'), which is exactly the decision boundary that separates it from get_section/resolve_act. The condition that selects this tool is stated with no inference required.

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