Skip to main content
Glama
mrq1911

SSIG MCP

by mrq1911
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

SSIG MCP

SSIG is a local MCP-to-browser signing bridge for EVM, Solana, and Sui. An agent can prepare and simulate a transaction, but it cannot access a private key or approve the wallet prompt. You inspect the request in a retro terminal UI and sign with an extension already installed in your browser.

What it does

  • Exposes separate MCP tools for EVM, Solana, and Sui transaction requests.

  • Requires an ASCII-only agent explanation for every request.

  • Automatically attempts a dry run before adding the request to the queue.

  • Serves an authenticated approval UI on loopback by default, with explicit RFC1918 LAN mode.

  • Discovers EIP-6963/EIP-1193 EVM wallets, Solana Wallet Standard wallets, and Sui Wallet Standard wallets.

  • Supports sign and sign-and-submit modes.

  • Persists request state, never keys, in ~/.ssig/requests.json with owner-only permissions.

The UI keeps three pieces of evidence separate:

  1. The agent's ASCII explanation (explicitly marked untrusted).

  2. The dry-run output.

  3. Decoded and exact serialized transaction data.

The browser wallet's own confirmation screen is the final authority.

Related MCP server: waiaas

Install and build

Requirements: Node.js 20 or newer and a compatible browser wallet extension.

npm install
npm run build
npm test

Run it manually with:

npm start

The process prints the terminal URL to stderr. MCP itself uses stdin/stdout, so an MCP client will normally start the process for you.

MCP configuration

Add a local stdio server to your MCP client, using the absolute path to the built entrypoint:

{
  "mcpServers": {
    "ssig": {
      "command": "node",
      "args": ["/absolute/path/to/ssig/dist/server/server/index.js"],
      "env": {
        "SSIG_PORT": "3721"
      }
    }
  }
}

The available tools are:

  • request_evm_transaction

  • request_solana_transaction

  • request_sui_transaction

  • get_transaction_request

  • list_transaction_requests

  • cancel_transaction_request

The three request tools return an approvalUrl. Open that URL in the browser profile containing your wallet extension.

Required ASCII explanation

asciiExplanation rejects non-ASCII characters. The agent should name amounts, assets, recipients, expected state changes, and material risk. For example:

+------------------- SWAP --------------------+
| INPUT  : 100.00 USDC                       |
| ROUTE  : USDC -> WETH via 0xRouter...      |
| MIN OUT: 0.031 WETH                        |
| SIGNER : 0x1234...abcd                     |
| RESULT : USDC decreases; WETH increases    |
| RISK   : slippage, malicious router, MEV   |
+---------------------------------------------+

This explanation is context, not proof. Compare it with the decoded payload, dry run, and extension preview.

Transaction formats

EVM

Pass chainId, an optional expectedSigner, and an EIP-1193 transaction object. Quantities must use canonical JSON-RPC hex (0x0, 0x1, and so on). SSIG checks the active chain and never calls wallet_addEthereumChain; unknown networks must be added by you through a trusted wallet flow.

sign-and-submit uses eth_sendTransaction. sign uses eth_signTransaction, which many consumer wallets intentionally do not support.

Solana

Pass a Wallet Standard chain identifier and a base64-encoded wire transaction:

  • solana:mainnet

  • solana:devnet

  • solana:testnet

  • solana:localnet

The transaction can be unsigned or partially signed. The extension receives the exact decoded bytes through solana:signTransaction or solana:signAndSendTransaction.

Sui

Pass a Sui Wallet Standard chain identifier and base64-encoded BCS TransactionData bytes:

  • sui:mainnet

  • sui:testnet

  • sui:devnet

  • sui:localnet

SSIG uses Mysten's dApp Kit compatibility layer, including modern and legacy Sui Wallet Standard features.

Dry-run configuration

Simulation destinations are configured by the server owner, never by an MCP tool argument. This prevents an agent from turning the bridge into an arbitrary network client.

EVM

