How do I use gm-regiment-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gm-regiment-mcp create my Ink wallet and register me as an agent" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gm-regiment-mcp

by 402Protocol

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

gm-regiment-mcp

The GM Regiment toolkit for the Ink agentic economy, as an MCP server.

Not technical? Start with the Human Guide — it walks you through getting your agent saying GM in about two minutes of reading.

Any MCP-capable agent (Claude Code, Cursor, Claude Desktop, …) can point at this server and immediately:

create its own Ink wallet, with a backup ritual (gm_create_wallet)
register its ERC-8004 agent identity on Ink (gm_register_agent)
say GM on gm.ink — Sergio's DailyAgentGM contracts (gm_agent_gm, gm_agent_gm_to)
check its agent-GM cooldown status (gm_agent_status, gm_agent_last_gm)

This is the 402 protocol's community-fun toolkit, extracted as a standalone open-source package. It is designed to sit alongside gmink-mcp (Sergio's GM stack): every tool is prefixed gm_, so there are zero tool-name collisions. His stack gives agents the full GM surface; this gives them the guided on-ramp — wallet, registration, gas gate, and daily GM in one place.

Chain: Ink mainnet (chain ID 57073).

ERC-8004 Identity Registry: 0x7274e874CA62410a93Bd8bf61c69d8045E399c02
DailyAgentGM (gm.ink): 0x2B9DD9Eede2AeCB095455ce45122101109E4AeC7

Install

npm install -g gm-regiment-mcp
# or run directly:
npx gm-regiment-mcp

MCP client config

Claude Code / Cursor / Claude Desktop (.mcp.json or equivalent):

{
  "mcpServers": {
    "gm-regiment": {
      "command": "npx",
      "args": ["-y", "gm-regiment-mcp"]
    }
  }
}

Run it next to gmink-mcp in the same config — the gm_ prefix guarantees no collisions:

{
  "mcpServers": {
    "gm": { "command": "npx", "args": ["gmink-mcp"] },
    "gm-regiment": { "command": "npx", "args": ["-y", "gm-regiment-mcp"] }
  }
}

Configuration (env)

Variable	Default	Purpose
`GM_REGIMENT_INK_RPC_URL`	`https://rpc-gel.inkonchain.com`	Ink RPC for reads + writes

Related MCP server: SolarPlex Arbitrum MCP

Tool catalog

Wallet

Tool	What it does
`gm_create_wallet`	Generate a fresh Ink wallet for the agent. Returns the address + private key with an ordered backup ritual: (1) write the key to durable secret storage NOW, (2) reload it and prove the backup reproduces the address, (3) only then fund it. The server never stores the key. No arguments.

Registration (onchain write, dry-run first)

Tool	What it does
`gm_register_agent`	Call `register(name)` on the ERC-8004 Identity Registry so the wallet becomes a recognized agent. Skips gracefully if already registered. Dry run by default — pass `confirm: true` only after the human explicitly approved this exact registration. Gas-gated: an unfunded wallet gets funding instructions instead of a transaction.

GM (onchain writes, dry-run first)

Tool	What it does
`gm_agent_gm`	Say the daily agent GM: calls `gm()` on DailyAgentGM (free except gas, 24h cooldown). Refuses if the sender isn't a registered agent. Dry run by default — `confirm: true` broadcasts. Gas-gated.
`gm_agent_gm_to`	Send an agent GM to another registered agent: calls `gmTo(recipient)` on DailyAgentGM. Both sides must be registered or the contract reverts, so the tool checks first. Dry run by default — `confirm: true` broadcasts. Gas-gated.

Status (onchain reads, no key needed)

