Skip to main content
Glama
Sign In
dexe-mcp

dexe-mcp

by edward-arinin-web-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Signer and write posture

dexe_write_context
Read-only

Retrieve the session’s write posture—signer mode and address, agent keyring, readiness, deposited DAO power, and any unfinished write journey—before signing or broadcasting governance transactions.

Instructions

Read-only. Write posture for this session — the signer mode + address (WalletConnect, keystore, hot key or none), the agent KEYRING (signerKey, address, gas, 24h broadcasts per persona), Pinata / WalletConnect / Safe readiness, the signer's deposited power in the newest recorded DAO, and a write journey a prior session left unfinished. Chains, env readiness and recorded DAOs are dexe_context.

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": "dexe_write_context"
  }
}

Input Schema

NameRequiredDescriptionDefault
includeAgentBalancesNoProbe each persona's native balance (one eth_getBalance per signer, default chain).
includeDepositedPowerNoRead the signer's deposited power in the newest recorded DAO (one extra RPC call).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.37.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and the description agrees ('Read-only'), so no contradiction. Beyond annotations it discloses non-obvious behavior: the tool probes live state (signer balance, deposited power) and surfaces 'a write journey a prior session left unfinished', i.e. cross-session state. It does not disclose cost or latency of those live probes (the schema notes one RPC per signer / one extra RPC), which leaves a small gap.

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?

Front-loaded with the safety signal and the resource, then a dense but purposeful enumeration, closing with the sibling boundary. Two sentences, no filler, though the second is a heavy run-on list of parentheticals that takes effort to parse.

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

Completeness4/5

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

With no output schema, the description takes on the job of stating return content and does so item by item, which is exactly what an agent needs to decide whether to call it. Only minor gaps remain: the per-flag cost of the additional live probes and the shape of the returned readiness data are left implicit.

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 100% and both parameters (includeAgentBalances, includeDepositedPower) are documented in the schema itself, including their RPC cost. The description never mentions them, so it adds no meaning beyond what the structured field already provides — baseline 3 applies.

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 specific resource and scope ('write posture for this session') and then enumerates exactly what it returns: signer mode/address, agent keyring, Pinata/WalletConnect/Safe readiness, deposited power, unfinished write journey. It explicitly names the sibling boundary ('Chains, env readiness and recorded DAOs are dexe_context'), so an agent can separate it from the broader context tool without opening either schema.

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 'Read-only. Write posture...' framing plus the hand-off to dexe_context for chains/env/DAOs makes the intended pre-write readiness check clear, and it names the alternative for the excluded data. It stops short of an explicit trigger sentence ('call before any write action') and gives no when-not guidance, so it is strong but not fully prescriptive.

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

Deploy Server

Other Tools