Tenderly is preferred when all three settings are present:

SSIG_TENDERLY_ACCOUNT=my-account
SSIG_TENDERLY_PROJECT=my-project
SSIG_TENDERLY_ACCESS_KEY=secret

If Tenderly is unavailable or fails, SSIG can fall back to eth_call plus eth_estimateGas through a chain-ID map:

SSIG_EVM_RPC_URLS='{"1":"https://ethereum.example/rpc","8453":"https://base.example/rpc"}'

Tenderly needs expectedSigner because the sender is required for an accurate simulation.

Solana

SSIG calls the native simulateTransaction RPC with signature verification disabled and recent-blockhash replacement enabled:

SSIG_SOLANA_RPC_URLS='{"solana:mainnet":"https://solana.example/rpc","solana:devnet":"https://api.devnet.solana.com"}'

Sui

SSIG calls the current Sui Core API simulateTransaction over gRPC:

SSIG_SUI_GRPC_URLS='{"sui:mainnet":"https://fullnode.mainnet.sui.io:443","sui:testnet":"https://fullnode.testnet.sui.io:443"}'

Simulation policy

By default, an unavailable simulator is shown prominently but does not prevent signing. A simulation that executes and reports failure is blocked by default.

# Refuse requests when simulation is unavailable or errors.
SSIG_REQUIRE_SIMULATION=true

# Allow the user to inspect and sign even after a simulated execution failure.
SSIG_BLOCK_FAILED_SIMULATION=false

Simulation is point-in-time and provider-dependent. It cannot guarantee later execution, protect against every state change, or prove the agent's explanation is accurate. Sending a transaction to a simulation provider also reveals its contents to that provider.

Other configuration

Trusted-LAN access

Loopback is the secure default. To open the approval terminal from another machine on the same trusted private network, opt in explicitly and advertise this machine's RFC1918 address:

SSIG_HOST=0.0.0.0 \
SSIG_ALLOW_LAN=true \
SSIG_PUBLIC_HOST=192.168.1.50 \
npm start

LAN mode continues to require the random UI bearer token and accepts only loopback or the exact SSIG_PUBLIC_HOST value in the HTTP Host header. It uses plain HTTP, so use only a trusted LAN; on shared or hostile networks, keep loopback mode and use an SSH port-forward instead.

Variable

Default

Purpose

SSIG_HOST

127.0.0.1

Bind address. LAN mode accepts 0.0.0.0 or a private IPv4 address.

SSIG_ALLOW_LAN

false

Required explicit opt-in for non-loopback binding.

SSIG_PUBLIC_HOST

—

Exact RFC1918 address advertised and allowed in LAN mode.

SSIG_PORT

3721

UI/API port. Use 0 to choose a free port.

SSIG_DATA_DIR

~/.ssig

Persistent request-state directory.

SSIG_REQUEST_LIMIT

1000

Maximum retained requests; pending requests are never pruned.

SSIG_WEB_DIR

bundled dist/web

Override the static browser build location.

Security boundaries

  • SSIG binds only to loopback by default. LAN mode is explicit, RFC1918-only, and allowlists one exact Host value to reduce DNS-rebinding risk.

  • The approval API uses a random 256-bit bearer token. The browser stores it in session storage and immediately removes it from the URL.

  • API responses are no-store, the UI cannot be framed, and a restrictive Content Security Policy is applied.

  • The server validates the connected wallet against expectedSigner again when recording completion.

  • RPC URLs come only from administrator environment variables.

  • The MCP never receives seed phrases, private keys, or extension secrets.

  • An agent can still propose a malicious transaction or misleading ASCII explanation. Always read the extension preview and use small-value test transactions first.

Development

npm run typecheck
npm test
npm run build

The browser interface is visually inspired by AnderShell 3000. See NOTICE for attribution.

Available Tools

6 tools
cancel_transaction_requestCancel transaction requestA
Destructive

Cancel a still-pending browser approval request.

