Skip to main content
Glama
GemachDAO

GDEX Trading

by GemachDAO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

generate_evm_wallet

Read-only

Generate a new EVM wallet offline without network calls. Returns only the address by default, or reveal private key and mnemonic if requested.

Instructions

Generate a new EVM wallet offline (no network call). To trade with it, use gdex_connect { create: true } instead, which stores it locally. Returns only the address unless revealSecrets is true.

Input Schema

NameRequiredDescriptionDefault
revealSecretsNoReturn privateKey and mnemonic too (they then appear in the conversation)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.12.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / revealSecrets
      Added value: +{
+  "description": "Return privateKey and mnemonic too (they then appear in the conversation)",
+  "type": "boolean"
+}
  2. First observedv4.11.3

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds real behavioral detail: it runs offline with no network call, returns only the address by default, and reveals secrets only when asked. It doesn't state whether the wallet is persisted or discarded, which is the one gap.

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?

Three short sentences, zero waste, with the defining constraint (offline) front-loaded before the alternative and return behavior.

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?

Despite having no output schema, the description tells the agent exactly what comes back (address only, or privateKey/mnemonic with revealSecrets) and when to use a sibling instead. Nothing essential is missing for correct invocation.

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 100% and the schema already documents revealSecrets including its side effect. The description reinforces the same fact ('Returns only the address unless revealSecrets is true') but adds no new syntax or format detail, so the 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 verb and resource ('Generate a new EVM wallet') plus a distinguishing qualifier ('offline (no network call)'). It clearly separates itself from gdex_connect, which is the persistence/trading path.

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?

Explicitly routes the agent: use this for an offline throwaway wallet, but 'use gdex_connect { create: true } instead' when you need to trade with it. When-to-use and the alternative are both named directly.

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