Which integrations are available for this server?

Provides tools for checking balances and executing transfers of Tether (USDT) tokens on the Rootstock blockchain.

How do I use RSK MCP Server - Rootstock Blockchain Tools?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RSK MCP Server - Rootstock Blockchain Tools check my rBTC balance for wallet address 0x123...abc" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

RSK MCP Server - Rootstock Blockchain Tools

Official

by rsksmart

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

OpenSSF Scorecard CodeQL

RSK MCP Server - Rootstock Blockchain Tools

Rootstock MCP Server is a Model Context Protocol (MCP) server that provides advanced tools for interacting with the Rootstock (RSK) blockchain. This project enables AI clients to seamlessly connect and execute blockchain operations.

🚀 Key Features

💼 Wallet Management: Create, import, switch and manage multiple wallets
💰 Balance Queries: Check rBTC and ERC20 token balances
💸 Transfers: Send rBTC and tokens to other addresses
🔍 Transaction Tracking: Verify transaction status by hash
🚀 Contract Deployment: Deploy smart contracts on Rootstock
✅ Contract Verification: Verify deployed contracts
📄 Contract Interaction: Read data from verified contracts
📊 History: Query transaction history
🎯 Attestations: Create, verify, and manage attestations using RAS (Rootstock Attestation Service)
🏗️ Schema Management: Create and manage attestation schemas
📝 Attestation Queries: List and filter attestations by various criteria

Related MCP server: Base MCP Server

🧰 Available Tools

This server exposes 22 MCP tools. You don't call these directly — once the MCP is connected, your AI client selects the right tool based on your prompt.

Category	Tool	Description
Session	`start-interaction`	Start interacting with the Rootstock CLI functions
Session	`list-pending-operations`	List pending operations awaiting confirmation (deploys, transfers)
Session	`confirm-operation`	Confirm and execute a pending operation by ID
Session	`cancel-operation`	Cancel a pending operation by ID
Wallet	`start-wallet-interaction`	Show available wallet management operations
Wallet	`create-wallet`	Create, import, list, switch, or delete wallets
Wallet	`use-wallet-from-creation`	Reuse wallet data from a previous `create-wallet` result without re-uploading it
Balance	`check-balance`	Check rBTC or ERC20 token balances
Transfers	`transfer-tokens`	Transfer rBTC or ERC20 tokens between wallets
Transactions	`check-transaction`	Check a transaction's status and details by hash
Transactions	`check-transaction-history`	Query a wallet's transaction history via the Alchemy API
Contracts	`deploy-contract`	Deploy a smart contract using ABI and bytecode
Contracts	`verify-contract`	Verify a deployed contract's source code
Contracts	`read-contract`	Call view/pure functions on a verified contract
Attestations	`issue-attestation`	Issue a new attestation via RAS (Rootstock Attestation Service)
Attestations	`verify-attestation`	Verify an existing attestation by UID
Attestations	`revoke-attestation`	Revoke an existing attestation by UID
Attestations	`list-attestations`	Query attestations by event logs (requires a custom RPC URL)
Attestations	`create-schema`	Register a new attestation schema
Attestations	`attest-deployment`	Attest a contract deployment using the RAS default schema
Attestations	`attest-verification`	Attest a contract verification using the RAS default schema
Attestations	`attest-transfer`	Attest a token transfer using the RAS default schema

See Detailed Functionality below for parameters and examples.

📋 Prerequisites

Node.js v18 or higher
npm or yarn
TypeScript (included in dev dependencies)

Note: You will use this Model Context Protocol Server from a LLM Client (e.g Cursor, Claude, Warp, etc) which needs to be compatible with the MCP standard. Take into account there are 2 steps here:
Installation and Build
AI Client Configuration

IMPORTANT: You need to complete both settings to correctly use MCP within the Client.

🛠️ Installation and Build

1. Clone the Repository

git clone https://github.com/rsksmart/rsk-mcp-server
cd rsk-mcp-server

2. Install Dependencies

npm install

3. Build the Project

npm run build

This command:

Compiles TypeScript to JavaScript in the build/ folder
Makes the main file executable (build/index.js)

4. Verify Installation

node build/index.js

Important Note: For local running this MCP, your client will point to the index.js file created on the build folder after building it.

⚙️ AI Client Configuration

🏠 Remote Configuration

For Cursor IDE

In Cursor, go to Settings > Cursor Settings > Tools & Integrations

You will see an option to Add Custom MCP

And add to the JSON file:

{
  "mcpServers": {
    "rsk-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "@rsksmart/rsk-mcp-server"
      ]
    }
  }
}
// The Args field contains the path to the index.js file created by the build.

Note: For install reference on Cursor, please follow these instructions Here

Once it is installed into Cursor, you should see something like:

Green dot indicates it was installed correctly.

For Claude Desktop (Anthropic)

Edit your Claude Desktop configuration file:

Open your Claude client, and then click on Settings/Developer

Click the “Edit Config” button to open the configuration file and add the following configuration:

Note: This action creates a new configuration file if one doesn’t exist, or opens your existing configuration. The file is located at:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "rsk-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "@rsksmart/rsk-mcp-server"
      ]
    }
  }
}
// The Args field contains the path to the index.js file created by the build.

Note: For install reference on Claude, please follow these instructions Here

Once you have installed this MCP on the Claude client, you will see it once you click on the Search and toolsoption under Web search option (see next image)

🏠 Local Configuration

For Cursor IDE

In Cursor, go to Settings > Cursor Settings > Tools & Integrations

You will see an option to Add Custom MCP

And add to the JSON file:

{
  "mcpServers": {
    "rsk-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/your/project/rsk-mcp-server/build/index.js"]
    }
  }
}
// The Args field contains the path to the index.js file created by the build.

Note: For install reference on Cursor, please follow these instructions Here

Once it is installed into Cursor, you should see something like:

Green dot indicates it was installed correctly.

For Claude Desktop (Anthropic)

Edit your Claude Desktop configuration file:

Open your Claude client, and then click on Settings/Developer

Click the “Edit Config” button to open the configuration file and add the following configuration:

Note: This action creates a new configuration file if one doesn’t exist, or opens your existing configuration. The file is located at:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "rsk-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/your/project/rsk-mcp-server/build/index.js"],
      "env": {}
    }
  }
}
// The Args field contains the path to the index.js file created by the build.

Note: For install reference on Claude, please follow these instructions Here

Once you have installed this MCP on the Claude client, you will see it once you click on the Search and toolsoption under Web search option (see next image)

For Other MCP Implementations

Any MCP-compatible client can connect using:

node /path/to/project/rsk-mcp-server/build/index.js

🌐 Remote Configuration (URL)

Note: This functionality will be available when the server is deployed to a public endpoint.

Remote Client Configuration

{
  "mcpServers": {
    "rsk-mcp": {
      "url": "https://your-server.com/mcp-endpoint",
      "headers": {
        "Authorization": "Bearer your-api-key"
      }
    }
  }
}

🔧 Detailed Functionality

Once this MCP is installed on the client, you will be able to interact with it by prompt, using chat box, for example, a good prompt to start interacting with this MCP is to write a prompt like: I would like to start interacting with Rootstock

Then it will require you to give permission to use the MCP tool, you click on accept, and then it should answer something like:

