Machine-readable Japanese crypto-asset tax rules for AI agents: rules-as-code with citations, x402.
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 3.9/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: list_tax_rules catalogs rules, get_tax_rule retrieves a single rule, get_tax_parameters provides tax parameters, and get_rule_pack delivers scenario-based bundles. No functional overlap.
All tool names follow a consistent verb_noun pattern: list_tax_rules, get_tax_rule, get_tax_parameters, get_rule_pack. The naming convention is uniform and predictable.
With 4 tools, the server is well-scoped for its domain (Japanese crypto tax rules). Each tool serves a necessary function, and the count is neither too sparse nor excessive.
The tool surface covers cataloging, single-rule retrieval, parameters, and scenario packs. Minor gap: no batch retrieval for full rules by category, but list with filtering partially addresses this.
get_rule_packCurated scenario rule pack (x402 metered)AInspectScenario-curated bundle of full structured rules (statements, citations, parameters) for one use case: defi_staking | overseas_exchange | corporate_holding | transition_2028. Paid via x402: each call costs 0.05 USDC. This tool returns the HTTP 402 payment challenge (spec-conformant accepts list) for the pack resource. The 402 is real: settle it against /v1/packs/{scenario} with an X-PAYMENT header and the 200 response delivers the full pack body ({status:"settled", settlement, pack}) — payment buys the actual structured rules, not a receipt. Not tax advice. 一般的な税制情報の提供であり、個別の税務判断は税理士にご相談ください。
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | Yes | Scenario pack to retrieve: defi_staking | overseas_exchange | corporate_holding | transition_2028 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the 402 payment challenge, cost (0.05 USDC), settlement process (X-PAYMENT header), and expected 200 response structure. It also includes disclaimers. However, it does not detail failure modes or rate limits, which slightly reduces completeness.
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 necessary, mixing core functionality, payment details, and legal disclaimers (including Japanese text). While each part serves a purpose, it could be more concise without losing essential 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?
Given the complexity (paid, multi-step flow) and lack of output schema or annotations, the description adequately covers the tool's operation: it returns a 402 challenge, requires settlement, and returns the pack body. Disclaimers are included. Minor gaps exist (e.g., no mention of error handling for invalid scenarios, but schema enforces enum).
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 input schema has 100% coverage, describing the single 'scenario' parameter with enum values. The description redundantly lists the same enum values, adding no additional semantic meaning 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 clearly states it retrieves a curated bundle of structured rules for specific scenarios, with stated use cases (defi_staking, etc.). It distinguishes from siblings (get_tax_parameters, get_tax_rule, list_tax_rules) by being a paid, scenario-specific bundle. However, the description is somewhat verbose, mixing payment details and disclaimers.
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 implies this tool is for retrieving a complete rule pack for a specific scenario, while siblings are for individual parameters or rules. However, it does not explicitly state when to use this vs. alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tax_parametersJapanese tax parameters (brackets, rates, thresholds)AInspectFREE — returns structured tax parameters with per-value sources: progressive income tax brackets, resident tax and reconstruction surtax figures, the 2028-reform separate-taxation rate and loss-carryforward years, and the salary-filer filing threshold. Approximate reference values from public sources; not tax advice. 一般的な税制情報の提供であり、個別の税務判断は税理士にご相談ください。
| Name | Required | Description | Default |
|---|---|---|---|
| tax_year | No | Tax year for epoch annotation of pending-reform rules, e.g. 2026 or 2028 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that values are approximate and from public sources, and that it's not tax advice. It also mentions 'FREE' which hints at no cost. However, it does not describe whether the operation is read-only (presumed), any authentication requirements, or rate limits. The behavioral transparency is adequate but not thorough.
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 English sentence (plus a Japanese note) that packs all essential information: purpose, content, source quality, and disclaimer. It is front-loaded with 'FREE' and immediately states what the tool returns. Every phrase adds value with no wasted words.
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 a single optional parameter and no output schema, the description provides a comprehensive list of returned values and their nature (approximate, sourced). It includes a disclaimer. It could explicitly state the return format (object with keys) but 'structured tax parameters' implies organized data. The Japanese note adds completeness for its target audience.
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% with a detailed description for tax_year: 'Tax year for epoch annotation of pending-reform rules, e.g. 2026 or 2028.' The tool description adds further context by listing the specific tax items returned, which complements the schema. No ambiguity remains.
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 lists what the tool returns: progressive income tax brackets, resident tax, reconstruction surtax, 2028-reform figures, and filing threshold. The title 'Japanese tax parameters (brackets, rates, thresholds)' and content distinguish it from sibling tools like get_rule_pack and get_tax_rule, which focus on rules rather than parameter values.
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 starts with 'FREE' indicating no cost, and includes disclaimers about approximate values and not being tax advice. It implicitly tells the agent this tool is for retrieving snapshot tax numbers, not for detailed rule lookups. While it doesn't explicitly contrast with siblings, the term 'parameters' vs 'rules' provides adequate guidance. A minor gap: no direct 'when to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_tax_ruleFull structured rule record (rule_id lookup)AInspectFREE — returns one full structured rule: statement, exceptions, status, effective dates, machine tags and statutory citations (sources), served verbatim from the versioned rules corpus. Not tax advice. 一般的な税制情報の提供であり、個別の税務判断は税理士にご相談ください。
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes | Rule id, e.g. jp.crypto.income.classification.individual |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the source ('served verbatim from the versioned rules corpus') and includes a non-tax-advice disclaimer, but does not specify error behavior (e.g., missing rule_id), read-only nature, or any side effects. It is adequately transparent for a simple lookup 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 extremely concise: one English sentence covering purpose and source, plus a necessary legal disclaimer in Japanese. No unnecessary words, and the core information is front-loaded. Every sentence serves a clear purpose.
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 simplicity (single required parameter, no output schema, no nested objects), the description provides sufficient context: what is returned, the source, and a disclaimer. It does not cover error cases or return format details, but these are not critical for a straightforward 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 description coverage is 100%: the parameter 'rule_id' already has a clear description and example. The description adds context by framing the lookup as 'rule_id lookup' and giving an example in the schema, but does not substantially enhance meaning 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 clearly states the tool's purpose: 'returns one full structured rule' and lists specific components (statement, exceptions, status, etc.). It also identifies the lookup method (rule_id). This distinguishes it from sibling tools like list_tax_rules (list) or get_rule_pack (likely returns a set of rules).
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 no explicit guidance on when to use this tool vs. alternatives. It includes a 'FREE' label and a legal disclaimer, but does not explain prerequisites, when not to use, or how this complements siblings like get_rule_pack or get_tax_parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tax_rulesList structured Japanese crypto tax rulesAInspectFREE — returns structured rules. Catalog of machine-readable Japanese crypto-asset tax rules (rules-as-code): titles, status (current / enacted_pending), effective dates and statutory citations, filterable by category, taxpayer and tax_year. tax_year resolves the current-vs-2028-reform epoch per rule (applies / pending_enforcement). Sources are public only (NTA FAQ, e-Gov statutes, MOF documents); not tax advice. 一般的な税制情報の提供であり、個別の税務判断は税理士にご相談ください。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category filter: corporate | cost_basis | filing | income_classification | reform_2028 | taxable_events | |
| tax_year | No | Tax year to resolve rule applicability, e.g. 2026 or 2028 | |
| taxpayer | No | Taxpayer filter: all | corporate | individual |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description notes 'FREE — returns structured rules' and disclaims tax advice, but does not explicitly state read-only behavior, authorization needs, or rate limits. As a list operation, read-only is implied but not confirmed.
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 front-loaded with 'FREE — returns structured rules' and key details, but includes a Japanese disclaimer that adds length. Overall, it is clear and concise without excess.
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 no output schema and no annotations, the description covers return fields (titles, status, dates, citations), filtering options, and source types. Lacks details on pagination or response size, but sufficient for basic usage.
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 basic descriptions. The description adds value by explaining that tax_year 'resolves the current-vs-2028-reform epoch per rule (applies / pending_enforcement)', and lists category filter values, enhancing understanding 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 title 'List structured Japanese crypto tax rules' and description clearly state it returns a catalog of machine-readable rules with fields like titles, status, dates, citations. The description differentiates from siblings (get_rule_pack, get_tax_parameters, get_tax_rule) by being a list/filter operation.
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 implies usage via filtering parameters but does not explicitly state when to use this tool versus sibling tools (e.g., for listing vs. single rule retrieval). No 'when not to use' guidance is provided.
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.