ParametersJSON Schema
NameRequiredDescriptionDefault
requestIdYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already signal destructive/non-read-only behavior, so the bar is lower. The description adds valuable context by specifying exactly what is affected (the pending browser approval request) and adding the 'still-pending' state requirement, which goes beyond the basic destructiveHint. This enriches the agent's understanding of the tool's effect.

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

Conciseness5/5

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

The description is a single, seven-word sentence that is front-loaded with the verb and object. It contains no filler words or redundant information. Every word contributes meaning, making it exemplary in conciseness.

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

Completeness3/5

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

For a simple one-parameter tool with annotations, the description covers the core action and state condition. However, it does not explain what happens when the request is not pending, nor does it clarify how to obtain the requestId. Given the absence of an output schema and the tool's simplicity, the description is adequate but has clear gaps in error handling and parameter linkage.

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

Parameters2/5

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

The schema has zero description coverage for the only parameter, requestId, and the tool description does not mention it at all. The description fails to compensate for the low schema coverage, leaving the agent to infer that requestId is the identifier of the request to cancel from the tool name. This is a minimal, but not absent, semantic connection.

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 the specific verb 'Cancel' and identifies the resource as 'a still-pending browser approval request,' which clearly distinguishes it from sibling tools like request/review or list transactions. The qualifier 'still-pending' adds precision about the target state. This is a clear, specific purpose statement.

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

Usage Guidelines4/5

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

The description implies when to use the tool: for cancelling a request that is still pending approval. It also implicitly excludes non-pending requests, serving as a usage condition. However, it does not explicitly reference alternatives or explain when not to use it beyond the pending-state constraint, so it falls short of a 5.

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

get_transaction_requestGet transaction request statusA
Read-onlyIdempotent

Read the latest status and wallet result for one transaction request.

ParametersJSON Schema
NameRequiredDescriptionDefault
requestIdYes

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the useful context that it returns the latest status and wallet result, which is beyond what annotations convey. 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.

Conciseness5/5

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

A single, concise sentence that front-loads the verb and resource. Every word adds value with no redundancy or filler.

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?

For a simple read-only tool with one parameter and strong annotations, the description is sufficient. It specifies what is read and the key output (status and wallet result), and the ownership of the output is clear. No output schema exists, but the description covers the essential return values.

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

Parameters3/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 compensate. It only implicitly indicates that requestId refers to the transaction request being read ('for one transaction request'), but does not elaborate on format or meaning beyond the schema, which already specifies uuid format. The single parameter is self-explanatory, but little added value.

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 clearly states a specific verb ('Read') and resource ('one transaction request'), and specifies what is returned ('latest status and wallet result'). It distinguishes from sibling tools like list_transaction_requests (plural) and cancel_transaction_request (write operation).

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

Usage Guidelines3/5

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

The description implies use when a single transaction request's status is needed, but does not explicitly mention when not to use it or name alternatives. It lacks guidance like 'use list_transaction_requests for multiple requests' or 'use cancel_transaction_request to modify a request'.

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

list_transaction_requestsList transaction requestsA
Read-onlyIdempotent

List recent approval requests. Serialized transaction payloads are omitted.

ParametersJSON Schema
NameRequiredDescriptionDefault
statusesNo

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare read-only and idempotent safety. The description adds a valuable behavioral note that serialized transaction payloads are omitted, which sets expectations about the response and hints that get_transaction_request should be used for payloads.

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

Conciseness5/5

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

One sentence with the core purpose and a critical omission note. No wasted words.

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

Completeness3/5

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

The tool is simple, but with no output schema and no mention of the statuses filter, the description leaves gaps. It tells what is omitted but not what is included, and doesn't explain filtering behavior.

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

Parameters2/5

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

The single parameter 'statuses' is entirely undocumented in the description, and schema coverage is 0%. The enum values are self-explanatory, but the description adds no meaning about how filtering works or what the parameter does.

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 clearly states the tool lists recent approval requests, using a specific verb and resource. It distinguishes from siblings like get_transaction_request (single fetch) and request_* (creation) by its list nature.

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