Perfect! The Rootstock CLI is now active and ready to help you interact with the Rootstock blockchain. Here are the available options:
Available Rootstock Operations:
💼 wallet - Manage your wallet (create new, use existing, or import)
💰 balance - Check wallet balances
💸 transfer - Transfer RBTC or ERC20 tokens
🔍 tx - Check transaction status
🚀 deploy - Deploy a smart contract
✅ verify - Verify a contract
📄 contract - Interact with a contract
📊 history - Check transaction history
❓ help - Display help
What would you like to do? If you don't have a wallet yet, I'd recommend starting with option 1 (wallet management) to create or import a wallet first. Then you can proceed with other operations like checking balances, transferring tokens, or deploying contracts.
Which option interests you?

You can continue the flow according to what you need to do.

1. 🧭 Session & Interaction

Available Tools:

start-interaction: Entry point tool — start here when a user first asks about Rootstock. Lists all available operations.
list-pending-operations: List operations awaiting confirmation (contract deployments, token transfers)
confirm-operation: Confirm and execute a pending operation using its operation ID
cancel-operation: Cancel and discard a pending operation using its operation ID

Why confirmation is needed: Critical operations like deploy-contract and transfer-tokens require a confirmAction boolean on every call — omitting it fails schema validation. Passing confirmAction: false creates a pending operation (expires after 5 minutes) instead of executing, and nothing happens on-chain until it's confirmed via confirm-operation. Passing confirmAction: true on the first call skips that pending step entirely — the tool descriptions themselves instruct AI agents not to do this until a real person has explicitly approved the action, so treat it as an escape hatch for already-approved automation, not the default flow.

List Pending Operations

{} // no parameters

Confirm an Operation

{
  operationId: "op_1700000000000_abc123xyz" // ID returned when the operation was created
}

Cancel an Operation

{
  operationId: "op_1700000000000_abc123xyz"
}

2. 💼 Wallet Management

Available Tools:

start-wallet-interaction: Initialize wallet management
create-wallet: Create/import/manage wallets
use-wallet-from-creation: Reuse wallet data from a previous create-wallet result without re-uploading it

Supported Operations:

🆕 Create New Wallet

// Creates a wallet with secure password
{
  walletOption: "🆕 Create a new wallet",
  walletName: "MyWallet",
  walletPassword: "secure_password",
  replaceCurrentWallet: false
}

🔑 Import Existing Wallet

// Import using private key
{
  walletOption: "🔑 Import existing wallet",
  walletName: "ImportedWallet",
  privateKey: "0x...",
  walletPassword: "secure_password"
}

🔍 List Saved Wallets

// List all available wallets
{
  walletOption: "🔍 List saved wallets",
  walletData: "my-wallets.json_content"
}

🔁 Switch Active Wallet

// Switch to another wallet
{
  walletOption: "🔁 Switch wallet", 
  newMainWallet: "WalletName"
}

♻️ Reuse Wallet From Previous Creation

// Skips re-uploading wallet data by referencing the create-wallet result
{
  testnet: true,
  token: "rBTC",
  walletCreationResult: "{\"walletsData\":{...}}" // the full JSON string returned by create-wallet, not a parsed object
}

3. 💰 Balance Queries

Tool: `check-balance`

Supported Tokens:

rBTC - Rootstock native token
USDT - Tether USD
DOC - Dollar on Chain
BPRO - BitPro
RIF - RIF Token
FISH - Fish Token
Custom Token - Any ERC20 token

Example:

{
  testnet: true, // true for testnet, false for mainnet
  token: "rBTC",
  walletName: "MyWallet" // optional, uses current wallet if not specified
}

For Custom Tokens:

{
  testnet: true,
  token: "Custom Token",
  customTokenAddress: "0x...", // token contract address
  walletName: "MyWallet"
}

4. 💸 Token Transfers

Tool: `transfer-tokens`

Transfers rBTC or ERC20 tokens between wallets. Like deploy-contract, confirmAction is required on every call: pass false to get back a pending operation that must be confirmed via confirm-operation before anything executes; pass true only once a real person has approved the transfer.

Requirements:

Recipient address
Amount (number, not string)
Wallet with sufficient funds
Token contract address (optional, omit for native rBTC)

Example:

{
  testnet: true,
  toAddress: "0x...", // recipient address
  value: 0.01, // amount to transfer (number)
  tokenAddress: "0x...", // optional, omit for native rBTC transfers
  walletData: "my-wallets.json_content",
  walletPassword: "wallet_password",
  confirmAction: false // required on every call; false requires confirm-operation, true executes immediately
}

5. 🔍 Transaction Tracking

Tool: `check-transaction`

{
  testnet: true, // network to check
  txid: "0x..." // transaction hash (with or without 0x prefix)
}

Returned Information:

Transaction status (pending/confirmed/failed)
Block number
Gas used
Transfer details
Timestamps

6. 📊 Transaction History

Tool: `check-transaction-history`

Queries a wallet's transaction history using the Alchemy API.

Requirements:

Alchemy API key (optional — falls back to a stored key if omitted)

Example:

{
  testnet: true,
  apiKey: "your-alchemy-api-key", // optional, uses a stored key if omitted
  number: "10", // number of transactions to retrieve (string)
  walletData: "my-wallets.json_content"
}

7. 🚀 Contract Deployment

Tool: `deploy-contract`

Requirements:

Contract ABI (JSON)
Compiled bytecode (hex)
Constructor arguments (optional)
Wallet with sufficient funds

Example:

{
  testnet: true,
  abiContent: `[{"inputs":[],"name":"myFunction"...}]`, // complete ABI
  bytecodeContent: "0x608060405234801561001057600080fd5b50...", // bytecode
  constructorArgs: ["arg1", "arg2"], // constructor arguments
  walletData: "my-wallets.json_content",
  walletPassword: "wallet_password"
}

8. ✅ Contract Verification

Tool: `verify-contract`

Requirements:

Deployed contract address
Solidity source code
Compilation metadata (JSON Standard Input)
Constructor arguments used

Example:

{
  testnet: true,
  contractAddress: "0x...", // contract address
  contractName: "MyContract", // exact name in source code
  jsonContent: `{"language":"Solidity","sources":{...}}`, // compilation metadata
  constructorArgs: ["arg1", "arg2"] // arguments used in deployment
}

9. 📄 Contract Reading

Tool: `read-contract`

To List Available Functions:

{
  testnet: true,
  contractAddress: "0x..." // must be a verified contract
}

To Call a Function:

{
  testnet: true,
  contractAddress: "0x...",
  functionName: "balanceOf", // view/pure function name
  functionArgs: ["0x..."] // function arguments
}

10. 🌐 Supported Networks

Rootstock Mainnet

RPC URL: https://public-node.rsk.co
Chain ID: 30
Explorer: https://explorer.rootstock.io

Rootstock Testnet

RPC URL: https://public-node.testnet.rsk.co
Chain ID: 31
Explorer: https://explorer.testnet.rootstock.io

11. 🎯 Attestation Management

Available Attestation Tools:

issue-attestation: Create new attestations with a raw schema and encoded data
verify-attestation: Verify existing attestations by UID
revoke-attestation: Revoke attestations
list-attestations: Query attestations by event logs (requires custom RPC URL)
create-schema: Register new attestation schemas
attest-deployment: Create a deployment attestation using the RAS default schema
attest-verification: Create a contract verification attestation using the RAS default schema
attest-transfer: Create a transfer attestation using the RAS default schema

