MolTrust MCP Server

mt_shopping_verify

Read-only

Verify a shopping transaction against a BuyerAgentCredential.

Checks the credential signature, spend limits, trust score, and
returns a verification receipt with approval status.

Args:
    credential_jws: JWS compact serialization of the BuyerAgentCredential
    transaction_amount: Transaction amount (e.g. 189.99)
    transaction_currency: Currency code (e.g. "USDC")
    merchant_id: Merchant identifier string
    item_description: Description of the item being purchased

Input Schema

Name	Required	Description
`merchant_id`	Yes	Merchant identifier string
`credential_jws`	Yes	JWS compact serialization of the BuyerAgentCredential
`item_description`	Yes	Description of the item being purchased
`transaction_amount`	Yes	Transaction amount (e.g. 189.99)
`transaction_currency`	Yes	Currency code (e.g. "USDC")

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 28, 2026
- addedInput schema / properties / credential_jws / description
```
Added value: +"JWS compact serialization of the BuyerAgentCredential"
```
- addedInput schema / properties / item_description / description
```
Added value: +"Description of the item being purchased"
```
- addedInput schema / properties / merchant_id / description
```
Added value: +"Merchant identifier string"
```
- addedInput schema / properties / transaction_amount / description
```
Added value: +"Transaction amount (e.g. 189.99)"
```
- addedInput schema / properties / transaction_currency / description
```
Added value: +"Currency code (e.g. \"USDC\")"
```
First observedSep 22, 2026

TDQS

A3.5/5.0

Behavior4/5

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

readOnlyHint=true is consistent with a verification operation, so the description need not re-establish the safety profile. It goes beyond annotations by disclosing the specific checks performed (signature, spend limits, trust score) and that a verification receipt with approval status is produced, though it omits what happens on failed verification and any auth or latency requirements.

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 opening sentences are well front-loaded and information-dense, but the Args section restates the five input-schema descriptions word for word, which is pure redundancy given 100% schema coverage.

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 described, and the summary of checks is helpful. However, for a security-critical verification tool with only a readOnlyHint annotation, the definition leaves open the failure semantics (does denial return a receipt with approval status false, or raise an error?) and whether the credential must be issued by a specific sibling first.

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% and the Args block duplicates the schema descriptions verbatim ('Merchant identifier string', 'Transaction amount (e.g. 189.99)'), adding no new semantics. The one small gain is illuminating what credential_jws should be a credential of, which the schema already states. Baseline 3 applies.

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 uses a specific verb+resource ('Verify a shopping transaction against a BuyerAgentCredential') and enumerates what is checked (signature, spend limits, trust score). It does not explicitly name sibling tools such as mt_shopping_issue_vc or mt_shopping_info, so differentiation relies on naming convention rather than stated contrast.

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 only implied: an agent can infer this is the step after issuing a shopping credential, but the description states no prerequisites (e.g. do you need a credential from mt_shopping_issue_vc first?) and no when-not conditions or alternatives.

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.