How do I use Rootstock MCP Server?

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., "@Rootstock MCP Server What's my USDC balance on Rootstock?" 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.

Rootstock MCP Server

by alicecha

Overview Schema Related Servers Score Discussions

Remote

OpenSSF Scorecard CodeQL

Rootstock MCP Server

This is a Model Context Protocol (MCP) server that provides onchain tools for Claude AI, allowing it to interact with the Rootstock blockchain.

Features

Call contract functions on Rootstock Network
Get ERC20 token balances
Transfer ERC20 tokens
Get current gas prices

Related MCP server: Base MCP Server

Installation

Clone this repository:

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

Install dependencies:

npm install

Build the project:

npm run build

Configuration

Create a .env file in the root directory with the following variables:

SEED_PHRASE="your twelve word seed phrase here"

Usage

Running the server

npm start

Using with Claude

{
  "mcpServers": {
    "rootstock": {
      "command": "node",
      "args": ["/path/to/rootstock-mcp/build/index.js"],
      "env": {
        "SEED_PHRASE": "your twelve word seed phrase here"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Available Tools

call_contract

Call a contract function on Rootstock Network.

Parameters:

contractAddress: The address of the contract to call
functionName: The name of the function to call
functionArgs: The arguments to pass to the function
abi: The ABI of the contract
value (optional): The value of RBTC to send with the transaction

erc20_balance

Get the balance of an ERC20 token on Rootstock Network.

Parameters:

contractAddress: The address of the contract to get the balance of

erc20_transfer

Transfer an ERC20 token on Rootstock Network.

Parameters:

contractAddress: The address of the contract to transfer the token from
toAddress: The address of the recipient
amount: The amount of tokens to transfer

get_gas_price

Get the current gas price on Rootstock Network.

License

MIT

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

8 tools

call_contractC

Call a contract function on Rootstock Network

ParametersJSON Schema

Name	Required	Description
`contractAddress`	Yes	The address of the contract to call
`functionName`	Yes	The name of the function to call
`functionArgs`	No	The arguments to pass to the function
`abi`	Yes	The ABI of the contract

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It only says 'call a contract function' without mentioning side effects, gas costs, or whether it initiates a transaction or a static call. This is insufficient for safe usage.

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 one sentence and front-loaded with the key action. It is concise, but the brevity sacrifices important details about behavior and usage.

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 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, whether the call is state-changing, or how to handle the ABI parameter.

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 adequate parameter descriptions. The tool description adds no extra meaning beyond the schema, but since the schema already explains each parameter, a baseline of 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 'call' and resource 'contract function on Rootstock Network', distinguishing it from sibling deploy and balance tools. However, it doesn't specify whether the call is read-only or a transaction, which is a key nuance.

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 like deploy or balance tools. There are no exclusions, prerequisites, or context for when this tool is appropriate.

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

deploy_property_nftB

Deploy a PropertyNFT contract on Rootstock

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/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 traits such as gas costs, success/failure conditions, or side effects. It merely states the action.

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 short sentence that directly conveys the tool's purpose. It is efficient and front-loaded with key information.

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 zero parameters and no output schema, the description omits essential details like return values, prerequisites, or potential errors. For a deployment tool, this information is critical for correct invocation.

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?

Input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info because none are needed. Baseline score of 4 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?

Description explicitly states the action (deploy), the resource (PropertyNFT contract), and the platform (Rootstock). It clearly distinguishes from sibling tools like deploy_property_token and deploy_property_yield_vault.

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 its siblings or any prerequisites. The description lacks context about deployment scenarios or alternatives.

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

deploy_property_tokenC

Deploy a PropertyToken contract on Rootstock

ParametersJSON Schema

Name	Required	Description
`propertyNFTAddress`	Yes	The address of the PropertyNFT
`propertyId`	Yes	The ID of the property
`name`	Yes	The name of the property
`symbol`	Yes	The symbol of the property

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are provided, and the description lacks any behavioral disclosure beyond the bare 'deploy' action. It does not mention gas costs, transaction confirmation, reverts, or other important behaviors.

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 extremely concise with a single sentence containing no superfluous information.

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?

For a contract deployment tool, the description is severely lacking. It does not mention return values, gas requirements, or that it initiates a transaction, making it incomplete given the complexity.

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 descriptions for each parameter, so baseline is 3. The tool description adds no additional meaning beyond the schema.

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 tool deploys a PropertyToken contract on Rootstock, specifying the verb and resource. However, it does not differentiate from sibling tools like deploy_property_nft or deploy_property_yield_vault.

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, nor any prerequisites or conditions for deployment.

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

deploy_property_yield_vaultB

Deploy a PropertyYieldVault contract on Rootstock

ParametersJSON Schema

Name	Required	Description
`assetAddress`	Yes	The address of the underlying ERC20 PropertyToken
`name`	Yes	The name of the vault token
`symbol`	Yes	The symbol of the vault token
`propertyNFTAddress`	Yes	The address of the PropertyNFT
`propertyId`	Yes	The ID of the property

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. It only states the action but does not disclose gas costs, irreversibility, or any side effects of deployment. The behavioral transparency is minimal.

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 concise—one sentence front-loading the action and target. No superfluous words, though it could benefit from structured details like prerequisites.

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 of deploying a smart contract (5 required params, no output schema), the description is incomplete. It does not explain return values (e.g., contract address) or chain-specific details like gas estimation.

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% and each parameter has a clear description. The tool description adds no further meaning beyond what the schema already provides, so baseline score applies.

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 'Deploy', the specific contract 'PropertyYieldVault', and the target chain 'Rootstock'. It distinguishes from sibling tools like deploy_property_nft and deploy_property_token, which deploy different contract types.

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 or any prerequisites (e.g., needing to deploy PropertyNFT and PropertyToken first). The usage context is entirely implied.

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

erc20_balanceB

Get the balance of an ERC20 token on Rootstock

ParametersJSON Schema

Name	Required	Description	Default
`contractAddress`	Yes	The address of the contract to get the balance of

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, description fails to disclose whether the operation is read-only, requires authentication, or has side effects. It only states 'get balance' without behavioral details.

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, front-loaded with verb and resource – efficient and clear.

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?

Missing output schema: does not describe return value (e.g., balance in wei, decimals). No mention of prerequisites or error conditions.

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

Parameters2/5

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

Despite 100% schema coverage, description does not clarify whose balance is returned (e.g., the caller's), nor does it add meaning beyond the schema's parameter description.

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 the action ('Get balance') and resource ('ERC20 token on Rootstock'), differentiating it from siblings like erc20_transfer or call_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; no exclusions or context for appropriate use provided.

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

erc20_transferB

Transfer an ERC20 token on Rootstock

ParametersJSON Schema

Name	Required	Description
`contractAddress`	Yes	The address of the contract to transfer the token from
`toAddress`	Yes	The address of the recipient
`amount`	Yes	The amount of tokens to transfer

TDQS

B3.2/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 behavioral traits such as that this is a write operation requiring gas and a transaction, nor does it mention return values or error conditions. The burden on the description is high but unmet.

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, front-loaded with key information. No unnecessary words. 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?

With 3 parameters, no output schema, and no annotations, the description should provide more context (e.g., transaction outcome, gas requirements). It fails to give a complete picture for an invocation decision.

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 input schema has 100% description coverage for all three parameters, so the baseline is 3. The tool description adds no additional meaning 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 'Transfer an ERC20 token on Rootstock' clearly states the action (transfer), the resource (ERC20 token), and the specific network (Rootstock), distinguishing it from sibling tools like erc20_balance and call_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 (e.g., erc20_balance for checking balance, call_contract for general calls). Lacks explicit context for appropriate usage.

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

get_addressA

Get the address of the current account

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/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 traits beyond the basic action. There is no mention of what 'current account' means or any potential side effects, though the tool is likely a simple read.

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 wasted words. It is as concise as possible.

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 the tool's simplicity (no parameters, no output schema), the description is nearly complete. It could mention what format the address is in or prerequisites, but it is adequate for a basic getter.

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%. With 0 parameters, the description does not need to add parameter semantics, and the baseline score of 4 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 verb 'Get' and resource 'address of the current account'. It distinguishes itself from sibling tools which involve contracts, tokens, and gas prices.

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?

While the purpose is clear, there is no guidance on when to use this tool versus alternatives. The siblings are distinct enough that the context is implied, but no explicit when/when-not advice is given.

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

get_gas_priceA

Get the current gas price on Rootstock Network

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, and description lacks behavioral details such as whether the call is read-only, any potential delays, or error conditions.

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 clear sentence, no wasted words, front-loaded with key information.

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?

Adequate for a simple parameterless tool, but lacks details on return format or potential issues; could be more complete.

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?

No parameters exist, so baseline is 4; description adds no param info, which is acceptable.

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 'Get the current gas price on Rootstock Network' uses a specific verb and resource, clearly distinguishing it from sibling tools that involve contracts and 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 versus alternatives; does not mention context or exclusions.

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.

8 tool updatesv1.0.0May 25, 2026
- First observedcall_contract
- First observeddeploy_property_nft
- First observeddeploy_property_token
- First observeddeploy_property_yield_vault
- First observederc20_balance
- First observederc20_transfer
- First observedget_address
- First observedget_gas_price

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct function: generic contract call, specific deployments, ERC20 operations, account info, and gas price. No overlap or ambiguity.

Naming Consistency3/5

Mix of verb_noun patterns (call_contract, get_address) and noun_verb patterns (erc20_balance, erc20_transfer). The deployment tools start with 'deploy' but have varying suffixes.

Tool Count5/5

8 tools is well-scoped for a blockchain interaction server, covering deployment, generic calls, ERC20, account, and gas data without being excessive.

Completeness2/5

Missing basic blockchain operations like native RBTC transfer, balance of native token, transaction receipts, and block info. The tool set is biased toward property-related contracts and ERC20, leaving gaps for general use.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

Base Intel MCP A
io.github.selflabbs
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
Base Intel MCP A
com.datakoot
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
51
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
intelligence
app.tinkrr
Bitcoin and YouTube video intelligence for AI agents. Pay-per-call via x402 USDC on Base.
Cryptocurrency Blockchain Entertainment & Media
2

Related MCP Servers

Veri5ight MCP Server
Blockchain Web3 & Decentralized Tech
5ajaki
A
license
B
quality
D
maintenance
Enables Claude to interact with Ethereum nodes, allowing users to check ENS token balances, view smart contract code, and decode transactions through natural language.
Updated 2 years ago (2025-01-31 04:17 UTC)
5
1
MIT
Base MCP Serverofficial
Blockchain Web3 & Decentralized Tech Cryptocurrency
base
A
license
Not graded
quality
F
maintenance
Provides onchain tools for Claude AI to interact with the Base blockchain and Coinbase API, enabling wallet management, fund transfers, and smart contract deployment.
Updated 4 months ago (2026-05-13 20:07 UTC)
13
350
MIT
MCP Crypto Wallet EVM
Blockchain Web3 & Decentralized Tech Cryptocurrency
dcSpark
A
license
B
quality
D
maintenance
Provides Claude with access to Ethereum and EVM-compatible blockchain operations, enabling wallet management, transaction handling, contract interactions, and blockchain queries through natural language.
Updated a year ago (2025-03-26 03:12 UTC)
4
35
61
10
MIT
RSK MCP Server - Rootstockofficial
Blockchain Web3 & Decentralized Tech Cryptocurrency
rsksmart
A
license
C
quality
A
maintenance
Enables AI clients to interact with the Rootstock (RSK) blockchain through wallet management, balance queries, token transfers, smart contract deployment and verification, and transaction tracking operations.
Updated 2 months ago (2026-07-15 18:52 UTC)
22
61
3
MIT

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/alicecha/rsk-mcp-server'

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

Rootstock MCP Server

Features

Installation

Configuration

Usage

Running the server

Using with Claude

Available Tools

call_contract

erc20_balance

erc20_transfer

get_gas_price

License

Disclaimer

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Base MCP Serverofficial

RSK MCP Server - Rootstockofficial

Latest Blog Posts

MCP directory API