🎯 Issue Attestation

{
  testnet: true,
  recipient: "0x...", // recipient address
  schema: "0x...", // schema UID
  data: "encoded_data", // schema-encoded data
  expirationTime: 0, // optional timestamp
  revocable: true // optional
}

🔍 Verify Attestation

{
  testnet: true,
  uid: "0x..." // attestation UID
}

❌ Revoke Attestation

{
  testnet: true,
  uid: "0x...", // attestation UID
  walletData: {}, // wallet configuration
  walletPassword: "password"
}

📋 List Attestations

Note: RSK public nodes do not support eth_getLogs. A custom rpcUrl from a provider such as Alchemy or GetBlock is required.

{
  testnet: true,
  rpcUrl: "https://rsk-mainnet.g.alchemy.com/v2/YOUR_KEY", // required
  recipient: "0x...", // optional filter
  attester: "0x...", // optional filter
  schema: "0x...", // optional filter
  limit: 10 // optional, default 10
}

🏗️ Create Schema

{
  testnet: true,
  schema: "uint256 tokenId, string name", // schema definition
  revocable: true,
  resolverAddress: "0x...", // optional, defaults to zero address
  walletData: {}, // wallet configuration
  walletPassword: "password"
}

🏗️ Attest Deployment

Creates a deployment attestation using the RAS default deployment schema. Uses DEFAULT_SCHEMA_UIDS.testnet.deployment when no schemaUID is provided.

{
  testnet: true,
  contractAddress: "0x...",
  contractName: "MyContract",
  deployer: "0x...",
  blockNumber: 1000000,
  transactionHash: "0x...",
  timestamp: 1700000000,
  abiHash: "0x...", // optional
  bytecodeHash: "0x...", // optional
  schemaUID: "0x...", // optional, uses default RAS schema
  recipient: "0x...", // optional
  walletData: {}, // wallet configuration
  walletPassword: "password"
}

✅ Attest Verification

Creates a contract verification attestation using the RAS default verification schema.

{
  testnet: true,
  contractAddress: "0x...",
  contractName: "MyContract",
  verifier: "0x...",
  sourceCodeHash: "0x...",
  compilationTarget: "contracts/MyContract.sol:MyContract",
  compilerVersion: "v0.8.17+commit.8df45f5f",
  optimizationUsed: true,
  timestamp: 1700000000,
  verificationTool: "hardhat",
  schemaUID: "0x...", // optional, uses default RAS schema
  recipient: "0x...", // optional
  walletData: {}, // wallet configuration
  walletPassword: "password"
}

💸 Attest Transfer

Creates a transfer attestation using the RAS default transfer schema.

{
  testnet: true,
  sender: "0x...",
  recipient: "0x...",
  amount: "0.001",
  tokenSymbol: "RBTC", // optional, defaults to RBTC
  tokenAddress: "0x...", // optional, for ERC20
  transactionHash: "0x...",
  blockNumber: 1000000,
  timestamp: 1700000000,
  transferType: "native", // e.g. "native" or "erc20"
  reason: "payment", // optional
  schemaUID: "0x...", // optional, uses default RAS schema
  walletData: {}, // wallet configuration
  walletPassword: "password"
}

📁 Project Structure

rsk-mcp-server/
├── src/
│   ├── handlers/
│   │   └── responsesHandler.ts    # MCP response handling
│   ├── services/
│   │   ├── AttestationService.ts  # Attestation operations
│   │   ├── ContractDeploymentService.ts # Contract deployment
│   │   ├── ContractReadService.ts # Contract reading
│   │   ├── ContractVerificationService.ts # Contract verification
│   │   ├── HistoryService.ts      # Transaction history
│   │   ├── TransferService.ts     # Token transfers
│   │   └── WalletService.ts       # Wallet management
│   ├── tools/
│   │   ├── constants.ts           # Constants and options
│   │   ├── handlers.ts            # Auxiliary handlers
│   │   ├── schemas.ts             # Zod validation schemas
│   │   └── types.ts               # TypeScript types
│   ├── utils/
│   │   └── responses.ts           # Response utilities
│   ├── server-config.ts           # MCP server configuration
│   ├── index.ts                   # Main entry point
│   └── rsk-cli.d.ts               # Ambient type declarations for rsk-cli
├── scripts/
│   └── test-attestations.mjs      # Attestation integration tests
├── build/                         # Compiled code (generated)
├── package.json                   # Project configuration
├── tsconfig.json                  # TypeScript configuration
└── README.md                      # This documentation

🔐 Security

Private Key Management

Private keys are stored encrypted using AES-256
Each wallet has its own unique IV (initialization vector)
Passwords are never stored in plain text

Best Practices

Use strong and unique passwords
Maintain secure backups of my-wallets.json
Do not share configuration files
Use testnet for testing

🐛 Troubleshooting

Error: "Module not found"

npm install
npm run build

MCP Connection Error

Verify absolute path in configuration
Ensure the project is compiled
Check MCP client logs

Wallet Issues

Verify my-wallets.json format
Check password in password.json (in case you managed the password in a file)
Ensure sufficient funds for transactions

Contributing

We welcome contributions from the community. Please fork the repository and submit pull requests with your changes. Ensure your code adheres to the project's main objective.

Support

For any questions or support, please open an issue on the repository or reach out to the maintainers.

Disclaimer

The software provided in this GitHub repository is offered “as is,” without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and non-infringement.

Testing: The software has not undergone testing of any kind, and its functionality, accuracy, reliability, and suitability for any purpose are not guaranteed.
Use at Your Own Risk: The user assumes all risks associated with the use of this software. The author(s) of this software shall not be held liable for any damages, including but not limited to direct, indirect, incidental, special, consequential, or punitive damages arising out of the use of or inability to use this software, even if advised of the possibility of such damages.
No Liability: The author(s) of this software are not liable for any loss or damage, including without limitation, any loss of profits, business interruption, loss of information or data, or other pecuniary loss arising out of the use of or inability to use this software.
Sole Responsibility: The user acknowledges that they are solely responsible for the outcome of the use of this software, including any decisions made or actions taken based on the software’s output or functionality.
No Endorsement: Mention of any specific product, service, or organization does not constitute or imply endorsement by the author(s) of this software.
Modification and Distribution: This software may be modified and distributed under the terms of the license provided with the software. By modifying or distributing this software, you agree to be bound by the terms of the license.
Assumption of Risk: By using this software, the user acknowledges and agrees that they have read, understood, and accepted the terms of this disclaimer and assumes all risks associated with the use of this software.

Available Tools

22 tools

attest-deploymentB

Create a deployment attestation on Rootstock using RAS. Uses default testnet schema UIDs when none is provided.

ParametersJSON Schema

Name	Required	Description
`abiHash`	No	Keccak256 hash of the contract ABI (optional)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`deployer`	Yes	Address of the deployer wallet (0x... format)
`recipient`	No	EAS attestation recipient address - defaults to contractAddress
`schemaUID`	No	Schema UID to use - uses default RSK deployment schema if not provided
`timestamp`	Yes	Unix timestamp of the deployment
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use - uses current wallet if not provided
`blockNumber`	Yes	Block number where the contract was deployed
`bytecodeHash`	No	Keccak256 hash of the contract bytecode (optional)
`contractName`	Yes	Name of the deployed contract
`walletPassword`	No	Password to decrypt the wallet - required when using walletData
`contractAddress`	Yes	Deployed contract address (0x... format)
`transactionHash`	Yes	Deployment transaction hash (0x... format, 32 bytes)

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description bears full burden for behavioral disclosure. It only mentions default schema UIDs but omits side effects like wallet requirements, gas costs, or blockchain writes. The tool's write nature is implied but not explicit.

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 a single, front-loaded sentence with a second sentence adding key detail about default schema UIDs. Every word is necessary; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 parameters, 7 required, and no output schema, the description is too terse. It lacks workflow context (e.g., prerequisite wallet setup, transaction lifecycle) and does not explain the purpose of deployment attestation or RAS.

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?

