Skip to main content
Glama
assetfare

assetfare

by assetfare
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

assetfare_prepare_cctp_action

Idempotent

Prepare the unsigned CCTP burn for a legacy v1 session using a caller-owned event signer public key, advancing preparation state without signing or submitting.

Instructions

Prepare the unsigned CCTP burn for the current legacy v1 session using a caller-owned event signer public key. Use only when the legacy workflow reports this as the next action; for v2 routes use assetfare_v2_prepare or assetfare_v2_session_create instead. Requires caller approval and advances preparation state, but never receives the event signer private key, signs, or submits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYesLegacy v1 session UUID returned by assetfare_create_session. Use only with the unversioned legacy workflow; do not pass a v2 session ID.
access_tokenYesSensitive legacy v1 wallet-bound bearer token returned by assetfare_finish_wallet_auth. Use only with unversioned legacy session tools; never log or use it as a v2 session capability.
idempotency_keyYesCaller-generated retry key, 8-128 characters. Reuse it only when retrying the same logical mutation; choose a new key for a new operation.
event_signer_publicYesFresh caller-generated ephemeral Solana event signer public key for the legacy CCTP burn. Keep the matching private key client-side; never send it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, and the description adds important context: it requires caller approval, advances preparation state, and never receives the event signer private key, signs, or submits. This meaningfully clarifies the safety and state-change profile beyond the annotation hints.

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?

Three sentences with no filler: the action is front-loaded, usage routing is precise, and the security boundary is stated compactly. Every sentence earns its place.

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 is complete enough for selecting and invoking the tool correctly, given strong schema coverage and annotations. It could be slightly stronger by indicating what the caller should expect as a result, especially since no output schema is present, but the core usage and safety context are well covered.

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 params are already well-documented. The tool description reinforces that the event signer is caller-owned, but this largely repeats the schema's existing 'caller-generated' and 'never send it' guidance, adding little new semantic value.

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 states a specific verb ('Prepare'), a clear resource ('unsigned CCTP burn'), and explicit scope ('current legacy v1 session'). It also distinguishes itself by noting what it never does—sign or submit—and implicitly differentiates from v2 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 Guidelines5/5

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

The description explicitly says to use it only when the legacy workflow reports it as the next action and names the v2 alternatives (assetfare_v2_prepare or assetfare_v2_session_create). This leaves no ambiguity about when this tool should be selected.

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

Deploy Server

Other Tools