Indian Legal MCP

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

No annotations exist, so the description carries the full disclosure burden. It does describe the returned payload (name, year, repealed/replaced status), which is genuinely useful given no output schema, but it says nothing about read-only nature, invalid act_code handling, or error behavior.

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 well-formed sentence that front-loads the action and resource and then lists the returned fields with zero filler or 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?

With no output schema and no annotations, the description compensates by naming the fields returned, which is the critical missing context for this tool. It stops short of complete behavioral coverage (error cases, source of repeal data), but covers what an agent needs to call and interpret it.

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 schema itself enumerates the valid act_code values, so the parameter is fully documented. The description adds only that the code identifies 'one specific Act', which is baseline-level and adds no syntax or format detail 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?

The description names a specific verb and resource ('Get metadata about one specific Act') and enumerates the returned fields (full name, year enacted, currency/repeal status). It is clearly distinct from list_acts and get_full_act in scope, 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?

Usage is implied by 'one specific Act' – the agent infers this is the lookup for a single act's metadata rather than a listing or full text. No explicit when-to-use guidance, prerequisites, or named alternatives (e.g., why not get_full_act) are provided.

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 that output is full text and that unsupported acts yield a clear message rather than empty data, which prevents misinterpretation. It stops short of describing the return shape or ordering, minor gaps for a read-only 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 sentences, zero filler, with the core behavior front-loaded and the fallback caveat immediately after. Everything 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, the description covers purpose, valid inputs, and failure behavior sufficiently. Only the exact return structure/ordering is unspecified, which is a minor omission rather than a blocker.

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 real meaning by constraining the act_code domain to six valid codes and by implying chapter_number is an Act-specific chapter identifier. That is useful guidance the schema examples ('BNS', '1') alone don't 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 every section within one chapter of an Act') plus scope ('with full text'). The chapter-level granularity cleanly distinguishes it from siblings like get_section, get_section_range, and get_full_act without needing to name them.

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 enumerates the acts where the tool is meaningful (BNS, BNSS, BSA, IPC, CRPC, IEA) and the acts where it is not (CPC, MVA, COI), with the fallback behavior defined. This is a genuine when-to-use / when-not-to-use statement.

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

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

No annotations are provided, so the description carries the full burden and does so well: it discloses the pagination scheme (50 sections/page) and the graceful empty-sections-with-note behavior for out-of-range pages, which an agent could not infer otherwise. It omits auth/permission requirements and whether the call is read-only, but 'Get' strongly implies a read.

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 core action and return shape before the usage caveat. No filler, though the edge-case sentence could be tightened slightly.

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 or annotations, the description supplies the essentials: return granularity, pagination size, and out-of-range behavior. It is sufficient for correct invocation, with only minor gaps around permissions and total-page discovery.

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%, setting a baseline of 3, but the description adds real meaning to the `page` parameter by stating the page size (50 sections) and what happens when a page exceeds the total. That is useful semantic context beyond the schema's 'page number to fetch.'

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 (Get) and resource (entire Act) with an explicit scope ('in full'), which cleanly separates it from siblings like get_section, get_chapter, and get_section_range. An agent can tell exactly what this returns 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?

Gives a clear negative condition: 'Use only when genuinely needing the whole Act,' implicitly routing to the more granular sibling tools. It does not name those alternatives explicitly, but the when-not guidance is 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?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: for repealed acts (IPC, CRPC, IEA), the result includes a note that it no longer applies to new cases and names the replacement. This is valuable context beyond the schema. It doesn't mention rate limits, auth, or error behavior, but for a read-only lookup tool, the repealed-act note is the most important behavioral disclosure. A 4 is appropriate because it adds meaningful behavioral context 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?

The description is a single paragraph with a clear front-loaded orchestration instruction, then the purpose, then examples, then the repealed-act note. Every sentence earns its place. The orchestration instruction is somewhat verbose with the ALL-CAPS framing, but it is functional and not redundant. A 4 because it is efficient but slightly heavy on the instruction framing.

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 2-parameter lookup tool with no output schema, the description covers the purpose, the prerequisite, the special case of repealed acts, and the Preamble case. It doesn't describe the return format, but with no output schema, that is a minor gap. The orchestration instruction and the repealed-act note make it complete enough for an agent to call it correctly. A 4 is appropriate.

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 with examples. The description adds the orchestration context (use after search_keyword) and the special case of '0' for Preamble, which is already in the schema. The description doesn't add much beyond the schema, but the schema is already strong. Baseline 3 is correct.

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 ('Get'), a specific resource ('exact text of ONE section or Constitution article'), and a clear scope ('by its number'). It also distinguishes itself from siblings by explicitly naming search_keyword as the prerequisite and giving concrete examples ('BNS Section 103', 'IPC 302'). This is a clear, specific purpose that an agent can act on.

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 explicitly says when to use this tool: 'AFTER you have found the exact section number via search_keyword, or if the user explicitly provided it.' It also gives examples of when someone would ask for a specific section. It does not explicitly name alternatives like get_section_range, but the orchestration instruction and the 'ONE section' scope make the usage boundary clear. The condition is explicit and actionable.

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 does disclose two non-obvious traits: numeric comparison that tolerates letter-suffixed identifiers ('108A') and silent auto-correction of reversed start/end with a note in the response. It stops short of stating the operation is read-only or describing result size/pagination behavior.

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, each earning its place: purpose first, then the letter-suffix comparison rule, then the reverse-order behavior. Front-loaded and free of 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 simple 3-parameter read tool with no output schema, the description covers the core operation and two boundary behaviors, and even alludes to a response note. Minor gaps remain around result scope and what act_code formats are accepted.

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 baseline is 3; the description adds real meaning by explaining that start/end are compared numerically and that reversed ordering is tolerated instead of erroring. It adds no detail on act_code, which the schema only illustrates with 'BNS'.

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 all sections between a start and end number (inclusive) with full text'), which implicitly separates it from the single-section sibling indian_legal_mcp_get_section and from get_chapter/get_full_act. It never names an alternative, so the differentiation is inferential rather than explicit.

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

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

There is no when-to-use or when-not-to-use guidance and no sibling is referenced, so an agent must decide on its own between this range tool and get_section/get_full_act/list_sections. The tolerance behaviors described are edge-case handling, not routing 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 that results include metadata and descriptions and implicitly that this is a read-only enumeration, but says nothing about result volume, ordering, or pagination for what may be a large list. For a zero-parameter read tool this is acceptable but thin.

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, front-loaded with the action and resource, followed immediately by the use case. No filler or 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?

With no output schema and no annotations, the description adequately covers what the tool returns (Act metadata and descriptions) and why to call it. Given the simplicity of a zero-param listing tool, only finer return-shape detail 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 no parameters, so the baseline is 4. There is no parameter syntax for the description to add, and it correctly avoids claiming any inputs such as filters that the schema does not support.

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 all available Acts in the database') and adds return content ('with metadata and descriptions'). It is distinguishable from the singular get_act_info/get_full_act siblings by being a discovery-level listing, though it does not explicitly name or contrast with them.

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 clear conditions for use: 'to see which legal codes are supported or find short codes,' which frames it as a discovery entry point before drilling into sections. It does not explicitly name alternatives (e.g. use get_act_info for a specific Act), so it stops short of full when/when-not 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 scope (numbers and titles only, not body text) and relative cost vs get_full_act, which is useful. It does not disclose return format (e.g., structure of the list), pagination, or whether it requires an exact act_code match. Adequate but not rich.

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 core purpose, then the usage context and contrast. 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 simple list tool with one fully documented parameter and no output schema, the description covers purpose, scope, and routing to alternatives. Slightly incomplete regarding return shape and error behavior, but 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 description coverage is 100%, and the single parameter act_code already documents format and examples ('BNS', 'MVA'). The description adds no extra parameter detail beyond what the schema provides, so baseline 3 is appropriate for a 1-param tool with full coverage.

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 (section numbers and titles in one Act), plus explicitly excludes body text. It is distinguishable from siblings like get_full_act and get_section, which the description names as complement/contrast.

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 frames when to use: 'browse what exists in an Act before deciding which specific section or chapter to fetch in full.' It names the alternative (get_full_act) and why this one is preferable (much shorter), giving a clear 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?

Since no annotations are provided, the description carries the behavioral disclosure burden. It clearly explains how search results are ranked and that matching is exact/near-exact word matching rather than semantic. It does not explicitly state that the tool is read-only, but this is implied by its search nature.

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 appropriately sized and information-dense: it conveys orchestration guidance, purpose, ranking, and matching semantics in a compact form. The all-caps orchestration instruction is slightly verbose but still relevant and front-loaded.

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 keyword search tool with no annotations and no output schema, the description covers key behavior and distinguishing semantics. It does not describe the output format, but the ranking behavior and matching limitations give an agent enough context to use the tool effectively.

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 adds meaning beyond the schema by clarifying that the query matches against titles and body text, and that exact/near-exact keywords are used rather than meaning-based matching, which helps the agent form effective queries.

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

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

The description clearly states the tool performs a keyword search over section titles and text, and specifies a precise three-tier ranking scheme. It is easily distinguishable from the sibling get_* and list_* tools because it is the only search-oriented tool in the group.

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 explicit guidance to use this tool first when the specific section number is unknown and instructs the agent never to guess section numbers. It does not explicitly name alternatives for cases where section numbers are already known, but the orchestration cue and the 'NOT meaning-based search' limitation provide strong usage context.

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