MolTrust MCP Server

mt_create_interaction_proof

Create an interaction proof before issuing a SkillEndorsementCredential.

Returns evidence_hash and base_tx_hash anchored on Base L2.
Required before calling mt_endorse_agent. Valid for 72 hours.

Args:
    api_key: MolTrust API key of the agent creating the proof
    agent_a: DID of the first agent in the interaction
    agent_b: DID of the second agent in the interaction
    interaction_type: Type of interaction (e.g. skill_verification, purchase, prediction)
    outcome: Outcome of the interaction: success or failure

Input Schema

TableJSON Schema

Name	Required	Default
`agent_a`	Yes
`agent_b`	Yes
`api_key`	Yes
`outcome`	No	success
`interaction_type`	No	skill_verification

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.5/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 full burden. It discloses the return values (evidence_hash, base_tx_hash), the blockchain (Base L2), and the validity period (72 hours). It also indicates this is a creation (mutation) operation. However, it does not detail potential side effects, idempotency, or error conditions, which would be valuable for a transaction-creating tool.

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 concise and well-structured. The first two sentences convey purpose and key returns, followed by the dependency and validity. Parameter explanations are listed compactly. There is no redundancy, and the most critical information is front-loaded.

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 purpose, usage prerequisite, validity, return values, and parameter semantics. It is complete for a tool of this complexity. Minor gaps include lack of mention of error handling, expiry behavior, or required permissions beyond the api_key. Given the presence of an output schema and the clarity of the description, it is sufficiently complete.

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

Parameters5/5

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

The description provides detailed semantics for all five parameters: api_key, agent_a, agent_b, interaction_type, and outcome. It even includes examples for interaction_type and outcome. Since the schema itself has no descriptions (0% coverage), this is essential and fully compensates. Each parameter's meaning is clarified beyond just name and type.

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 specific action ('Create an interaction proof') and its context ('before issuing a SkillEndorsementCredential'). It also names the dependent sibling tool (mt_endorse_agent), distinguishing this tool's purpose. The mention of return values (evidence_hash, base_tx_hash) further clarifies its function.

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 explicitly states when to use this tool: 'Required before calling mt_endorse_agent' and 'Valid for 72 hours.' This provides clear timing and a prerequisite. It does not mention alternatives, but given the sibling list, this tool is a unique step in the workflow, so that is acceptable. The guidance is strong but not exhaustive.

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 tools Inspect

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.