Input schema has 100% description coverage, so baseline is 3. The description adds no value beyond the schema; it repeats the default schema UID behavior already documented in the schemaUID property. Parameters like walletData and walletPassword are not explained.

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 tool creates a deployment attestation on Rootstock using RAS, specifying verb and resource. It distinguishes from sibling attestation tools like issue-attestation and attest-transfer by focusing on deployment context.

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?

The description implies usage for creating deployment attestations but provides no explicit guidance on when to use this tool versus alternatives like attest-verification or import-related tools. No exclusion criteria or prerequisites are mentioned.

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

attest-transferB

Create a transfer attestation on Rootstock using RAS. Uses default testnet schema UIDs when none is provided.

ParametersJSON Schema

Name	Required	Description
`amount`	Yes	Transfer amount as a string (e.g., '1.5')
`reason`	No	Optional reason or memo for the transfer
`sender`	Yes	Sender address (0x... format)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`recipient`	Yes	Recipient address of the transfer (0x... format)
`schemaUID`	No	Schema UID to use - uses default RSK transfer schema if not provided
`timestamp`	Yes	Unix timestamp of the transfer
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use - uses current wallet if not provided
`blockNumber`	Yes	Block number of the transfer
`tokenSymbol`	No	Token symbol (e.g., 'RBTC', 'RIF') - defaults to RBTC for native transfers; required when tokenAddress is provided
`tokenAddress`	No	ERC20 token contract address - omit for RBTC transfers
`transferType`	Yes	Type of transfer (e.g., 'native', 'erc20', 'payment')
`walletPassword`	No	Password to decrypt the wallet - required when using walletData
`transactionHash`	Yes	Transfer transaction hash (0x... format, 32 bytes)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description bears full burden. It discloses creation of an attestation but omits side effects, authorization needs, or reversibility. For a creation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no extraneous words, front-loaded with purpose. Could benefit from slight restructuring (e.g., listing key behaviors) but is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 100% schema coverage, the description fails to explain the attestation creation flow, wallet integration, or relationship with related tools (e.g., transfer-tokens). Agents need more context to use correctly.

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%; the description adds no new parameter meaning beyond 'uses default testnet schema UIDs' which is already implied in the schemaUID description. Baseline 3 maintained.

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 it creates a transfer attestation on Rootstock using RAS, with a specific verb and resource. It distinguishes from siblings like transfer-tokens (actual transfer) and issue-attestation (general attestation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as issue-attestation or detect-attestation. No prerequisites or exclusion criteria provided.

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

attest-verificationC

Create a contract verification attestation on Rootstock using RAS. Uses default testnet schema UIDs when none is provided.

ParametersJSON Schema

Name	Required	Description
`testnet`	Yes	Use testnet (true) or mainnet (false)
`verifier`	Yes	Address of the verifier wallet (0x... format)
`recipient`	No	EAS attestation recipient address - defaults to contractAddress
`schemaUID`	No	Schema UID to use - uses default RSK verification schema if not provided
`timestamp`	Yes	Unix timestamp of the verification
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use - uses current wallet if not provided
`contractName`	Yes	Name of the verified contract
`sourceCodeHash`	Yes	Hash of the verified source code
`walletPassword`	No	Password to decrypt the wallet - required when using walletData
`compilerVersion`	Yes	Solidity compiler version used (e.g., 'v0.8.17+commit.8df45f5f')
`contractAddress`	Yes	Verified contract address (0x... format)
`optimizationUsed`	Yes	Whether compiler optimization was enabled
`verificationTool`	Yes	Tool used for verification (e.g., 'hardhat', 'foundry', 'manual')
`compilationTarget`	Yes	Compilation target file path (e.g., 'contracts/MyContract.sol:MyContract')

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It mentions default testnet schema UIDs but omits critical details like whether the operation is read-only or destructive, permission requirements, side effects, or error handling. The description is insufficient for understanding tool behavior.

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 description is short (two sentences) and front-loaded with the primary action, but given the tool's complexity (15 parameters, no annotations), it is under-specified. Conciseness should not sacrifice essential details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is severely incomplete for a tool with 15 parameters and no output schema. It fails to explain the overall workflow, expected return values, error scenarios, or step-by-step usage. The tool is complex, yet the description provides almost no contextual guidance.

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 coverage is 100%, so baseline is 3. The description adds little beyond the schema, only noting default schema UIDs. It does not explain parameter relationships (e.g., walletData and walletPassword dependency) or provide usage hints for complex parameters.

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 clearly states it creates a contract verification attestation on Rootstock using RAS, specifying the tool's purpose with a specific verb and resource. However, it does not explicitly differentiate from sibling attestation tools like attest-deployment or attest-transfer, though the name and description imply the specific use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., issue-attestation or verify-attestation). There is no mention of prerequisites, context for usage, or conditions under which this tool should be avoided.

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

cancel-operationB

Cancel a pending operation

ParametersJSON Schema

Name	Required	Description	Default
`operationId`	Yes	The ID of the operation to cancel

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description bears full weight. It does not disclose whether cancellation is irreversible, required permissions, or side effects on associated entities.

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?

Single sentence, no unnecessary words. Front-loaded and appropriate in length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and minimal description. For a cancellation tool, lacks context on post-cancellation state, reversibility, and error conditions.

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 coverage is 100% with one parameter described. Description adds no extra meaning beyond schema, meeting baseline expectation.

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?

Description uses specific verb 'Cancel' and resource 'pending operation'. Clearly distinguishes from sibling tools like 'confirm-operation' and 'list-pending-operations'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus siblings. Does not mention prerequisites or alternatives like checking operation status before cancellation.

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

check-balanceB

Check the balance of a wallet for RBTC or ERC20 tokens on Rootstock blockchain. You can either use an existing wallet file or provide wallet data directly.

ParametersJSON Schema

Name	Required	Description
`token`	No	Token to check balance for (rBTC, USDT, DOC, BPRO, RIF, FISH, Custom Token, etc.)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json) - can be a JSON object or string - required if you want to use specific wallet data
`walletName`	No	Specific wallet name to check balance for - uses current wallet if not provided
`customTokenAddress`	No	Custom token contract address - required if token is 'Custom Token'

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description is the sole source of behavioral disclosure. It does not mention that the tool is read-only, any required permissions, rate limits, error handling, or what happens when a wallet is not found. It only states the basic action without behavioral specifics.

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 two sentences long, front-loads the primary purpose, and contains no wasted words. It is efficiently structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no output schema, no annotations, and multiple sibling tools, the description lacks details about return values, error handling, and the testnet/mainnet distinction. It does not fully equip an agent to understand the tool's usage comprehensively.

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?