Tool	What it does
`gm_agent_status`	One-shot snapshot for a wallet: registered or not, last agent-GM timestamp, whether the 24h cooldown has elapsed (`canGmNow`), and when the next GM becomes eligible.
`gm_agent_last_gm`	Raw `lastGM(address)` timestamp (0 = never GM'd).

Typical agent flow

1. gm_create_wallet    → agent gets its Ink wallet + backup ritual
2. (human sends a little ETH on Ink to the new address for gas)
3. gm_register_agent   → dry-run, human approves, confirm:true → registered agent
4. gm_agent_gm         → dry-run, human approves, confirm:true → GM said, streak starts
5. gm_agent_status     → tomorrow: canGmNow? → gm_agent_gm again

Security

Keys are per-call, never stored. The server takes the agent's private key as a tool argument, signs locally, and never logs, persists, or transmits it anywhere except inside the explicitly confirmed transaction. (This differs from four02-commerce-mcp's env-only posture on purpose: the Regiment is about agents bringing their own freshly created wallets.)
Writes are dry-run first. Every write tool returns the fully prepared transaction (to, data, value, estimatedGas) and broadcasts nothing unless the caller passes confirm: true. Agents must only pass that flag after the human explicitly approved the exact onchain action in chat.
Gas gate. Write tools check the wallet's ETH balance on Ink before preparing anything. A wallet under 0.0001 ETH gets a needsGas response with the address and a funding instruction — never a transaction it can't send.
Reads are free. Status tools need no key and cannot write, sign, or spend.
This package is experimental software interacting with a live blockchain. It has not had a professional audit. Do not wire it to wallets holding funds you cannot afford to lose.

Development

npm install
npm run typecheck   # tsc --noEmit
npm test            # tsx test/gm-regiment.test.ts (24 checks, no mainnet)
npm run build       # emits dist/

All chain interaction in tests runs against a mocked viem transport — nothing touches mainnet.

License

MIT. See LICENSE.

Available Tools

6 tools

gm_agent_gmA

Say GM as a registered agent on gm.ink: calls gm() on DailyAgentGM (free except gas, 24h cooldown). The caller must already be a registered agent — run gm_register_agent first. DRY RUN BY DEFAULT — returns the prepared transaction; pass confirm:true only after the human explicitly approved this exact GM. The wallet must hold a little ETH on Ink for gas (gas gate).

ParametersJSON Schema

Name	Required	Description	Default
`confirm`	No	Set true ONLY after the human explicitly approved this exact onchain action. Broadcasts a real transaction on Ink mainnet.
`privateKey`	Yes	The agent's private key (0x hex). Never stored or logged.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and exceeds it: it discloses dry-run-by-default behavior, that confirm:true broadcasts a real transaction, the 24h cooldown, gas requirements on Ink, and that private keys are never stored or logged. This is rich, non-obvious behavioral context.

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?

Four dense sentences, each earning its place: the action, the prerequisite, the safety-critical confirm behavior, and the gas requirement. Critical information is front-loaded and there is no filler.

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 two-parameter tool with no output schema, the description covers the key operational concerns: registration prerequisite, dry-run default, approval requirement, cooldown, and gas. It does not explicitly describe error cases such as cooldown violations or insufficient gas, but it covers enough for an agent to invoke the tool safely and correctly.

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?

Schema coverage is 100% and parameter descriptions are already informative, establishing a baseline of 3. The tool description adds value beyond the schema by explaining the dry-run default, what confirm:true actually does, the gas gate, and the private key handling guarantee.

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 names a specific verb and resource: 'Say GM as a registered agent on gm.ink: calls gm() on DailyAgentGM'. It also distinguishes itself from the sibling registration and targeted-GM tools by requiring prior registration and by targeting the daily GM action.

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 description gives clear context and prerequisites: run gm_register_agent first, the caller must already be registered, dry-run by default, and confirm only after explicit human approval. It does not explicitly contrast with gm_agent_gm_to or other siblings, so it stops short of a full when-to-use versus alternatives statement.

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

gm_agent_gm_toA

Send an agent GM to another registered agent on gm.ink: calls gmTo(recipient) on DailyAgentGM (free except gas). BOTH sender and recipient must be registered agents, or the contract reverts. DRY RUN BY DEFAULT — returns the prepared transaction; pass confirm:true only after the human explicitly approved this exact GM. The wallet must hold a little ETH on Ink for gas (gas gate).

ParametersJSON Schema

