Skip to main content
Glama
Sign In
Society Abstract MCP

Society Abstract MCP

by wearesociety
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ab_generate_wallet

Generate a new Ethereum/Abstract Externally Owned Account (EOA) with private key and address for agents to create keypairs before funding or deploying smart accounts.

Instructions

Generate a brand-new Externally Owned Account (EOA).

RETURNS • privateKey – 0x-prefixed 32-byte hex string • address – checksummed Ethereum/Abstract address

COMMON USES • Let agents spin up their own keypairs before funding or deploying smart-accounts.

SECURITY • The private key is returned in plaintext. Ensure the caller stores it securely and never logs it.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.4

TDQS

A4.4/5.0
Behavior4/5

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

Annotations provide destructiveHint=false and a title, but the description adds valuable behavioral context beyond that: it discloses security implications ('private key is returned in plaintext'), storage requirements ('Ensure the caller stores it securely'), and logging restrictions ('never logs it'). It doesn't contradict annotations and adds meaningful operational guidance.

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 perfectly structured with clear sections (RETURNS, COMMON USES, SECURITY), each containing only essential information. Every sentence earns its place: the first states the purpose, subsequent bullets detail outputs and usage context, and the security warning is critical. No wasted words.

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?

For a 0-parameter tool with annotations covering safety (destructiveHint=false) but no output schema, the description provides excellent coverage: purpose, return values (privateKey, address), usage context, and critical security warnings. The only minor gap is not explicitly stating this is a read-only operation (though implied by generation without side effects).

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

Parameters4/5

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

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, and the schema clearly states 'No parameters required.' No additional parameter information is needed or provided.

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 explicitly states 'Generate a brand-new Externally Owned Account (EOA)' - a specific verb ('Generate') and resource ('EOA'). It clearly distinguishes from sibling tools like ab_agw_create_wallet (likely a different wallet type), ab_deploy_token_erc20 (deployment), ab_get_balance (query), and ab_transfer_token (transaction).

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 'COMMON USES' section provides clear context: 'Let agents spin up their own keypairs before funding or deploying smart-accounts.' This indicates when to use this tool (pre-funding/pre-deployment) but doesn't explicitly state when NOT to use it or name specific alternatives among siblings.

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