The schema has 100% coverage for parameter descriptions. The description adds context about the high-level modes (existing wallet vs. direct data) that maps to walletData and walletName, but does not add significant detail beyond the schema. Baseline 3 is appropriate.

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 tool checks the balance of a wallet for RBTC or ERC20 tokens on the Rootstock blockchain. It specifies the target resource (wallet balance) and action (check), and mentions two modes of operation (existing wallet file or direct wallet data), which distinguishes it from sibling tools like check-transaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., check-transaction). It explains how to use it (wallet file or direct data) but not the context or prerequisites for usage. No when-not-to-use or exclusion criteria are mentioned.

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

check-transactionA

Check the status and details of a transaction on Rootstock blockchain using the transaction hash

ParametersJSON Schema

Name	Required	Description	Default
`txid`	Yes	Transaction hash (with or without 0x prefix) to check status and details
`testnet`	Yes	Use testnet (true) or mainnet (false)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It states the tool checks status and details, which implies read-only behavior. Does not disclose error handling for invalid hashes or network issues. Adequate but not rich.

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?

Single sentence, no fluff. Every word earns its place. Efficient and 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?

Low complexity (2 params, no output schema). Description covers purpose and parameters adequately. Missing return value description, but absence of output schema reduces expectation. Complete enough for a simple lookup tool.

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 coverage is 100%, so schema already documents both parameters. Description adds value by clarifying that txid can have or omit 0x prefix and explaining testnet parameter. Baseline 3 with minor added 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 clearly states the tool checks status and details of a transaction on Rootstock blockchain using transaction hash. The verb 'Check' and resource 'transaction on Rootstock blockchain' are specific. Among siblings like check-balance and check-transaction-history, this is well-distinguished.

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?

No explicit guidance on when to use this tool versus alternatives. Usage is implied but not stated. No 'when not to use' or references to siblings like check-transaction-history.

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

check-transaction-historyC

Check the transaction history of a wallet on Rootstock blockchain using Alchemy API

ParametersJSON Schema

Name	Required	Description
`apiKey`	No	Alchemy API key - if not provided, will use stored key
`number`	No	Number of recent transactions to retrieve
`testnet`	Yes	Use testnet (true) or mainnet (false)
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)

TDQS

C2.9/5.0

Behavior2/5

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

Without annotations, the description carries the burden of behavioral disclosure. It only states the read operation but does not mention authentication requirements (apiKey), rate limits, or what happens if wallet data is missing. The reliance on Alchemy API is noted but no further details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with key information. While concise, it could benefit from breaking down into separate lines for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters and no output schema or annotations, the description is insufficient. It does not explain the return format, pagination, or error handling. Sibling differentiation is missing.

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 coverage is 100% with parameter descriptions. The tool description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

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 clearly states the verb (check), resource (transaction history of a wallet), and context (Rootstock blockchain, Alchemy API). However, it does not distinguish from the sibling 'check-transaction' tool, which may refer to checking a single transaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'check-transaction' or 'check-balance'. No prerequisites or exclusions mentioned.

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

confirm-operationB

Confirm and execute a pending operation

ParametersJSON Schema

Name	Required	Description	Default
`operationId`	Yes	The ID of the operation to confirm

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full behavioral disclosure. It states the tool executes a pending operation, implying a state change, but does not clarify reversibility, side effects, or success/failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise at 4 words, containing no unnecessary information. It could benefit from slight expansion, but is not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations, and the description is minimal. It does not explain the expected response, error conditions, or prerequisites, leaving the agent with incomplete information for correct invocation.

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?

The schema covers 100% of parameters, and the description adds no additional meaning beyond the schema's description of operationId. Baseline 3 is appropriate.

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 'Confirm and execute a pending operation' clearly states the verb (confirm/execute) and resource (pending operation). It distinguishes from siblings like cancel-operation, but could be more specific about the nature of the operations.

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?

No explicit when-to-use or when-not-to-use guidance. Usage is implied by the operation lifecycle (list-pending, then confirm or cancel), but the description does not explicitly state this or provide alternatives.

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

create-schemaB

Create a new attestation schema on Rootstock network

ParametersJSON Schema

Name	Required	Description
`schema`	Yes	Schema definition string (e.g., 'uint256 tokenId, string name')
`testnet`	Yes	Use testnet (true) or mainnet (false)
`revocable`	Yes	Whether attestations using this schema can be revoked
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use - uses current wallet if not provided
`walletPassword`	No	Password to decrypt the wallet - required when using walletData
`resolverAddress`	No	Resolver contract address (0x... format) - uses zero address if not provided

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description is the sole source of behavioral info. It only says 'Create' which implies a write operation, but lacks details on network interaction, gas costs, transaction confirmation, or error states. This is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no wasted words. It could be slightly expanded without becoming verbose, but it is appropriately concise for a simple purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters and no output schema, yet the description is extremely minimal. It fails to explain the outcome, how to use the created schema, or network-specific considerations. More context is needed for effective use.

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?

All 7 parameters have descriptions in the schema (100% coverage), so the bar is baseline 3. The description adds no extra meaning beyond the schema, such as parameter interactions or defaults.

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 action (Create), the object (new attestation schema), and the network (Rootstock). It distinguishes from sibling tools like issue-attestation or verify-attestation by focusing on schema creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, prerequisites for schema creation, or typical use cases. The description only states what it does, not when or why.

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

create-walletC

Create a new wallet based on the selected option. This function will ask for required information step by step.

ParametersJSON Schema

Name	Required	Description
`privateKey`	No	Private key to import - required for 'Import existing wallet' option
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json) - required for most operations
`walletName`	No	The name for the new wallet - required for create/import operations
`passwordFile`	No	JSON file content with password field - format: {"password": "yourpassword"}
`walletOption`	Yes	The wallet creation option selected by the user
`newMainWallet`	No	Name of wallet to switch to - required for 'Switch wallet' option
`newWalletName`	No	New name for the wallet - required for 'Update wallet name' option
`previousWallet`	No	Current name of wallet to rename - required for 'Update wallet name' option
`walletPassword`	No	The password for the wallet - required for create/import operations
`deleteWalletName`	No	Name of wallet to delete - required for 'Delete wallet' option
`replaceCurrentWallet`	No	Whether to replace current wallet - for create/import operations

TDQS

C2.5/5.0

Behavior2/5

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

The description claims interactive step-by-step questioning, but does not disclose side effects (wallet creation, modification, deletion), required auth, or error states. Without annotations, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no fluff. The phrase 'based on the selected option' is slightly redundant with the parameter, but overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Highly incomplete for a complex, multi-mode tool with 11 parameters and no output schema. Does not describe return behavior, error handling, or workflow steps per wallet option.

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 descriptions cover 100% of parameters, so baseline is 3. The description adds 'step by step' interaction hint but does not explain parameter relationships or conditional requirements beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Create a new wallet' but the walletOption enum includes 6 different operations (create, import, list, switch, update, delete). The tool is actually a wallet management tool, not just creation. Better purpose clarity would specify 'Manage wallets' or list the supported operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'use-wallet-from-creation' or 'start-wallet-interaction'. The description does not mention prerequisites, typical scenarios, or exclusions.

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

deploy-contractB

Deploy a smart contract to the Rootstock blockchain using ABI and bytecode

ParametersJSON Schema