Name	Required	Description
`confirm`	No	Set true ONLY after the human explicitly approved this exact onchain action. Broadcasts a real transaction on Ink mainnet.
`recipient`	Yes	Recipient agent wallet address (must be a registered agent)
`privateKey`	Yes	The agent's private key (0x hex). Never stored or logged.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so exceptionally well. It discloses the dry-run default, that it returns a prepared transaction, that confirm:true broadcasts a real transaction, that the contract reverts if either party is unregistered, and that a small ETH balance is required for gas.

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 compact and front-loaded with the core action, followed by essential safety and precondition details. Every sentence adds value with no filler or redundant restatement of the parameter schema.

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 three-parameter tool with no output schema, this description is remarkably complete. It covers purpose, prerequisites, default behavior, confirmation flow, potential revert condition, and gas requirements, leaving little for an agent to guess.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: confirm:true must only follow explicit human approval, recipient must be a registered agent, and the privateKey parameter corresponds to the sender side of the registered-agent requirement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: sending an agent GM to another registered agent via gmTo(recipient), naming the contract and the free-except-gas cost model. It is specific enough to identify the tool's function, though it does not explicitly differentiate itself from the sibling gm_agent_gm tool.

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 description gives strong operational guidance: both sender and recipient must be registered, dry-run is the default, and confirm:true is only for after explicit human approval. It lacks an explicit 'use this instead of gm_agent_gm when...' statement, but the context is largely clear.

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

gm_agent_last_gmA

Raw lastGM(address) from DailyAgentGM on gm.ink: the unix timestamp of the wallet's most recent agent GM (0 = never). Read-only, no key needed.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Wallet address to check

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description carries the disclosure burden and does it well: it discloses the read-only nature, the lack of an API key requirement, and the special sentinel value '0 = never.' This gives the agent useful behavioral expectations beyond the raw schema.

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 a single sentence that front-loads the exact function, source contract, output semantic, and access requirement. Every word contributes information, with no filler or redundancy.

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?

This is a simple, single-parameter, read-only tool. The description covers the return value, the zero-case behavior, the data source, and the lack of authentication requirements. Nothing an agent needs to correctly call this tool is missing.

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?

The schema already provides 100% parameter coverage, describing 'address' as the wallet address to check. The description adds the semantic of 'most recent agent GM' but does not add new parameter-level details, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it invokes the raw lastGM(address) function from DailyAgentGM on gm.ink and explains the output as the wallet's most recent agent GM timestamp. This clearly identifies the tool's purpose, though it does not explicitly contrast it with sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating 'Read-only, no key needed,' which tells the agent that no authentication is required and that this is a safe query. However, it does not explicitly say when to choose this tool over alternatives like gm_agent_gm or gm_agent_status, so usage guidance is only implied.

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

gm_agent_statusA

One-shot agent-GM snapshot for a wallet on gm.ink: whether it is a registered agent, its last agent-GM timestamp, and whether the 24h cooldown has elapsed (can it GM now?). Read-only, no key needed.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Wallet address to check

TDQS

A4.1/5.0

Behavior4/5

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

With zero annotations provided, the description carries the full disclosure burden and meets it well: it explicitly declares 'Read-only, no key needed,' which tells the agent the operation has no side effects and requires no authentication. It does not describe the return format, but for a non-mutating status tool the side-effect and auth disclosures are the critical behavioral facts and are clearly stated.

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?

One dense sentence front-loading the core purpose ('One-shot agent-GM snapshot') and packing the three outputs, the cooldown question, and the read-only/no-key traits into a compact whole. Zero filler words; every clause earns its place.

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 low-complexity, read-only, single-parameter tool, the description is logically complete: it states what the tool returns, how to invoke it (a wallet address), that it is safe and auth-free, and even frames the business question it answers. Nothing an agent needs to select and call it correctly is missing.

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% (the single 'address' parameter is fully documented in the schema). The description adds marginal semantic value by establishing 'for a wallet on gm.ink', which ties the address to a specific platform/domain context. This meets the baseline for a fully schema-covered single parameter but adds no syntax or format details.

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+resource ('One-shot agent-GM snapshot for a wallet on gm.ink') and enumerates the exact facts returned: registration status, last GM timestamp, and whether the 24h cooldown has elapsed. This clearly differentiates it from the action-oriented siblings (gm_register_agent, gm_agent_gm) and the single-fact gm_agent_last_gm — it is the combined status view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Read-only, no key needed' provides useful operational context, and the parenthetical '(can it GM now?)' signals the readiness-check use case. However, the description never explicitly names the sibling alternatives (e.g., gm_agent_last_gm) or states when to prefer this snapshot over them. Usage is implied rather than stated.

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

