lr-labs

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

With no annotations, the description carries the full transparency burden, and it succeeds. It discloses the tool's determinism ('no generative model', 'same facts and same law always produce the same answer'), the exact return structure (answer, condition tree, assumptions, unresolved facts, GAAR gate, authority), and the crucial behavioral rule that stated ABSENT facts defeat a limb while omission leaves the question open.

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 lengthy but every clause contributes actionable information: purpose, return bundle, determinism, usage triggers, and absent-fact semantics. It is front-loaded with the core purpose, and the structured flow keeps it readable. It is not maximally concise, but it earns its length.

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 complex tool with 5 parameters, nested objects, and no output schema, the description compensates thoroughly. It enumerates the composed return value, explains the deterministic engine, provides precise usage boundaries, gives absent-fact handling guidance, and refers to a sibling tool for coverage—making its place in the workflow 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?

Schema coverage is high (~80%), so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the effect of stating facts as ABSENT, clarifying that the 'question' field does not drive the answer, and noting that treaty spelling is normalized. This elevates it above baseline, though it falls short of 5 because most parameter detail already resides in the schema.

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

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

The description clearly states the tool computes the tax position of cross-border arrangements, with specific focus on permanent-establishment exposure and Indian tax liability. It also distinguishes itself from siblings by explicitly instructing to use it 'INSTEAD OF answering from memory' for enumerated tax scenarios and referencing list_compiled_corridors for coverage checks.

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 provides explicit when-to-use conditions: questions involving permanent establishment, dependent agents, cross-border sales into India, specific treaty corridors, or attribution of profits. It also gives a clear alternative action ('Call list_compiled_corridors first if unsure of coverage') and frames the tool as the preferred route over memory-based answers, making the usage boundary explicit.

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 takes on the full burden. It discloses a key behavioral trait: the engine 'refuses rather than guesses' outside compiled corridors. While it doesn't explicitly state read-only semantics, 'List' implies a safe read operation, and the refusal behavior is valuable. A slight gap remains in not detailing any other side effects or constraints.

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 two sentences long, with the first stating the tool's output and the second providing usage context. No wasted words, and the most critical information is front-loaded. Each sentence adds value.

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 zero-parameter tool with no output schema, the description is complete. It specifies what will be listed (treaty pairs, PE families, counts, schema) and when to use it. The refusal behavior also informs the user of limitations, making the tool's purpose and boundaries fully clear.

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 are zero parameters, which according to the rubric earns a baseline of 4. The description doesn't add parameter details because none exist; the empty schema is fully covered. No further explanation needed.

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

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

The description clearly states the tool lists treaty pairs, PE families, and compiled-rule counts, plus the structured-fact schema. It uses a specific verb ('List') and resource, and distinguishes itself from siblings by mentioning its role in deciding whether analyze_cross_border_tax can answer a question.

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 'Call this to decide whether analyze_cross_border_tax can answer a question' and notes that outside compiled corridors the engine refuses rather than guesses. This provides clear when-to-use guidance and an alternative tool, satisfying the criterion for explicit usage context.

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 full burden. It discloses the return payload (compiled answer with pinpoint, authority, quote) and refusal behavior for outside compiled topics. It does not explicitly declare read-only status, but the query/response framing strongly implies a safe, non-mutating operation.

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 dense but well-structured: purpose first, then examples, then usage guidance, then behavior. Every sentence earns its place, though the length is slightly above minimal; the examples are valuable enough to justify it.

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 there is no output schema, the description compensates by explaining return fields (pinpoint, authority, quoted text), refusal behavior, and usage boundaries. It does not list all compiled topics, but the refusal mechanism covers that gap. Overall it is complete for a read-only 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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by defining what qualifies as a 'rule-level question', giving concrete query examples, and explaining the style of input (plain language). This materially aids parameter use, especially for the query field.

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 opens with a specific verb+resource: 'Answer a RULE-LEVEL question directly from compiled law'. It provides detailed examples and explicitly distinguishes itself from analyze_cross_border_tax, making its purpose unmistakable.

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 explicitly states when to use this tool vs. alternatives: 'Use THIS, not analyze_cross_border_tax, when the question is about the law in the abstract; use analyze when you have a specific matter's facts.' This is clear, actionable guidance with a named alternative.

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 of transparency. It states the tool is 'deterministic' and 'Computed from compiled Indian TP rules with no generative model in the path,' which reassures about the nature of the computation. It also exposes the specific rules applied (Rule 10TD floors, Rule 10D, Rule 10CA). It does not disclose output format or error/edge-case behavior, but for a deterministic rule-based analyser this is reasonably transparent.

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 about four sentences and around 130 words. It is longer than minimal, but every sentence contributes: it lists outputs, describes the computation method, gives usage intent, and names the alternative tool. It is well-structured and front-loaded with the main action, though slightly dense for a quick scan.

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

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

There is no output schema, so the description needs to convey what the user gets. It does so by listing the key answers (safe-harbour eligibility, documentation obligations, eligible methods, ARP range). It also covers the primary use cases and the boundary against a sibling tool. However, it does not mention any prerequisites or typical inputs like transaction value or markup percentage, so it is not fully complete on its own.

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 56% (5 of 9 params described in schema), so the description needs to compensate. It adds semantic context by mentioning 'safe-harbour eligibility against the Rule 10TD floors' (links to serviceMarkupPct), 'cost-plus markups' (links to transactionType), and 'whether a comparables percentile falls inside the arm's-length range' (links to alrPercentile). It does not clarify every param (e.g., hasInternalCup/hasExternalCup), but the domain context helps infer meaning.

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 opens with a specific verb ('Screen') and an explicit resource ('Indian transfer-pricing position'), then enumerates concrete outputs (safe-harbour eligibility, documentation obligations, eligible methods, arm's-length range). It clearly distinguishes itself from the sibling tool by noting 'For the permanent-establishment side of the same arrangement, use analyze_cross_border_tax.'

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 states when to use the tool: 'Use for questions about intra-group service fees, cost-plus markups, royalties, management charges, safe harbour, TP documentation, or arm's-length pricing...' It also names the alternative tool and the exact condition for using it (permanent-establishment side), providing an exclusion and a sibling comparison.

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 exist, so the description carries full burden. It discloses determinism, the compiled corpus scope, polarity checking against a holdings ledger, and crucially the limitation that 'no flags' only means nothing compiled contradicts, not a confirmation outside compiled corridors. This is rich, honest behavioral disclosure.

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 concise despite covering many points. It starts with the main verb and scope, adds examples, then a clear warning and usage directive. Every sentence contributes: no filler or redundant statements.

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 only 2 simple parameters and no output schema, the description sufficiently explains what the tool does, how it behaves, its limitations, and when to use it. The output behavior is implied ('no flags means...'), enough for an agent 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% for both parameters, so baseline is 3. The description adds meaning by instructing the agent to 'Write the claim as a sentence' and providing a concrete example, plus clarifying that 'as_of' is an optional validity date. This goes beyond the bare schema and helps proper usage.

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 identifies the tool's purpose with a specific verb ('verify') and resource ('tax research note/analysis'). It enumerates a precise scope (citations, quotes, thresholds, temporal claims, case holdings) and names specific cases (E-Funds, Formula One, etc.), making it distinct from sibling tools like analyze or 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?

Explicit usage guidance is provided: 'Use before relying on or presenting any cross-border tax reasoning.' This clearly states when to use the tool. It does not explicitly discuss when not to use it or mention alternatives, but the context is strong and practical.

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