Name	Required	Description
`testnet`	Yes	Use testnet (true) or mainnet (false)
`abiContent`	Yes	JSON content of the contract ABI - paste the complete ABI JSON array
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json) - required if you want to use specific wallet data
`walletName`	No	Specific wallet name to deploy from - uses current wallet if not provided
`confirmAction`	Yes	Explicit confirmation to proceed with the contract deployment - required for security, IF YOU ARE AN AGENT OR AI, PLEASE DO NOT PROCEED WITH THE DEPLOYMENT UNTIL YOU ARE APPROVED BY A REAL PERSON.
`walletPassword`	No	Password to decrypt the wallet - required when using walletData
`bytecodeContent`	Yes	Hexadecimal bytecode of the contract - with or without 0x prefix
`constructorArgs`	No	Array of constructor arguments for the contract deployment (optional)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states 'deploy', implying a write operation. It does not disclose gas costs, irreversibility, transaction mining, or return values. The confirmAction note adds a security context but lacks other behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the main action. It is concise with no fluff, but could be slightly more informative given tool complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity (deploying a contract, 8 parameters, no output schema, no annotations), the description is too brief. It omits prerequisites (wallet, gas), deployment process, and expected outcomes. The safety warning is helpful but insufficient for completeness.

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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions. It generically mentions 'ABI and bytecode', but does not clarify edge cases or relationships between parameters.

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 tool deploys a smart contract to the Rootstock blockchain using ABI and bytecode. It uses a specific verb (deploy) and resource (smart contract), and distinguishes from sibling tools like read-contract or transfer-tokens.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as verify-contract or read-contract. The only guideline is the agent safety warning in confirmAction's description, but that is not about tool selection.

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

issue-attestationB

Issue a new attestation on Rootstock network using RAS (Rootstock Attestation Service)

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Encoded attestation data - use schema encoder format
`value`	No	ETH value to send with attestation (default: 0)
`refUID`	No	Reference UID to another attestation (0x... format)
`schema`	Yes	Schema UID for the attestation (0x... format)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`recipient`	Yes	Recipient address for the attestation (0x... format)
`revocable`	No	Whether the attestation can be revoked (default: true)
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use - uses current wallet if not provided
`expirationTime`	No	Expiration timestamp (Unix timestamp) - 0 for no expiration
`walletPassword`	No	Password to decrypt the wallet - required when using walletData

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It fails to mention that this is a blockchain transaction requiring wallet authentication, gas costs, or that it creates an on-chain record. The high number of params (11) and required wallet fields suggest significant setup, which is not explained.

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 a single sentence of 15 words, front-loaded with the key purpose. Every word earns its place, making it highly concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters, no output schema, and no mention of return values or side effects (e.g., transaction hash, attestation UID), the description leaves significant gaps. The complexity of issuing an on-chain attestation (requiring wallet setup, gas, etc.) is not addressed.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds value by specifying that 'data' should use schema encoder format and that 'walletData' should contain saved wallet file content. This provides useful guidance beyond the bare schema descriptions.

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 action (issue), the resource (attestation), the network (Rootstock), and the service (RAS). This directly differentiates from sibling tools like verify-attestation, revoke-attestation, and list-attestations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Siblings include schema creation (create-schema) and other attestation operations, but the description does not specify prerequisites (e.g., needing a schema UID) or when to prefer this over others.

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

list-attestationsA

List attestations on Rootstock network by querying EAS contract event logs. Requires a custom rpcUrl — RSK public nodes do not support eth_getLogs.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of attestations to return (default: 10)
`rpcUrl`	No	Custom RPC URL with eth_getLogs support (e.g. Alchemy, GetBlock). Required — RSK public nodes do not support event log queries.
`schema`	No	Filter by schema UID (0x... format)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`attester`	No	Filter by attester address (0x... format)
`recipient`	No	Filter by recipient address (0x... format)

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the reliance on event logs and the need for a custom RPC, but does not address pagination, rate limits, or what happens if no attestations are found. The limit parameter implies some pagination support, but it is not described.

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 exceptionally concise: two sentences with no wasted words. The first sentence states the action and context, the second highlights the essential requirement. Every sentence serves a purpose.

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?

The tool has 6 parameters and no output schema. The description explains the input constraints well but does not describe the return format (e.g., array of attestation objects, fields, or pagination). Given the absence of an output schema, more detail on the response would improve completeness.

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

Parameters4/5

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

The input schema provides 100% description coverage for all parameters. The description reinforces the critical rpcUrl requirement. While the schema already covers parameter meaning, the description adds practical context (why rpcUrl is necessary), which is valuable beyond the schema.

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 tool lists attestations on Rootstock via EAS event logs. It uses a specific verb (list) and resource (attestations), and the context of Rootstock and EAS distinguishes it from sibling tools like issue-attestation or verify-attestation.

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 notes that a custom rpcUrl is required because RSK public nodes lack eth_getLogs support. This guides when to use the tool, though it could be slightly more explicit about when not to use it beyond the public node limitation.

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

list-pending-operationsA

List all pending operations that require user confirmation

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It adequately describes a read-only list operation without side effects. It is transparent enough for a simple tool with no parameters.

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 a single, front-loaded sentence with no unnecessary words. Every word adds value, making it concise and well-structured.

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?

Given no output schema and 0 parameters, the description is nearly complete. It could mention scope (e.g., whether it lists all users' operations or only the current user's), but for a simple listing tool it is sufficient.

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

Parameters4/5

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

The tool has 0 parameters, and the schema description coverage is 100%. Per guidelines, 0 parameters earns a baseline of 4. No additional parameter information is needed.

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 verb 'list' and the resource 'pending operations', and adds context 'that require user confirmation'. This distinguishes it from sibling tools like confirm-operation and cancel-operation.

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?

The description implies usage context but does not explicitly state when to use this tool versus alternatives like confirm-operation or cancel-operation. It is clear from the name and siblings, but no explicit guidance is provided.

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

read-contractA

Read data from a verified smart contract on the Rootstock blockchain by calling view/pure functions

ParametersJSON Schema

Name	Required	Description
`testnet`	Yes	Use testnet (true) or mainnet (false)
`functionArgs`	No	Array of arguments for the function call (required if the function has parameters)
`functionName`	No	Name of the view/pure function to call - if not provided, available functions will be listed
`contractAddress`	Yes	Contract address to read from (0x... format) - must be a verified contract

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description must carry full burden. It correctly implies a non-destructive read operation but adds no detail about potential failures, required node access, or rate limits. The requirement for a verified contract is only in the parameter description, not in main. Adequate but not rich.

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?

Single sentence, no filler. Concise and front-loaded with key information: action, resource, and blockchain. Every word 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?

With 4 parameters, 100% schema coverage, and no output schema, the description is sufficient for a simple read tool. It covers the core purpose but could mention the return format or behavior when functionName is omitted (though schema notes it). Mostly complete.

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 coverage is 100% with all parameter descriptions provided. The description adds 'by calling view/pure functions', which overlaps with the functionName parameter description. Baseline 3 is appropriate as the description adds minimal value beyond the schema.

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?

Description clearly states what the tool does: reads data from a verified smart contract on Rootstock blockchain via view/pure functions. The verb 'read', resource 'smart contract', and method 'view/pure functions' are specific and differentiate from siblings like deploy-contract or transfer-tokens.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, when not to use, or compare to sibling tools such as check-transaction or deploy-contract. Usage context is implied but not explicit.

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

revoke-attestationC