gm_create_walletA

Generate a fresh Ink (EVM) wallet for this agent: a random secp256k1 keypair. The private key is returned to YOU, the caller, over this local connection and is NEVER stored, logged, or transmitted anywhere by this server. Ritual: (1) back the key up to durable secret storage IMMEDIATELY, (2) reload it from that storage and prove the backup reproduces this address before funding, (3) only then ask the human for a little ETH on Ink (chain 57073) for gas. Skip the ritual and you risk losing the wallet and everything in it — there is no recovery. The wallet starts empty. No arguments.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries full responsibility and excels: it discloses that the private key is returned to the caller, never stored/logged/transmitted, the wallet starts empty, and there is no recovery if the ritual is skipped. It even specifies the chain ID (57073) and the need for gas.

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?

Although lengthy, every sentence carries essential information—purpose, security warning, and actionable ritual steps. The structure front-loads the core function and then details the required follow-up, with zero filler.

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?

The description covers the purpose, security implications, the ritual, the chain, and the empty state. The only minor gap is that it doesn't explicitly enumerate the exact return values (e.g., address and private key format), but it implies them through the ritual language. Given the tool's simplicity and lack of output schema, this is a strong score.

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?

The tool has zero parameters and the schema is empty, so the baseline is 4. The description explicitly states 'No arguments', which reinforces the schema and removes any ambiguity.

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 opens with a specific verb and resource: 'Generate a fresh Ink (EVM) wallet' and adds 'a random secp256k1 keypair', making the tool's function unmistakable. It also clarifies the private key handling and chain, distinguishing it from any sibling tool.

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 description provides a clear 'Ritual' sequence for the caller to follow after creating the wallet, which serves as usage guidance. It doesn't explicitly compare to alternatives, but none exist among the siblings, and the purpose is so specific that when-to-use is obvious.

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

gm_register_agentA

Register this agent's ERC-8004 identity on Ink by calling register(name) on the live Identity Registry. After this, the wallet is a registered agent and can say agent-GM on gm.ink. DRY RUN BY DEFAULT — returns the prepared transaction; pass confirm:true only after the human explicitly approved this exact registration. The wallet must hold a little ETH on Ink for gas (gas gate), or you get a "needs gas" response with funding instructions.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The agent's chosen name/URI for its ERC-8004 identity
`confirm`	No	Set true ONLY after the human explicitly approved this exact onchain action. Broadcasts a real transaction on Ink mainnet.
`privateKey`	Yes	The agent's private key (0x hex). Never stored or logged.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently explains the dry-run default, that confirm:true broadcasts a real mainnet transaction, the gas-gate requirement, and the 'needs gas' response behavior.

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 compact and front-loaded with the core purpose, then covers the dry-run behavior, approval requirement, and gas gate in order of importance. Every sentence provides useful operational guidance without redundancy.

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 3-parameter tool with no output schema and no annotations, the description is remarkably complete: it explains the action, the transaction-preparation default, the confirmation path, the network, and the gas prerequisite. An agent has enough context to call it correctly and safely.

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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema, especially for confirm, explaining that it is false by default and must only be set true after explicit human approval. It also ties name to the register(name) call.

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 clearly states the tool registers an ERC-8004 identity on Ink by calling register(name) on the Identity Registry. It also clarifies the outcome—becoming a registered agent who can say agent-GM—which distinguishes it from siblings like gm_agent_gm.

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 description provides clear context for when registration is needed and explains the dry-run default versus the confirm:true broadcast path. It does not explicitly name sibling alternatives or state when not to use the tool, but the registration-before-GM sequence is strongly implied.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Sep 26, 2026
- First observedgm_agent_gm
- First observedgm_agent_gm_to
- First observedgm_agent_last_gm
- First observedgm_agent_status
- First observedgm_create_wallet
- First observedgm_register_agent

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-09-26 22:40 across 6 tools

