MCP server that routes EVM transactions and messages to your own browser wallet for signing — a thin shim over browser-web3-signer
Server has 5 tools with varying quality. Tool naming follows verb_noun pattern well (connect_wallet, send_transaction, sign_message, etc.). Descriptions are present and reasonably detailed, particularly for high-risk operations. However, schema quality is inconsistent: some parameters lack descriptions or have minimal constraints. Parameter schemas use proper JSON Schema format but miss validation boundaries (e.g., chainId accepts any number with no min/max). Output schemas are not documented anywhere in the visible code. Error handling is implicit (browser timeout mentioned in descriptions) but lacks structured error guidance. No enum constraints visible for parameters that should have them (e.g., chainId could be enumerated to valid network IDs).
Open the approval page and connect a browser wallet. Returns the address.
Ask the user to approve and send a transaction from their browser wallet. Returns the tx hash.
Sign a plain message with `personal_sign`. Returns the signature.
Sign EIP-712 typed data. Returns the signature.
Output schemas completely undocumented. No visible documentation of what each tool returns, field types, or structure. Users cannot predict downstream data availability for chaining.
sign_typed_data parameter 'domain' and 'types' lack individual field descriptions. The 'types' parameter shows only a code comment example, not a formal schema or constraint. LLMs cannot infer valid structure.
All numeric 'chainId' parameters lack min/max bounds. No enum of valid chains provided. LLMs can pass invalid chain IDs (e.g., chainId: 999999) without validation guidance in the schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 14 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
send_transaction has optional 'value' and 'data' parameters but no description of mutual exclusivity or when each applies. Gas parameters (gasLimit, maxFeePerGas, maxPriorityFeePerGas) lack clear constraints and EIP-1559 vs legacy tx guidance.
Browser interaction described in plain text ('This tool opens a browser window') but no structured timeout or retry guidance in error handling. Descriptions mention 5-min timeout but no recovery strategy documented.
Parameter 'address' in sign_message and sign_typed_data lacks guidance on format validation (0x prefix, length). No constraint stating 40 hex chars required. LLMs may pass malformed addresses.