Revoke an existing attestation by UID on Rootstock network

ParametersJSON Schema

Name	Required	Description
`uid`	Yes	Attestation UID to revoke (0x... format)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use - uses current wallet if not provided
`walletPassword`	No	Password to decrypt the wallet - required when using walletData

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It does not state that revocation is a destructive operation, whether confirmation is required, or any permission or network constraints beyond 'Rootstock network'. The irreversible nature and need for wallet signing are omitted.

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 a single, clear sentence that conveys the core purpose. It is front-loaded and avoids extraneous detail. Every word is functional, earning its place despite the lack of elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a mutation with 5 parameters, no output schema, and no annotations. The description fails to explain return values, success/failure indicators, prerequisites (e.g., wallet setup), or how to interpret results. It is under-specified for effective use by an AI agent.

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 coverage is 100%, so the parameters are documented. The description adds no additional meaning beyond the schema; it does not explain the role of wallet parameters or the format of the UID in context. Baseline score of 3 is appropriate given full schema coverage.

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 clearly states the action (revoke), resource (attestation), identifier (UID), and network (Rootstock). It distinguishes from sibling tools like issue-attestation and verify-attestation by specifying revocation. However, it does not elaborate on what revocation entails (e.g., permanent invalidation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as when an attestation should be revoked or if there are prerequisites. The description does not mention that revocation is irreversible or that the attestation must have been previously issued.

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

start-interactionC

Start interaction with the Rootstock CLI functions, start this once someone ask something related to the rootstock (rsk) blockchain

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.1/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral effects. There is no mention of side effects, prerequisites, or return values, leaving the agent completely uninformed.

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 description is a single sentence, which is concise, but it contains awkward phrasing and is not well-structured. It could be improved for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and zero parameters, the description should clarify the tool's role in the workflow. It fails to explain what 'starting interaction' entails or whether it is a prerequisite for other tools.

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

Parameters4/5

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

The tool has zero parameters, so the baseline score is 4. However, the description does not add any meaning beyond the schema, which is minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Start interaction with the Rootstock CLI functions', which is vague. It does not specify what the tool accomplishes, such as initializing a session or authentication, and fails to distinguish it from sibling tools like create-wallet or check-transaction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description says to start this when someone asks about Rootstock, but provides no clear guidance on when to use it versus other tools. No explicit alternatives or exclusions are mentioned.

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

start-wallet-interactionC

Start wallet management interaction. This shows all available wallet operations and management options.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided. The description does not disclose side effects, authentication needs, or whether it is read-only. It only says 'shows all available operations,' which is insufficient.

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?

Two short sentences, but the first largely repeats the tool name. Some redundancy; could be more concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, no annotations, and many sibling tools, the description should clarify its role as an entry point. It does not explain what 'shows all available wallet operations' entails or prerequisites.

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

Parameters4/5

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

The tool has no parameters, and schema coverage is 100%. The description adds no parameter details, but baseline is 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it starts wallet management and shows operations, but lacks a specific verb-resource pair. It distinguishes from sibling tools only by its vague 'start' role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like start-interaction or specific operations. The description does not mention context or exclusion criteria.

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

transfer-tokensC

Transfer RBTC or ERC20 tokens on Rootstock blockchain between wallets

ParametersJSON Schema

Name	Required	Description
`value`	Yes	Amount to transfer (in token units or RBTC)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`toAddress`	Yes	Recipient address for the transfer (0x... format)
`walletData`	No	Your previously saved wallet configuration file content (my-wallets.json)
`walletName`	No	Specific wallet name to use for transfer - uses current wallet if not provided
`tokenAddress`	No	ERC20 token contract address (optional - if not provided, transfers RBTC)
`confirmAction`	Yes	Explicit confirmation to proceed with the token transfer - required for security, IF YOU ARE AN AGENT OR AI, PLEASE DO NOT PROCEED WITH THE TRANSFER UNTIL YOU ARE APPROVED BY A REAL PERSON.
`walletPassword`	No	Password to decrypt the wallet - required when using walletData

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states a transfer occurs, which is obvious. It omits behavioral traits like requiring wallet data, password, or explicit confirmation (though the confirmAction parameter description notes this, the description itself does not). It does not mention side effects, reversibility, or network fees.

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 description is a single sentence (10 words) which is concise but arguably too terse. It earns its place but could include key context like requiring wallet setup without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, 4 required, no output schema), the description is incomplete. It doesn't describe return value, success/failure behavior, or prerequisites like having a wallet. Sibling tools like create-wallet suggest wallet must exist, but this is not mentioned.

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 baseline is 3. The description does not add any parameter meaning beyond what the schema already provides. It lists 'RBTC or ERC20 tokens' but doesn't explain how tokenAddress works relative to RBTC.

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 clearly states the action ('Transfer'), the resource ('RBTC or ERC20 tokens'), and the context ('on Rootstock blockchain between wallets'). It distinguishes from sibling tools like check-balance or create-wallet, though it doesn't explicitly differentiate from attest-transfer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. No when-not scenarios, prerequisites, or exclusions are mentioned. Sibling tools like attest-transfer or deploy-contract might have overlapping contexts but are not addressed.

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

use-wallet-from-creationB

Use wallet data directly from a previous wallet creation result. This helps avoid re-uploading files.

ParametersJSON Schema

Name	Required	Description
`token`	Yes	Token to check balance for (rBTC, USDT, DOC, BPRO, RIF, FISH, Custom Token, etc.)
`testnet`	Yes	Use testnet (true) or mainnet (false)
`customTokenAddress`	No	Custom token contract address - required if token is 'Custom Token'
`walletCreationResult`	Yes	The complete JSON result from create-wallet function including walletsData

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'use wallet data' without explaining side effects, prerequisites (e.g., wallet already created), error conditions, or what the tool actually does with the data (e.g., sets current wallet?). This lack of detail is a significant gap.

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 two short sentences with no unnecessary words. It is front-loaded: first sentence states purpose, second provides benefit. Excellent conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of output schema and annotations, and the tool having 4 parameters (3 required), the description is incomplete. It does not explain what success looks like, possible errors, or how this tool fits into the workflow (e.g., after using, what operations can be performed?). An agent would need more context to use it correctly.

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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only mentions 'wallet data' and 'avoid re-uploading files' without elaborating on parameter details like what constitutes a valid walletCreationResult or how token/testnet are used.

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 states the tool uses wallet data from a previous creation result, avoiding re-uploading files. The verb 'use' is slightly vague but combined with the context it's clear the tool is for reusing existing wallet data. It distinguishes from siblings like create-wallet and check-balance.

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?

The description implies usage to avoid re-uploading files, suggesting it should be used when a wallet creation result is available. However, it does not explicitly state when not to use it or compare to alternatives like create-wallet. The guidance is implied rather than explicit.

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

verify-attestationC

Verify an existing attestation by UID on Rootstock network

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	Attestation UID to verify (0x... format)
`testnet`	Yes	Use testnet (true) or mainnet (false)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'verify' without disclosing whether it is a read-only call, requires gas, or has side effects. Siblings with similar patterns suggest it may be a read operation, but this is not explicit.

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?

Single sentence, no filler words. All information is front-loaded and directly relevant. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a verification tool with no output schema and no annotations, the description should hint at the return value or side effects. It does not, leaving the agent unaware of what happens after verification. Incomplete for a blockchain operation.

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 covers 100% of parameters with descriptions, so baseline is 3. Description adds no extra semantic meaning beyond what is already in schema (e.g., UID format). Meets minimum but does not supplement.

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?

Description clearly states verb 'Verify' and resource 'existing attestation by UID on Rootstock network', distinguishing it from sibling tools like issue-attestation and list-attestations. However, it does not explain the nature of verification (e.g., on-chain check) or expected output.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as list-attestations or check-transaction. No context on prerequisites or exclusions.

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

verify-contractB

Verify a smart contract on the Rootstock blockchain using source code and compilation metadata

ParametersJSON Schema

Name	Required	Description
`testnet`	Yes	Use testnet (true) or mainnet (false)
`jsonContent`	Yes	JSON Standard Input content from Solidity compilation - contains solcLongVersion and input fields, it is not necesary to readd the content, just validate it contains an 'input' field and others. If the file is too large, you can delete the 'output' section to reduce file size while keeping the required compilation metadata.
`contractName`	Yes	Name of the contract as defined in the source code
`constructorArgs`	No	Array of constructor arguments used during deployment (optional)
`contractAddress`	Yes	Contract address to verify (0x... format)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so the description must disclose behavior. It only says 'Verify' without explaining internal operations (e.g., API call, state changes) or side effects. No mention of permissions, rate limits, or what happens to the input data.

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?

Single sentence of 15 words, directly stating purpose with no filler. Information is front-loaded and every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks information about return values or outcomes (e.g., verification success/failure, transaction hash). Does not explain how to use the result or what happens after verification. For a tool with no output schema and zero annotations, more context is needed.

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 baseline is 3. The description adds context about Rootstock and verification but does not significantly enhance understanding beyond the schema's detailed parameter descriptions.

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 action ('Verify'), the target ('smart contract on the Rootstock blockchain'), and the method ('using source code and compilation metadata'). It distinguishes the tool from siblings like deploy-contract and read-contract.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as deploy-contract or check-transaction. Does not mention prerequisites like having the contract source code or compilation artifacts, nor when not to use it (e.g., if contract is already verified).

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

22 tool updatesv0.2.7Jul 29, 2026
- First observedattest-deployment
- First observedattest-transfer
- First observedattest-verification
- First observedcancel-operation
- First observedcheck-balance
- First observedcheck-transaction
- First observedcheck-transaction-history
- First observedconfirm-operation
- First observedcreate-schema
- First observedcreate-wallet
- First observeddeploy-contract
- First observedissue-attestation
- First observedlist-attestations
- First observedlist-pending-operations
- First observedread-contract
- First observedrevoke-attestation
- First observedstart-interaction
- First observedstart-wallet-interaction
- First observedtransfer-tokens
- First observeduse-wallet-from-creation
- First observedverify-attestation
- First observedverify-contract

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Disambiguation3/5

Several tools have overlapping names or purposes, such as check-transaction vs check-transaction-history and start-interaction vs start-wallet-interaction. Descriptions help differentiate, but agents could still confuse similar tools.

Naming Consistency3/5

Tool names use a dash-separated pattern but verbs are inconsistent (e.g., 'issue-attestation' vs 'attest-deployment'). Some verbs are vague ('start-interaction'), breaking a strict verb_noun pattern.

Tool Count4/5

22 tools cover a broad range of blockchain operations (wallet, transactions, contracts, attestations). The count is slightly high but justifiable for the comprehensive scope.

Completeness4/5

The tool set covers major workflows: wallet management, transfers, contract lifecycle, and attestation CRUD. Minor gaps like advanced contract queries exist, but core functionality is well-represented.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

blockscout-mcp-server AOAuth
ai.smithery
Provide AI agents and automation tools with contextual access to blockchain data including balance…
Blockchain Web3 & Decentralized Tech Search
244
Satoshidata Wallet Intel B
io.github.wrbtc
Bitcoin wallet intelligence for AI agents: trust, labels, tx verify, fees, and timestamps.
Blockchain Finance Cryptocurrency
442
Nansen A
io.github.nansen-ai
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
462
Nansen A
io.github.hurcanNansen
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
462

Related MCP Servers

Rootstock MCP Server
cuongpo
A
license
B
quality
Not graded
maintenance
A backend service that enables seamless interaction with the Rootstock blockchain using the Model Context Protocol, providing standardized APIs for querying, transacting, and managing assets on Rootstock.
Updated a year ago (2025-07-12 04:06 UTC)
19
-
Base MCP Server
Blockchain Web3 & Decentralized Tech Cryptocurrency
bioanywhere
A
license
Not graded
quality
Not graded
maintenance
Enables AI applications to interact with the Base blockchain network, allowing wallet management, smart contract deployment, token transfers, NFT operations, DeFi interactions with Morpho vaults, and onramping funds via Coinbase.
Updated 9 months ago (2025-12-09 19:17 UTC)
13
-
Rootstock MCP Server
Blockchain Cryptocurrency Web3 & Decentralized Tech
alicecha
A
license
B
quality
D
maintenance
Enables Claude AI to interact with the Rootstock blockchain, including calling contracts, checking ERC20 token balances, transferring tokens, and querying gas prices.
Updated a year ago (2025-05-08 08:57 UTC)
8
MIT
Bink MCP Serverofficial
Blockchain Cryptocurrency
Bink-AI
F
license
Not graded
quality
D
maintenance
Enables AI agents to perform blockchain operations like wallet management, token info, DeFi swaps, cross-chain bridging, and price checking across Ethereum, BNB Chain, and Solana.
Updated a year ago (2025-05-06 10:37 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rsksmart/rsk-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

RSK MCP Server - Rootstock Blockchain Tools

🚀 Key Features

🧰 Available Tools

📋 Prerequisites

🛠️ Installation and Build

1. Clone the Repository

2. Install Dependencies

3. Build the Project

4. Verify Installation

⚙️ AI Client Configuration

🏠 Remote Configuration

For Cursor IDE

For Claude Desktop (Anthropic)

🏠 Local Configuration

For Cursor IDE

For Claude Desktop (Anthropic)

For Other MCP Implementations

🌐 Remote Configuration (URL)

Remote Client Configuration

🔧 Detailed Functionality

1. 🧭 Session & Interaction

Available Tools:

2. 💼 Wallet Management

Available Tools:

Supported Operations:

3. 💰 Balance Queries

Tool: check-balance

4. 💸 Token Transfers

Tool: transfer-tokens

5. 🔍 Transaction Tracking

Tool: check-transaction

6. 📊 Transaction History

Tool: check-transaction-history

7. 🚀 Contract Deployment

Tool: deploy-contract

8. ✅ Contract Verification

Tool: verify-contract

9. 📄 Contract Reading

Tool: read-contract

10. 🌐 Supported Networks

Rootstock Mainnet

Rootstock Testnet

11. 🎯 Attestation Management

Available Attestation Tools:

📁 Project Structure

🔐 Security

Private Key Management

Best Practices

🐛 Troubleshooting

Error: "Module not found"

MCP Connection Error

Wallet Issues

Contributing

Support

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Bink MCP Serverofficial

Latest Blog Posts

MCP directory API

Tool: `check-balance`

Tool: `transfer-tokens`

Tool: `check-transaction`

Tool: `check-transaction-history`

Tool: `deploy-contract`

Tool: `verify-contract`

Tool: `read-contract`