Skip to main content
Glama
Sign In

MolTrust MCP Server

by io.github.MoltyCel
OverviewDiscussionsAdmin

moltrust_register

Destructive

Register a new AI agent on MolTrust.

Creates a decentralised identity (DID), issues a W3C Verifiable Credential,
and anchors the agent on the Base blockchain.

Args:
    display_name: Agent name (1-64 chars, alphanumeric/dash/underscore/dot/space)
    platform: Platform identifier (e.g. "openai", "langchain", "custom")

Input Schema

NameRequiredDescriptionDefault
platformYesPlatform identifier (e.g. "openai", "langchain", "custom")
display_nameYesAgent name (1-64 chars, alphanumeric/dash/underscore/dot/space)

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / display_name / description
      Added value: +"Agent name (1-64 chars, alphanumeric/dash/underscore/dot/space)"
    • addedInput schema / properties / platform / description
      Added value: +"Platform identifier (e.g. \"openai\", \"langchain\", \"custom\")"
  2. First observed

TDQS

B3.1/5.0
Behavior3/5

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

The description adds real context beyond annotations: it discloses that a DID and verifiable credential are created and that the agent is anchored on the Base blockchain, which signals persistence. However, with destructiveHint=true and idempotentHint=false already declared, it never warns about irreversibility, cost, or what happens on repeat/duplicate registration calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence and the three-line summary of created artifacts are well front-loaded and earn their place. The trailing 'Args:' section duplicates the input schema word-for-word and is pure filler.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and the description adequately covers what is created. But for a non-idempotent, destructive, blockchain-writing operation in a crowded sibling namespace, the absence of cost/permission/irreversibility guidance leaves meaningful gaps.

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%, so the 'Args' block is a verbatim restatement of the schema's own parameter descriptions and adds no new meaning (no format examples or normalization notes). Baseline 3 applies when the schema carries the semantic load.

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 opening sentence states a specific verb and resource ('Register a new AI agent on MolTrust') and the body enumerates the concrete artifacts produced (DID, W3C Verifiable Credential, Base blockchain anchor). It is distinguishable from moltrust_verify/moltrust_credential by naming, though it does not explicitly contrast with sibling registrar tools like mt_register_seed or mt_salesguard_register.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus the many sibling registration/verification tools, and no prerequisites (funding, credits, wallet, prior deposit) are mentioned. The agent must infer usage context entirely from the name.

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

All MolTrust MCP Server toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources