Skip to main content
Glama

lr-labs

by io.github.abhinandansethi

Compiled Rule Lookup

lookup_compiled_rule
Read-only

Answer a RULE-LEVEL question directly from compiled law: thresholds and day counts, WITHHOLDING TAX rates on royalty and fees for technical services (treaty and domestic), the 1961→2025 Income-tax Act section renumbering (s.195→s.393(2), s.115A→s.207, s.90→s.159, s.206AA→s.397(2)), tests and their elements, what a named case held. Ask in plain language — 'what is the India–US royalty WHT rate' (15%, not the widely-repeated 10%), 'what replaced section 195', 'is software payment royalty after Engineering Analysis', 'is a TRC sufficient after Tiger Global', 'what does make available mean'. Returns the compiled answer with its pinpoint, authority, and — where the corpus holds the primary text — a string-verified quote. 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. Outside compiled topics it refuses and lists what can be asked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe rule-level question, in plain language.
treatyNoOptional treaty pair to scope the lookup (e.g. 'India-USA', 'India-Germany').

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, which aligns with the description's 'lookup' nature. The description adds behavioral detail: it returns 'the compiled answer with its pinpoint, authority, and — where the corpus holds the primary text — a string-verified quote', and it refuses outside compiled topics. No contradictions.

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

Conciseness4/5

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

The description is long but well-structured, front-loading the core purpose and then expanding with examples, disambiguation, and behavioral notes. Every sentence contributes necessary information. A slight reduction because a few examples could be trimmed, but overall it is efficient for the complexity.

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

Completeness5/5

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

Despite having no output schema, the description explains the return format (pinpoint, authority, quote). It covers scope, refusal behavior, sibling differentiation, and parameter usage. For a tool with two parameters and a well-defined domain, this is complete and leaves no major gaps.

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

Parameters4/5

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

Schema coverage is 100% with each parameter having a description. The description adds value by providing concrete examples of valid queries for the 'query' parameter (e.g., 'what is the India–US royalty WHT rate') and clarifying the scope of the 'treaty' parameter. This goes beyond the schema's minimal descriptions.

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

Purpose5/5

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

The description uses a specific verb ('Answer a RULE-LEVEL question') and resource ('compiled law'), provides concrete examples of supported queries (thresholds, WHT rates, section renumbering, tests, case holdings), and explicitly distinguishes from the sibling tool analyze_cross_border_tax by stating when to use each.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool ('when the question is about the law in the abstract') versus the sibling ('use analyze when you have a specific matter's facts'), and also notes that the tool refuses outside compiled topics, listing what can be asked.

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

All lr-labs toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: analyze for specific fact patterns, lookup for abstract rule questions, list for coverage inquiry, screen for transfer pricing, and verify for checking analysis. The descriptions explicitly cross-reference each other to disambiguate when to use which, such as 'use analyze when you have a specific matter's facts' vs 'use lookup when the question is about the law in the abstract'.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: analyze_cross_border_tax, list_compiled_corridors, lookup_compiled_rule, screen_transfer_pricing, verify_tax_research_note. The verbs are distinct and the nouns clearly describe the resource or action.

Tool Count5/5

Five tools is well-scoped for this domain: coverage discovery, rule lookup, fact-based analysis, transfer pricing screening, and verification. Each tool earns its place without redundancy or bloat, matching the tightly defined purpose of the server.

Completeness5/5

The tool set covers the full workflow: discover what the engine covers, look up abstract rules, analyze specific cross-border arrangements, screen transfer pricing, and verify any research note. The refusal mechanism for out-of-scope topics ensures no dead ends, and the explicit links between tools make the surface complete for its stated legal reasoning purpose.

Resources