Usage Guidelines2/5

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

The description does not explicitly state when to use this tool versus alternatives. It implies a browsing use case with 'recent' but offers no guidance on filtering by status or when to prefer get_transaction_request for specific details.

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

request_evm_transactionRequest EVM transaction approvalA

Simulate and queue an EVM transaction for explicit browser-wallet approval. Never claims that a transaction is signed before the user approves it. asciiExplanation is mandatory, ASCII-only, and must explain amounts, destination, outcome, and risk.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYes
titleYes
chainIdYes
networkNameNo
transactionYes
expectedSignerNo
asciiExplanationYesRequired plain-ASCII explanation of what the transaction does. Use a small ASCII diagram or table, name assets/amounts/recipients, and state the expected outcome and main risk.
expiresInMinutesNo

TDQS

A4.1/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it states the tool simulates before queueing, never claims signature before approval, and enforces asciiExplanation constraints. This complements the annotations (readOnlyHint=false, openWorldHint=true) without contradicting them.

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

Conciseness5/5

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

The description is compact at two sentences, front-loads the core function, and adds a critical safety caveat and a mandatory parameter rule without wasted words.

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

Completeness3/5

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

The description covers the primary action and key safety detail, but doesn't explain the sign vs sign-and-submit modes, return values, or lifecycle of the queued request. Given the absence of an output schema and presence of a nested transaction object, additional context would help the agent use the tool correctly.

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

Parameters3/5

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

Only asciiExplanation receives enhanced semantic guidance in the description, restating and expanding on the schema's requirement. The many other parameters (mode, chainId, transaction fields) are left to the schema, which is sparse given only 13% schema description coverage; the description could have compensated more.

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 opens with 'Simulate and queue an EVM transaction for explicit browser-wallet approval,' which clearly identifies the action (simulate/queue) and resource (EVM transaction) and distinguishes it from sibling tools like request_solana_transaction or list_transaction_requests. The additional caveat about not claiming signature reinforces the tool's role.

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

Usage Guidelines4/5

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

The description implies the tool should be used when an EVM transaction needs user approval, and the name/description differentiate it from Solana/Sui variants. However, it does not explicitly state when to use this over the get/list/cancel transaction request tools, nor does it describe prerequisites or exclusions.

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

request_solana_transactionRequest Solana transaction approvalA

Simulate and queue a serialized Solana transaction for explicit approval with a Wallet Standard browser extension. asciiExplanation is mandatory, ASCII-only, and must explain instructions, assets, destination, outcome, and risk.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYes
titleYes
networkYes
expectedSignerNo
asciiExplanationYesRequired plain-ASCII explanation of what the transaction does. Use a small ASCII diagram or table, name assets/amounts/recipients, and state the expected outcome and main risk.
expiresInMinutesNo
transactionBase64YesBase64-encoded, unsigned or partially signed Solana wire transaction

TDQS

A3.9/5.0
Behavior4/5

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

Beyond annotations, it discloses that transactions are simulated and queued pending explicit user approval, and that asciiExplanation must be a plain-ASCII risk explanation. This adds behavioral context beyond readOnlyHint/idempotentHint flags, though it does not clarify post-approval submission behavior.

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

Conciseness5/5

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

Two sentences, front-loaded with action, no filler. The second sentence adds a critical constraint without redundancy.

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

Completeness3/5

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

Given the tool's complexity (7 params, 2 enums, no output schema), the description covers core function and the critical parameter but omits expected return values or behavior after approval (e.g., sign vs sign-and-submit).

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

Parameters3/5

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

With schema description coverage at 29%, the description compensates by emphasizing asciiExplanation requirements (ASCII-only, content requirements). However, other parameters like mode, network, and expectedSigner are left to schema enums, limiting added semantics.

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 specific verbs 'simulate and queue' and identifies the resource as a serialized Solana transaction for explicit approval via Wallet Standard. It clearly differentiates from sibling tools by network (Solana) and action (request approval).

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

