MolTrust MCP Server

mt_travel_issue_vc

Destructive

Issue a TravelAgentCredential (W3C Verifiable Credential) for a booking agent.

Creates a cryptographically signed credential that authorizes an AI agent
to book travel on behalf of a principal (company/human), with enforced
segment permissions and spend limits.

Args:
    agent_did: DID of the travel agent (e.g. "did:base:0x...")
    principal_did: DID of the authorizing entity (e.g. "did:base:acme-corp")
    segments: Comma-separated allowed segments (e.g. "hotel,flight,car_rental")
    spend_limit: Maximum spend amount per booking
    currency: Currency code (e.g. "USDC")
    traveler_name: Name of the authorized traveler (optional)
    validity_days: Number of days the credential is valid (default 30)

Input Schema

Name	Required	Description
`currency`	Yes	Currency code (e.g. "USDC")
`segments`	Yes	Comma-separated allowed segments (e.g. "hotel,flight,car_rental")
`agent_did`	Yes	DID of the travel agent (e.g. "did:base:0x...")
`spend_limit`	Yes	Maximum spend amount per booking
`principal_did`	Yes	DID of the authorizing entity (e.g. "did:base:acme-corp")
`traveler_name`	No	Name of the authorized traveler (optional)
`validity_days`	No	Number of days the credential is valid (default 30)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 28, 2026

addedInput schema / properties / agent_did / description

Added value: +"DID of the travel agent (e.g. \"did:base:0x...\")"

addedInput schema / properties / currency / description
```
Added value: +"Currency code (e.g. \"USDC\")"
```

addedInput schema / properties / principal_did / description

Added value: +"DID of the authorizing entity (e.g. \"did:base:acme-corp\")"

addedInput schema / properties / segments / description

Added value: +"Comma-separated allowed segments (e.g. \"hotel,flight,car_rental\")"

addedInput schema / properties / spend_limit / description
```
Added value: +"Maximum spend amount per booking"
```

addedInput schema / properties / traveler_name / description

Added value: +"Name of the authorized traveler (optional)"

addedInput schema / properties / validity_days / description

Added value: +"Number of days the credential is valid (default 30)"

First observedSep 22, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already flag a non-idempotent, destructive write, and the description adds real context: the output is a cryptographically signed credential, permissions and spend limits are enforced inside it, and validity is time-bounded. It stops short of stating side effects such as whether a new credential supersedes a prior one or what authorization the caller needs.

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 three-sentence summary is well front-loaded and earns its place, but the seven-item Args block duplicates the schema verbatim at 100% coverage, adding length without information.

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?

With an output schema available, return shape need not be described, and annotations plus the description cover the write's safety profile and semantics. The main remaining gap is lifecycle behavior — whether issuing again invalidates prior credentials and what the caller must hold to issue.

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 largely restates identical text ('DID of the travel agent', 'Comma-separated allowed segments', etc.) without adding format constraints, valid segment values, or currency semantics. Baseline 3 applies when the schema already does the documentation work.

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?

Opens with a specific verb+resource ('Issue a TravelAgentCredential') and immediately defines what the credential is (a W3C Verifiable Credential authorizing an AI booking agent on behalf of a principal). This clearly separates it from mint/verify/info siblings such as mt_travel_verify, mt_travel_info, and mt_skill_issue_vc.

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?

Usage is implied by the word 'Issue' and by the described effect (authorizes an agent with segment and spend limits), but the description never states when to call it versus mt_travel_verify, mt_travel_info, or the parallel *_issue_vc tools. No preconditions (e.g. a prior registration or funding step) are mentioned.

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.