pathiel

Overview Schema Source Related Servers Discussions Admin

connect_wallet

Destructive

Creates a local API wallet key and opens a page for the user's browser wallet to approve it with one signature, enabling trading (but not withdrawals). Poll with status=true to track the connect.

Instructions

Connect the user's Hyperliquid wallet so pathiel can trade: makes a new API wallet key on this machine, opens a local page where the user's browser wallet approves it with one signature, and saves the key to ~/.pathiel/.env.local. The API wallet can trade and never withdraw. status=true reports a connect in progress (waiting, done or failed) and starts nothing; cancel=true stops a waiting one; replace=true swaps a key already set, only when the user said so; open_browser=false prints the page link instead of opening it. Call only when the user asked; get_status shows whether trading is enabled. It returns at once and does not wait for the signature: poll with status=true. With a key already set it keeps that key unless replace=true. A failure returns {ok: false, state: failed, code, error, next} saying what to do. Returns the connect state (waiting, done or failed) and the page link.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "connect_wallet"
  }
}

Input Schema

Name	Required	Description
`cancel`	No	stop a waiting connect
`status`	No	report the current connect, start nothing
`replace`	No	swap out the key already set; only when the user said so
`open_browser`	No	open the page (default true)

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.6.1Nov 14, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations only declare destructiveHint=true; the description supplies the missing behavioral context: a key is written to ~/.pathiel/.env.local, the API wallet can trade but never withdraw, an existing key is preserved unless replace=true, and the call is asynchronous and must be polled with status=true. It also describes the failure envelope ({ok:false, state:failed, code, error, next}). It stops short of stating permissions or auth requirements for the browser signature step, so not a full 5.

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 is front-loaded and nearly every clause carries operational detail, but it is a dense run-on paragraph with mild redundancy — the asynchronous/polling behavior is stated twice and the page link is mentioned in both the open_browser sentence and the final return sentence.

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 mutating, multi-mode, asynchronous tool with no output schema, the description covers the return states (waiting/done/failed), the failure shape and its next-step field, key persistence location, and the polling protocol. Nothing an agent needs to call it and interpret the result is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns more by adding semantics the schema lacks: status=true "starts nothing," cancel=true targets only a waiting connect, replace=true carries a consent constraint ("only when the user said so"), and open_browser=false changes output to printing the link rather than opening it.

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?

States a concrete verb and resource ("Connect the user's Hyperliquid wallet") plus the mechanism: creates an API wallet key locally, opens a page for the browser wallet to sign, and persists the key to ~/.pathiel/.env.local. An agent can distinguish this from get_status or place_bracket without opening any schema.

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?

Gives explicit invocation conditions ("Call only when the user asked"), routes status checks to the sibling ("get_status shows whether trading is enabled"), and explains each mode's when-to-use: status=true reports without starting anything, cancel=true stops a waiting connect, replace=true only when the user said so. Exclusions and alternatives are both named.

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