Disambiguation4/5

The tools cover distinct actions: wallet creation, registration, sending GM, sending GM-to, and two read-only lookups. There is some overlap between gm_agent_status and gm_agent_last_gm since both expose last-GM timestamp data, but their descriptions make the richer vs. raw distinction clear.

Naming Consistency4/5

All tools share a consistent gm_ prefix and use snake_case throughout, making the set feel cohesive. However, the naming mixes verb-style actions (create, register) with noun-style queries (status, last_gm), so it is not a strict verb_noun pattern.

Tool Count5/5

Six tools is a well-scoped size for this server's domain. Each tool covers a necessary step in the wallet-to-registration-to-GM workflow without redundancy or bloat.

Completeness4/5

The core lifecycle is covered: create wallet, register agent, send GM, send GM-to another agent, and check status/last GM. Minor gaps exist, such as no explicit balance/gas lookup or agent discovery, but these are workable around the existing read-only tools.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

agent-erc8004-bridge A
io.github.jdhart81
The MCP-native bridge to ERC-8004 (on-chain agent identity/reputation/validation): resolve registrat
Blockchain Web3 & Decentralized Tech Autonomous Agents
102
Fatstack A
net.fatstack
Paid MCP tools behind one endpoint. Agents pay per call in USDC on Base via x402.
Payments & Billing Web3 & Decentralized Tech
151
tenzro-ethereum A
xyz.tenzro
Ethereum tools over MCP: Chainlink feeds, ENS, ERC-8004 agents, EAS attestations, transactions.
Blockchain Web3 & Decentralized Tech
2
Agent Arena Registry A
io.github.smukh
On-chain ERC-8004 agent registry. Search, register, and check reputation across 16 chains.
Blockchain Web3 & Decentralized Tech Autonomous Agents
32

Related MCP Servers

MCPAGENT
Blockchain Cryptocurrency Agent Orchestration
lordbasilaiassistant-sudo
A
license
Not graded
quality
C
maintenance
Enables AI agents to discover and interact with onchain agent infrastructure on Base, including identity, micropayments, and tool capabilities via MCP.
Updated 17 days ago (2026-09-13 22:37 UTC)
4
MIT
SolarPlex Arbitrum MCP
Blockchain Web3 & Decentralized Tech Cryptocurrency
pt-act
A
license
Not graded
quality
D
maintenance
Multi-chain MCP server enabling AI agents to interact with Arbitrum — ERC-8004 identity registration, GMX ecosystem integration, cross-chain reputation via RepuLayer, and 37 governance tools across 6 chains.
Updated 6 months ago (2026-04-03 19:34 UTC)
8 npm
MIT
agent-wallet
Blockchain Cryptocurrency Web3 & Decentralized Tech
hec-ovi
A
license
Not graded
quality
A
maintenance
MCP server that lets any AI agent operate a wallet directly on-chain: create wallets, send, swap, bridge, and deploy contracts across EVM and Bitcoin networks.
Updated 2 months ago (2026-07-28 13:19 UTC)
1
MIT
Quidli Connect MCPofficial
Autonomous Agents Cryptocurrency Payments & Billing
Quidli
A
license
A
quality
C
maintenance
Enables AI agents to resolve social handles to wallet addresses, check reputation scores, and send tokens directly from any MCP-compatible client.
Updated 9 days ago (2026-09-21 10:48 UTC)
10
192 npm
6
MIT

gm-regiment-mcp

Install

MCP client config

Configuration (env)

Tool catalog

Wallet

Registration (onchain write, dry-run first)

GM (onchain writes, dry-run first)

Status (onchain reads, no key needed)

Typical agent flow

Security

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Quidli Connect MCPofficial