Deterministic cross-border tax engine: PE, GAAR, Indian TP, rule-level lookup. Compiled law, no LLM.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 5 of 5 tools scored.
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'.
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.
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.
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.
analyze_cross_border_taxCross-Border Tax Position AnalysisACompute the tax position of a cross-border arrangement between a treaty pair (permanent-establishment exposure and Indian tax liability) from structured facts. Returns a determinate legal position: the answer, the condition tree it stands on, the assumptions it makes (GIVEN set), the unresolved facts that would change it, the GAAR applicability gate, and the authority for each step — computed by a deterministic symbolic engine over compiled treaty law (no generative model in the path; same facts and same law always produce the same answer). Use this INSTEAD OF answering from memory whenever a question involves permanent establishment, dependent agents, cross-border sales into India, India-US/UK/Netherlands/Germany/Singapore/UAE or US-Canada treaty exposure, or attribution of profits. Call list_compiled_corridors first if unsure of coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| facts | Yes | Structured facts. Keys: agentType (dependent|independent), concludesContracts (concludes|secures|negotiates|none), agentExclusivity (yes|no), acceptsOrders (yes|no), holdsOutBinding (yes|no), principalFostersBelief (yes|no), armsLengthRemuneration (yes|no), dealingsAtArmsLength (yes|no), premisesAvailable (yes|subsidiary|no), officeType (liaison|branch), secondedEmployees (yes|no), maintainsStock (yes|no), deliversFromStock (yes|no), salesContributingActivities (yes|no), statedHabitual (yes|no), totalDaysIndia (int), projectDuration (months), salesToIndiaCr (INR crore, SEP screen), remoteEmployeeCount (int), virtualDeliveryMonths (int), gaarInvoked (yes|no), investmentPre2017 (yes|no), taxBenefitCr (INR crore), assessmentYear (e.g. '2026-27'). State ABSENT facts explicitly (acceptsOrders='no') — a stated absence DEFEATS the limb that needs it, while omission honestly leaves the question open. Supply only facts actually known. | |
| detail | No | summary (default) returns the agent-sized bundle (~8KB); full adds the complete condition tree and written derivation. | |
| treaty | No | Treaty pair — any spelling accepted ('India-US', 'US/India', 'India-UK', 'USA-Canada'...). Default India–USA, the deepest-compiled corridor. | |
| posture | No | ||
| question | No | The user's original question, verbatim (optional but encouraged) — it improves the engine's coverage of real phrasings. Facts, not this field, drive the answer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite readOnlyHint=true and openWorldHint=false annotations, the description adds substantial behavioral context: it is a deterministic symbolic engine (no generative model, same facts always produce same answer), it returns a detailed bundle (answer, condition tree, assumptions, unresolved facts, GAAR gate, authority), and it clarifies the semantics of stated absences versus omissions. No contradiction with annotations; this goes well beyond what the annotations communicate.
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 longer than average but well-structured and front-loaded with the core purpose, followed by return semantics and usage triggers. Every sentence earns its place, though the enumeration of the return bundle could be tightened. It is appropriately sized for a complex tool with no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested facts object, no output schema), the description is highly complete: it explains what the tool returns (answer, condition tree, assumptions, unresolved facts, GAAR gate, authority), notes the default summary bundle (~8KB), mentions determinism, and provides usage triggers. This gives an agent enough context to invoke the tool correctly and interpret its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the baseline is 3. The description adds little about parameters beyond what the schema already provides; the guidance about 'State ABSENT facts explicitly' is duplicated in the facts parameter description. The tool description does not elaborate on the 'posture' parameter (which lacks a schema description), so the description does not compensate for the low-coverage parameter. Thus a mid-range score 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?
The description opens with a specific verb ('Compute') and resource ('tax position of a cross-border arrangement between a treaty pair'), clearly stating the tool's domain (permanent-establishment exposure and Indian tax liability). It also distinguishes itself from memory-based answering and hints at the sibling tool list_compiled_corridors, making the purpose unambiguous.
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 this tool ('Use this INSTEAD OF answering from memory whenever a question involves permanent establishment, dependent agents, cross-border sales...') and provides an alternative ('Call list_compiled_corridors first if unsure of coverage'). It does not explicitly exclude use cases for siblings like screen_transfer_pricing or verify_tax_research_note, so it stops short of a full when-not/alternatives matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_compiled_corridorsCompiled Corridor CoverageAList which treaty pairs, PE families, and compiled-rule counts the LR Labs engine covers, plus the structured-fact schema. Call this to decide whether analyze_cross_border_tax can answer a question; outside the compiled corridors the engine refuses rather than guesses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false, but the description adds context beyond that: the engine's refusal behavior outside corridors and the fact that it does not guess. This clarifies an important behavioral trait not conveyed by the annotations.
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 pack significant information: what the tool lists and when to use it. Every sentence earns its place, and the key action is 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?
With no parameters and no output schema, the description is fully self-sufficient. It explains the tool's purpose, its output scope, and its relationship to sibling tools, making it complete for an AI agent to decide when to invoke 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?
There are zero parameters, so the baseline is 4. The description adds value by explaining what the output covers (treaty pairs, PE families, counts, schema), which indirectly clarifies that no parameters are needed to retrieve this coverage information.
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 uses a specific verb ('List') and clearly specifies the resource: treaty pairs, PE families, compiled-rule counts, and the structured-fact schema. It also distinguishes itself from sibling tools by explicitly referencing analyze_cross_border_tax, making its role clear.
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 guidance: call this to decide whether analyze_cross_border_tax can answer a question. It also states the boundary condition ('outside the compiled corridors the engine refuses rather than guesses'), which serves as an exclusion criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_compiled_ruleCompiled Rule LookupAAnswer 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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The rule-level question, in plain language. | |
| treaty | No | Optional treaty pair to scope the lookup (e.g. 'India-USA', 'India-Germany'). |
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.
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.
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.
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.
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.
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.
screen_transfer_pricingTransfer Pricing Screen (India)AScreen an Indian transfer-pricing position deterministically: safe-harbour eligibility against the Rule 10TD floors (17%/18% software-ITES, 18-24% KPO), documentation obligations under Rule 10D, which transfer-pricing METHODS are eligible on the facts, the tested-party rule, and whether a comparables percentile falls inside the arm's-length range (35th-65th, Rule 10CA). Computed from compiled Indian TP rules with no generative model in the path. Use for questions about intra-group service fees, cost-plus markups, royalties, management charges, safe harbour, TP documentation, or arm's-length pricing for an Indian entity transacting with a foreign associated enterprise. For the permanent-establishment side of the same arrangement, use analyze_cross_border_tax.
| Name | Required | Description | Default |
|---|---|---|---|
| posture | No | ||
| question | No | The user's original question, verbatim (optional but encouraged) — it improves the engine's coverage of real phrasings. Facts, not this field, drive the answer. | |
| alrPercentile | No | Where the tested margin sits in the comparables set (percentile, 0-100). | |
| assessmentYear | No | ||
| hasExternalCup | No | ||
| hasInternalCup | No | ||
| transactionType | Yes | e.g. 'Provision of Services', 'IP Licensing / Royalty', 'Contract Manufacturing', 'Distribution of Goods', 'Intra-group Financing'. | |
| serviceMarkupPct | No | Declared cost-plus markup as a PERCENT (e.g. 12 for 12%). Drives safe harbour. | |
| transactionValueCr | No | Transaction value in INR crore. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation: it says the tool operates 'deterministically' and 'with no generative model in the path,' which sets clear expectations about the nature of the output. It also clarifies that the 'question' field is optional and does not drive the answer—only facts do. No contradiction with annotations.
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 information-dense but every sentence carries weight—initial action, specific rules, usage scenarios, and sibling pointer. The list of topics is long but directly relevant; it avoids fluff and extra verbiage, though slightly 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?
Given the high complexity of Indian TP rules, the description covers the tool's core functionality, its deterministic nature, the types of questions it answers, and an explicit alternative. Even though there is no output schema, the enumeration of what it calculates (safe harbour, methods, tested party, arm's-length range) effectively communicates expected results. This is a complete and self-sufficient description.
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 56%, and the description does not directly map to individual parameters beyond broad references (e.g., 'safe-harbour eligibility' implies serviceMarkupPct). The input schema already provides descriptions for key params like alrPercentile and transactionType. The description adds marginal context but does not clarify less-documented parameters such as posture or hasExternalCup, so it lands at the baseline.
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 uses a specific verb ('screen') plus a clear resource ('Indian transfer-pricing position') and enumerates concrete outputs (safe-harbour eligibility, documentation obligations, eligible methods, tested-party rule, arm's-length range). It also distinguishes itself from the sibling tool analyze_cross_border_tax, making its purpose unambiguous.
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 this tool ('Use for questions about intra-group service fees, cost-plus markups, royalties, management charges...') and provides an explicit alternative for the PE side ('use analyze_cross_border_tax'). This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_tax_research_noteTax Research Note VerificationADeterministically verify a piece of tax analysis (yours or anyone's): every citation is resolved against the compiled corpus, quotes and thresholds are checked against compiled law, temporal claims against validity windows — INCLUDING claims about what a named case held (E-Funds, Formula One, Morgan Stanley, Tiger Global, Progress Rail, Centrica …), checked against a string-verified holdings ledger. Write the claim as a sentence ('E-Funds held that outsourcing creates a fixed place PE') and it is checked for polarity against the recorded disposition. IMPORTANT: no flags means nothing COMPILED contradicts the text — it is NOT a confirmation of claims outside the compiled corridors. Use before relying on or presenting any cross-border tax reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The analysis text to verify. | |
| as_of | No | Optional YYYY-MM-DD validity date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description reveals deterministic behavior, the compiled corpus limit, the polarity-checking mechanism, and a named-example ledger. It explicitly warns that an absence of flags only means no contradiction with compiled law, not a general approval. This is rich behavioral disclosure that goes well beyond the structured annotations.
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, well-structured paragraph with four sentences, each earning its place: the main function, an example, a crucial caveat, and a usage directive. The case-name parenthetical is informative without being excessive, and key warnings are highlighted with 'IMPORTANT'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description covers the behavior, scope, limitations, and usage context thoroughly. The only minor gap is that it does not describe the exact return format (e.g., list of flags), but the caveat about 'no flags' implies a flag-based response, which is likely sufficient 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?
The schema covers both parameters completely, so the baseline is 3. The description adds valuable extra semantics by giving a sentence-format example for the 'text' parameter and clarifying that 'as_of' relates to validity windows. This enriches the meaning beyond field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('deterministically verify') and resource ('a piece of tax analysis'), then enumerates the exact checks performed (citations, quotes, thresholds, temporal claims, case holdings). This clearly distinguishes it from sibling tools like analyze_cross_border_tax or lookup_compiled_rule, which have different purposes.
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 before relying on or presenting any cross-border tax reasoning') and also gives a critical exclusion ('it is NOT a confirmation of claims outside the compiled corridors'). This provides both when-to-use and when-not-to-trust guidance, exceeding a simple context hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.