Usage Guidelines3/5

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

The description implies usage for Solana transaction approvals but does not explicitly contrast with sibling alternatives like request_evm_transaction or get_transaction_request. There is no when-not-to-use guidance, only the implied network-specific context.

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

request_sui_transactionRequest Sui transaction approvalA

Simulate and queue serialized Sui TransactionData for explicit approval with a Sui Wallet Standard extension. asciiExplanation is mandatory, ASCII-only, and must explain commands, objects/assets, destination, outcome, and risk.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYes
titleYes
networkYes
expectedSignerNo
asciiExplanationYesRequired plain-ASCII explanation of what the transaction does. Use a small ASCII diagram or table, name assets/amounts/recipients, and state the expected outcome and main risk.
expiresInMinutesNo
transactionBase64YesBase64-encoded BCS Sui TransactionData bytes

TDQS

A4/5.0
Behavior4/5

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

The description adds behavioral context beyond annotations by noting the tool simulates and queues transactions rather than immediately submitting them. The mandatory asciiExplanation requirement is also disclosed, which is a non-obvious behavioral constraint.

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

Conciseness5/5

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

The description is two sentences long, immediately stating the purpose and then highlighting the most critical input constraint. No wasted words, with essential information front-loaded.

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

Completeness2/5

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

The description omits important context about the transaction approval lifecycle, such as how a queued request is later retrieved or canceled, and does not explain the difference between 'sign' and 'sign-and-submit' modes. Given the presence of sibling tools for these operations, more guidance is needed.

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

Parameters3/5

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

Schema coverage is only 29%, but the description adds meaning to key parameters: transactionBase64 is described as serialized Sui TransactionData, and asciiExplanation is described as ASCII-only and required. Other parameters (mode, network, expectedSigner, expiresInMinutes) rely on schema enums and are left unexplained.

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 clearly states the tool simulates and queues serialized Sui TransactionData for explicit approval, specifying the exact resource (Sui) and action (simulate/queue). This distinguishes it from sibling tools for EVM and Solana transactions.

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

Usage Guidelines4/5

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

The description implies this is the tool for Sui transactions via the explicit 'Sui Wallet Standard extension' and 'serialized Sui TransactionData'. However, it does not explicitly mention when to prefer this over the EVM/Solana request tools or cancellation/retrieval tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.1.0
    • First observedcancel_transaction_request
    • First observedget_transaction_request
    • First observedlist_transaction_requests
    • First observedrequest_evm_transaction
    • First observedrequest_solana_transaction
    • First observedrequest_sui_transaction
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a distinct role: three chain-specific request tools, one status getter, one list, and one cancel. No two tools overlap in function; even the three request tools are clearly differentiated by chain.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., request_evm_transaction, get_transaction_request, list_transaction_requests). The pattern is uniform and predictable.

Tool Count5/5

Six tools is well-scoped for a transaction request manager: three chain-specific creation methods plus three lifecycle operations. Each tool earns its place without unnecessary duplication.

Completeness5/5

The tool surface covers the full lifecycle of transaction requests: create (for each supported chain), read (single and list), and cancel. No obvious gaps for the stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • waiaas

    waiaas
    A
    license
    C
    quality
    A
    maintenance
    Self-hosted wallet MCP server for AI agents. Provides 42 tools for multi-chain crypto operations: transfers, token management, DeFi (swap, lend, stake, bridge, perp), NFT, smart contracts, and x402 payments. Supports EVM and Solana with policy engine, spending limits, and human approval.
    60
    30
    MIT

  • Scout

    Lautrek
    A
    license
    B
    quality
    C
    maintenance
    Browser MCP server that connects to your existing browser, preserving sessions, passwords, and extensions, enabling AI agents to interact with web pages without bot detection.
    31
    10
    1
    MIT