I used the same url for two different postings.
Bridges USDC cross-chain from Arc Mainnet via Circle CCTP ($0.25 USDC)
| Name | Required | Description | Default |
|---|---|---|---|
| amountUsdc | Yes | Amount of USDC to bridge | |
| destinationChain | Yes | Destination chain name | |
| recipientAddress | Yes | Recipient address on destination chain |
| Name | Required | Description | Default |
|---|---|---|---|
| success | Yes | Bridge status | |
| burnTransactionHash | Yes | CCTP depositForBurn tx hash |
Changes observed during successful MCP inspections.
Input schema / properties / amountUsdc / descriptionAdded value: +"Amount of USDC to bridge"Input schema / properties / destinationChain / descriptionAdded value: +"Destination chain name"Input schema / properties / recipientAddress / descriptionAdded value: +"Recipient address on destination chain"Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "burnTransactionHash": {
+ "description": "CCTP depositForBurn tx hash",
+ "type": "string"
+ },
+ "success": {
+ "description": "Bridge status",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "success",
+ "burnTransactionHash"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, implying mutation, and the description explicitly states the fee ($0.25 USDC). It also mentions the mechanism (CCTP) which implies a cross-chain messaging protocol. It does not disclose potential delays or failure modes, but the fee statement adds transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that packs the essential information: the action, the asset, the source, the mechanism, and the fee. No wasted words, and the most critical detail (cost) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown but indicated) and a detailed input schema with enums for destinationChain, the description sufficiently covers the tool's purpose and cost. It could mention potential slippage or confirmation times, but the provided details are adequate for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters like amountUsdc, destinationChain, and recipientAddress are already described. The description adds no additional semantics, but since coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bridging USDC), the source chain (Arc Mainnet), the mechanism (Circle CCTP), and the cost ($0.25 USDC), distinguishing it from other bridge or swap tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for cross-chain USDC transfers from Arc Mainnet), but does not explicitly state when not to use it or mention alternatives (e.g., other bridging mechanisms). However, the clear source and mechanism provide good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.