Skip to main content
Glama

declare_jurisdiction

Idempotent

Declare your wallet's jurisdiction for geo-gated trading.

Gap: before this tool, the ONLY way to declare a jurisdiction was the jurisdiction= param on trade_equity -- an agent that only ever used perps/short/leverage tools had no write path at all, and the fail-safe unknown-jurisdiction-DENIED rule permanently refused it. Call this ONCE (or pass jurisdiction= directly on any perps/short/leverage/trade_equity tool) and the declaration is remembered for 90 days across EVERY geo-gated framework (tokenized equities under Reg S, perps/synthetic-shorting/leverage under the CFTC posture).

jurisdiction is an ISO-3166-1 alpha-2 country code (e.g. "US", "GB", "SG") -- YOUR OWN self-declaration of where you are, never advice or a recommendation (hard rules 2/5-8). A US-person declaration does not unblock US-restricted venues; it makes the DENIED reason explicit rather than "jurisdiction_unknown". Re-declaring overwrites the prior value.

Versioned terms acceptance: accepted_terms=true AND terms_version (the version string published with the terms at https://engaij.com/legal/crank/terms) are REQUIRED -- a declaration with the terms declined, unstated, or acknowledging a superseded version is rejected with the terms URL. Every value-bearing action (trade build, perp order, send, claim, payout) fails closed until this wallet has accepted the CURRENT terms version; when the published terms version is bumped, the next value-bearing action is refused until re-acceptance.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "wallet_address": "<wallet_address>",
      "jurisdiction": "<jurisdiction>"
    },
    "name": "declare_jurisdiction"
  }
}

Input Schema

NameRequiredDescriptionDefault
ipNo
caller_idNo
jurisdictionYes
terms_versionNo
accepted_termsNo
wallet_addressYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / accepted_terms
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
    • addedInput schema / properties / terms_version
      Added value: +{
      +  "default": "",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (write, open-world, idempotent, non-destructive), and the description adds substantial behavior beyond them: 90-day persistence across frameworks, the fail-safe unknown-jurisdiction DENIED rule, the terms-version gating that blocks every value-bearing action until re-acceptance, and the rejection-with-terms-URL on stale versions. This is exactly the extra context an agent needs before calling.

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 purpose and the ONCE/alternative guidance are front-loaded, and the terms section is clearly delineated. The 'Gap:' paragraph is more justification-for-existence than invocation guidance, so it is mild padding, but the overall structure is readable and mostly earns its length.

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?

An output schema exists, so return values need no explanation. Given a 6-param, geo-plus-terms-gated mutation, the description supplies the format of jurisdiction, the terms-version precondition, persistence duration, and failure behavior — everything needed to call it correctly.

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 description coverage is 0%, so the description must carry parameter meaning, and it does so for the critical ones: jurisdiction is defined as an ISO-3166-1 alpha-2 self-declaration, and accepted_terms=true plus terms_version are called out as REQUIRED with the consequence of omission. It does not explain ip or caller_id, which keeps it short of a 5.

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?

Opens with a specific verb+resource+purpose: 'Declare your wallet's jurisdiction for geo-gated trading.' It further distinguishes itself from the sibling write path by explaining that the alternative is the jurisdiction= param on trade_equity, so an agent can route correctly without inspecting schemas.

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?

States explicitly when to call it ('Call this ONCE') and names the alternative ('or pass jurisdiction= directly on any perps/short/leverage/trade_equity tool'). It also covers the re-declaration case (overwrites the prior value) and the consequences of skipping it (fail-closed), leaving no routing ambiguity.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources