一个适用于 Starknet 区块链的全面模型上下文协议 (MCP) 服务器。该服务器为 AI 代理提供了与 Starknet 网络交互、查询区块链数据、管理钱包以及与智能合约交互的能力。
Related MCP server: AMOCA Solana MCP Server
Starknet MCP 服务器利用模型上下文协议 (MCP) 为 AI 代理提供区块链服务。它为 Starknet 生态系统提供了全面的接口，使 AI 助手能够通过自然语言与 Starknet 区块链数据和操作进行交互。
主要功能包括：
读取区块链状态（余额、交易、区块）
与 Cairo 智能合约交互
转移代币（ETH、STRK 和其他 ERC20 代币）
使用 NFT 和代币元数据
解析 StarknetID 域名（类似于以太坊的 ENS）
通过适当的事务处理进行读写操作
所有服务均通过 MCP 工具和资源的一致接口公开，方便 AI 代理发现并使用 Starknet 区块链功能。所有接受 Starknet 地址的工具也支持 StarknetID ，可在后台自动将人类可读的身份解析为地址。
Starknet 集成：使用 Starknet.js 进行完整的 Starknet 区块链集成
网络支持：支持主网和Sepolia测试网
StarknetID 集成：将 Starknet ID 解析为地址，反之亦然
原生代币支持：支持 ETH 和 STRK 原生代币
智能合约交互：调用、查询Starknet智能合约
双传输：作为 stdio 服务器或 HTTP 服务器运行，以满足不同的集成需求
AI-Ready ：设计用于与 Claude、GPT 和其他 AI 助手一起使用
查询链信息（链ID、最新区块）
探索区块详细信息和交易
查看交易收据和状态
获取地址信息和合约数据
获取任意地址的 ETH 和 STRK 余额
在账户之间转移 ETH 和 STRK
查看合并的原生代币余额
获取 ERC20 代币余额和信息
转移 ERC20 代币
查看代币供应和元数据
检查代币所有权
通过代币 ID 检查 NFT 所有权
获取NFT收藏信息
查看地址的 NFT 余额
调用只读合约函数
通过交易确认执行合约写入
获取合约存储信息
查看 ABI 和合约类信息
将 Starknet 地址解析为 Starknet ID
将 Starknet ID 解析为地址
获取带有验证数据的完整 Starknet ID 资料
验证 Starknet 域名
该服务器支持以下Starknet网络：
主网：Starknet 的主要生产网络
Sepolia ：Starknet 在以太坊 Sepolia 上的测试网
Bun 1.0.0 或更高版本（推荐）
Node.js 18.0.0 或更高版本
最简单的入门方法是使用npx直接运行包：
# Run the stdio server without installation
npx @mcpdotdirect/starknet-mcp-server
# Run the HTTP server without installation
npx @mcpdotdirect/starknet-mcp-server http这将自动下载并运行最新版本，而无需先安装。
如果您打算经常使用它，您可以全局安装它：
# Install globally
npm install -g @mcpdotdirect/starknet-mcp-server
# Then run from anywhere
starknet-mcp-server
starknet-mcp-server http# Add to your project
npm install @mcpdotdirect/starknet-mcp-server
# Using yarn
yarn add @mcpdotdirect/starknet-mcp-server
# Using pnpm
pnpm add @mcpdotdirect/starknet-mcp-server然后添加到你的 package.json 脚本：
"scripts": {
"starknet-mcp": "starknet-mcp-server",
"starknet-mcp-http": "starknet-mcp-server http"
}如果您想从源代码运行或在本地开发：
# Clone the repository
git clone https://github.com/mcpdotdirect/starknet-mcp-server.git
cd starknet-mcp-server
# Install dependencies
npm install
# Start the stdio server
npm start
# Or start the HTTP server
npm run start:http对于自动重新加载的开发：
# Development mode with stdio
npm run dev
# Development mode with HTTP
npm run dev:http服务器使用以下默认配置：
默认网络：主网
服务器端口：3000（HTTP模式）
服务器主机：0.0.0.0（可从任何网络接口访问）
这些值在应用程序中是硬编码的。如果需要修改它们，可以编辑以下文件：
网络配置： src/core/chains.ts
对于服务器配置： src/server/http-server.ts
您可以以两种模式运行 Starknet MCP 服务器：
# Run the server in stdio mode (for CLI tools and AI assistants)
npx @mcpdotdirect/starknet-mcp-server
# Run the server in HTTP mode (for web applications)
npx @mcpdotdirect/starknet-mcp-server httpHTTP 服务器默认在端口 3000 上运行，并提供 REST API 和服务器发送事件 (SSE) 以进行实时通信。
要从 Cursor 连接到 Starknet MCP 服务器：
打开 Cursor 并转到“设置”（左下角的齿轮图标）
点击左侧边栏中的“功能”
向下滚动到“MCP 服务器”部分
点击“添加新的 MCP 服务器”
输入以下详细信息：
服务器名称： starknet-mcp-server
类型： command
命令： npx @mcpdotdirect/starknet-mcp-server
点击“保存”
连接后，您可以直接在 Cursor 中使用 MCP 服务器的功能。该服务器将显示在 MCP 服务器列表中，您可以根据需要启用/禁用。
为了获得可与团队共享或跨项目使用的更便携的配置，您可以在项目的根目录中创建一个.cursor/mcp.json文件：
{
"mcpServers": {
"starknet-mcp-server": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server"
]
},
"starknet-mcp-http": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server",
"http"
]
}
}
}将此文件放在项目的.cursor目录中（如果不存在则创建），Cursor 将在该项目中工作时自动检测并使用这些 MCP 服务器配置。
如果您正在开发 Web 应用程序并希望使用服务器发送事件 (SSE) 连接到 HTTP 服务器，则可以使用以下配置：
{
"mcpServers": {
"starknet-mcp-sse": {
"url": "http://localhost:3000/sse"
}
}
}如果您使用 Claude CLI，则只需两个命令即可连接到 MCP 服务器：
# Add the MCP server using npx
claude mcp add starknet-mcp-server npx @mcpdotdirect/starknet-mcp-server
# Start Claude with the MCP server enabled
claude配置完 MCP 服务器后，您就可以在 Cursor 中轻松使用它了。例如：
在您的项目中创建一个新的 JavaScript/TypeScript 文件：
// starknet-example.js
async function main() {
try {
// When using with Cursor, you can simply ask Cursor to:
// "Check the ETH balance of address 0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7 on Starknet mainnet"
// Or "Lookup the Starknet ID for address 0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7"
// Cursor will use the MCP server to execute these operations
// without requiring any additional code from you
} catch (error) {
console.error("Error:", error.message);
}
}
main();在 Cursor 中打开文件后，您可以要求 Cursor 执行以下操作：
“检查 vitalik.stark 的 ETH 余额”
“获取有关 Starknet 上最新区块的信息”
“在收藏 0x 中查找 NFT #123 的所有者...”
// Example of using the MCP client to check an ETH balance using Starknet ID
const mcp = new McpClient("http://localhost:3000");
const result = await mcp.invokeTool("get_starknet_eth_balance", {
address: "vitalik.stark", // Starknet ID instead of address
network: "mainnet"
});
console.log(result);
// {
// wei: "1000000000000000000",
// ether: "1.0"
// }// Example of using the MCP client to resolve a Starknet ID to an address
const mcp = new McpClient("http://localhost:3000");
const result = await mcp.invokeTool("resolve_starknet_address", {
name: "vitalik.stark",
network: "mainnet"
});
console.log(result);
// {
// starknetId: "vitalik.stark",
// address: "0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d",
// resolved: true
// }// Example of using the MCP client to call a smart contract function
const mcp = new McpClient("http://localhost:3000");
const result = await mcp.invokeTool("call_starknet_contract", {
contractAddress: "0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7", // ETH contract
entrypoint: "totalSupply",
calldata: [],
network: "mainnet"
});
console.log(result);
// {
// result: ["0x84b6c7d5970d5a73abe"]
// }如果您想在 Node.js 项目中以编程方式使用 MCP 服务器：
// Start the MCP server as a child process
const { spawn } = require('child_process');
const mcpServer = spawn('npx', ['@mcpdotdirect/starknet-mcp-server']);
// Connect to it with the MCP client
const mcp = new McpClient({ process: mcpServer });
// Now you can use the client
const networks = await mcp.invokeTool("get_supported_starknet_networks", {
random_string: "any"
});
console.log("Supported networks:", networks);对于更高级的用法，您可以围绕 HTTP API 创建一个包装类，或者使用 Axios 等库进行更清晰的 API 调用。
该服务器实现了以下 MCP 工具：
get_starknet_chain_info ：获取有关 Starknet 网络的信息
get_supported_starknet_networks ：获取支持的 Starknet 网络列表
get_starknet_eth_balance ：获取 Starknet 地址或 Starknet ID 的 ETH 余额
get_starknet_token_balance ：获取某个地址任意代币的余额
get_starknet_strk_balance ：获取地址的 STRK 代币余额
get_starknet_native_balances ：获取地址的所有原生代币余额（ETH 和 STRK）
resolve_starknet_name ：获取地址的 Starknet ID
resolve_starknet_address ：获取 Starknet ID 的地址
get_starknet_profile ：获取地址的完整 Starknet ID 配置文件
validate_starknet_domain ：检查字符串是否为有效的 Starknet ID
get_starknet_block ：获取有关特定区块的信息
get_starknet_block_transactions ：获取特定区块中的交易
get_starknet_transaction ：获取交易的详细信息
get_starknet_transaction_receipt ：获取交易收据
check_starknet_transaction_status ：检查交易是否已确认
call_starknet_contract ：调用合约上的只读函数
get_starknet_contract_class ：获取合约的类别（ABI 和其他信息）
execute_starknet_contract ：执行合约调用（写入操作）
get_starknet_token_info ：获取有关代币的信息
get_starknet_token_supply ：获取代币的总供应量
check_starknet_nft_ownership ：检查地址是否拥有特定的 NFT
get_starknet_nft_balance ：获取地址拥有的 NFT 数量
transfer_starknet_eth ：将 ETH 从一个账户转移到另一个账户（金额采用人类可读的格式）
transfer_starknet_strk ：将 STRK 从一个账户转移到另一个账户（金额采用人类可读的格式）
transfer_starknet_token ：将 ERC20 代币从一个账户转移到另一个账户（金额采用人类可读的格式）
服务器提供以下 MCP 资源：
starknet://{network}/chain ：获取特定网络的链信息
starknet://networks ：获取所有支持的网络列表
starknet://{network}/block/{blockIdentifier} ：获取特定区块的信息
starknet://{network}/block/latest ：获取最新区块
starknet://{network}/address/{address} ：获取有关地址的信息
starknet://{network}/tx/{txHash} ：获取交易信息
starknet://{network}/id/address/{address} ：将地址解析为 Starknet ID
starknet://{network}/id/name/{name} ：将 Starknet ID 解析为地址
starknet://{network}/id/profile/{address} ：获取地址的 Starknet ID 配置文件
对于 LLM 交互，服务器提供以下提示：
explore_starknet_block ：探索有关特定 Starknet 区块的信息
explore_starknet_address ：获取有关 Starknet 地址的信息
explore_starknet_transaction ：获取有关 Starknet 交易的信息
lookup_starknet_id ：查找 Starknet ID 或将地址解析为 Starknet ID
explore_starknet_id_profile ：探索完整的 Starknet ID 配置文件
当将此服务器与 Claude 或 GPT 等 AI 助手一起使用时：
配置您的 AI 助手以使用此 MCP 服务器
然后，助手可以使用工具与 Starknet 进行交互
示例查询：
“地址 0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d 的 ETH 余额是多少？”
“查找地址 0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d 的 Starknet ID”
“Starknet 主网的最新区块是什么？”
“获取有关交易 0x7e3a33ab42f2e24184763563b7b8482b53e3b89831ebc3eacf29d4d11f5198 的信息”
“将 Starknet ID vitalik.stark 解析为一个地址”
私钥仅用于交易签名，服务器永远不会存储
所有代币数量均以人类可读的格式（例如 ETH、STRK、代币单位）指定，而不是以 wei 或最小单位指定
在执行操作之前始终验证并清理输入参数
考虑实施额外的身份验证机制以供生产使用
在生产环境中使用 HTTPS 作为 HTTP 服务器
实施速率限制以防止滥用
对于高价值服务，考虑添加确认步骤
starknet-mcp-server/
├── src/
│ ├── index.ts # Main stdio server entry point
│ ├── server/ # Server-related files
│ │ ├── http-server.ts # HTTP server with SSE
│ │ └── server.ts # General server setup
│ ├── core/
│ │ ├── chains.ts # Chain definitions and utilities
│ │ ├── resources.ts # MCP resources implementation
│ │ ├── tools.ts # MCP tools implementation
│ │ ├── prompts.ts # MCP prompts implementation
│ │ └── services/ # Core blockchain services
│ │ ├── index.ts # Service exports
│ │ ├── balance.ts # Balance services
│ │ ├── blocks.ts # Block services
│ │ ├── clients.ts # Client utilities
│ │ ├── contracts.ts # Contract interactions
│ │ ├── starknetid.ts # Starknet ID services
│ │ ├── tokens.ts # Token services
│ │ ├── transactions.ts # Transaction services
│ │ ├── transfer.ts # Transfer services
│ │ └── utils.ts # Utility functions
├── package.json
├── tsconfig.json
└── README.md添加自定义工具、资源或提示时：
在所有资源、工具和提示名称中使用下划线 ( _ ) 代替连字符 ( - )
// Good: Uses underscores
server.tool(
"starknet_contract_call",
"Description of the tool",
{
contract_address: z.string().describe("The contract address")
},
async (params) => {
// Tool implementation
}
);此命名约定确保与 Cursor 和其他 AI 工具的兼容性
更多信息请见：
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
Call a read-only function on a contract
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| calldata | No | Call data array (optional) | |
| entrypoint | Yes | Function name to call | |
| resultTypes | No | Expected return types for each result value (e.g., ['felt', 'uint256', 'address']) | |
| contractAddress | Yes | Contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only mentions 'read-only' but fails to disclose other behavioral traits like authentication or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but could benefit from a bit more detail; still it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks info on return values, errors, or network defaults, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3; description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calls a read-only function on a contract, distinguishing it from siblings which are mostly getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; no when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an address owns a specific NFT
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| tokenId | Yes | Token ID to check | |
| ownerAddress | Yes | Owner's Starknet address or Starknet ID to check against | |
| tokenAddress | Yes | NFT contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It says 'check if an address owns a specific NFT', implying a read-only query. However, it does not disclose any behavioral traits such as network handling, error conditions, or whether it returns a boolean or other type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, clear sentence. Efficient but could be more descriptive without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ownership check with no output schema, the description is adequate. It covers the basic purpose and required parameters. Could improve by noting that it returns a boolean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no additional meaning beyond what the schema provides, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('check'), the resource ('NFT ownership'), and the subject ('an address'). It distinguishes from siblings like 'get_starknet_nft_balance' which returns a count, not a boolean ownership check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Implied usage for checking ownership of a specific NFT, but lacks when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a transaction is confirmed (finalized)
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'check if confirmed finalized' but does not disclose behavior for pending/failed transactions, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is front-loaded and direct. It is appropriately concise for a simple check, though it could benefit from a second sentence on behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple complexity, the description leaves out what 'confirmed' means and typical return values. Sibling tools provide richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds no additional meaning, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking if a transaction is confirmed (finalized). It uses a specific verb and resource, but does not differentiate from sibling tools like get_starknet_transaction or get_starknet_transaction_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to prefer this over get_starknet_transaction or what conditions warrant using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a contract call (write operation)
| Name | Required | Description | Default |
|---|---|---|---|
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| calldata | No | Call data array (optional) | |
| entrypoint | Yes | Function name to call | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) | |
| accountAddress | Yes | Sender's Starknet address | |
| contractAddress | Yes | Contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It only says 'write operation' with no details on permissions, gas, transaction lifecycle, side effects, or whether the call is synchronous. Lacks behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise but front-loads only the purpose. It lacks structure and additional information that would make it efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and a write operation, the description is incomplete. It does not explain the transaction flow, return value, or error scenarios, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what's in the schema; it does not explain parameter relationships or provide context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a contract call (write operation)', specifying the verb (execute), resource (contract call), and the nature (write operation). This distinguishes it from the sibling 'call_starknet_contract' which is likely read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies use for write operations but does not explicitly state when to use this tool versus alternatives like 'call_starknet_contract'. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific block
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| blockIdentifier | No | Block number, hash, or 'latest'/'pending'. Defaults to 'latest'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It merely says 'Get information' without specifying return behavior, error handling, or scope (e.g., whether it includes full transaction data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sibling tools with overlapping scope, the description is insufficiently complete. It omits any hint of what 'information' entails (e.g., block header, timestamp, etc.).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented in the schema. The description adds no extra semantic context beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves block information. However, it does not differentiate from the sibling tool 'get_starknet_block_transactions', which also targets blocks but for transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_starknet_block_transactions, or when not to use it (e.g., for chain-level info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transactions in a specific block
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| blockIdentifier | No | Block number, hash, or 'latest'/'pending'. Defaults to 'latest'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only says 'get transactions', implying a read operation but doesn't detail return format, error handling, or side effects. Important behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is front-loaded and efficient, though it could benefit from slightly more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 2 optional parameters, no output schema, and many sibling tools, the description is too sparse. It doesn't explain what blockIdentifier accepts (number, hash, etc.) or hint at the return type. More context is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already describes both parameters. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (transactions in a specific block). It distinguishes from siblings like get_starknet_block (block info) and get_starknet_transaction (single transaction), but does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or provide any exclusions or suggestions for related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a Starknet network
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states 'get information' without mentioning read-only nature, latency, or response format. Agent has no insight into side effects or data volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Efficient but lacks detail; conciseness does not compensate for missing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description should explain return value structure (e.g., chain ID, block height). It does not, leaving agent uninformed about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. Description adds 'Defaults to Mainnet' which is not in schema, providing slight extra value. Baseline 3 aligns with minimal addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about a Starknet network' is clear in verb and resource but vague on what specific information is returned. It does not differentiate from sibling tools like get_starknet_block or get_supported_starknet_networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Agent must infer from name and description, which is insufficient among many similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the class (ABI and other information) of a contract
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| contractAddress | Yes | Contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. However, it only mentions the function's input and output in vague terms, failing to confirm that it is a read-only operation, any side effects, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. However, it is extremely brief and could be expanded slightly to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description does not clarify the structure or content of the return value beyond 'ABI and other information'. Missing details like error handling, rate limits, or examples make the description incomplete for an agent to safely use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it repeats 'contract' without elaborating on parameter details or providing context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('the class (ABI and other information) of a contract'). It effectively distinguishes from sibling tools that deal with transactions, blocks, balances, etc., making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply states what it does without helping the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the ETH balance for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency, but it only states the basic function. It fails to disclose traits like read-only nature, error handling, rate limits, or what happens if the address is invalid. This is insufficient for a tool that queries blockchain state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks information about return format (e.g., balance in wei or ether), error cases, or handling of invalid addresses. Given the tool's moderate complexity and lack of annotations or output schema, more context is needed for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds value for the address parameter by clarifying 'with or without .stark', but does not enhance the network parameter beyond the schema. Overall, slight improvement over schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), resource (ETH balance), and scope (Starknet address or Starknet ID), effectively distinguishing it from sibling tools like get_starknet_strk_balance or get_starknet_token_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to use get_starknet_strk_balance for STRK or get_starknet_token_balance for arbitrary tokens. It also doesn't mention prerequisites or context for using network parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all native token balances (ETH and STRK) for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully cover behavioral traits. It only states the function but omits details like error handling (invalid address/ID), rate limits, idempotency, or return format. This is insufficient for a data retrieval tool with potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear verb and resource, front-loaded, no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides basic purpose but lacks details on return structure, error conditions, and behavioral traits. With similar sibling tools, more context would be helpful but description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described (address can be ID, network defaults to mainnet). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves native token balances (ETH and STRK) for a Starknet address or ID, using specific verbs and resource. It distinguishes from sibling tools like get_starknet_eth_balance and get_starknet_strk_balance which fetch individual native tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for combining two native token queries into one call, but provides no explicit guidance on when to use this tool vs get_starknet_eth_balance or get_starknet_strk_balance. No when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of NFTs owned by an address for a specific collection
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| ownerAddress | Yes | Owner's Starknet address or Starknet ID | |
| tokenAddress | Yes | NFT contract address or Starknet ID |
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 lacks disclosure of edge cases (e.g., zero balance, invalid address) or any behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, clearly communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only balance query, the description is adequate. No output schema exists, but the return value (a number) is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('number of NFTs'), and specifies the scope ('by address for a specific collection'). It distinguishes itself from sibling tool 'check_starknet_nft_ownership' which checks individual ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'check_starknet_nft_ownership'. Usage context is implied but not clarified with exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full Starknet ID profile for an address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID to lookup | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only restates the basic purpose. It does not disclose what 'full profile' includes, authentication needs, or any side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description omits important context like what constitutes a Starknet ID profile, expected return format, and prerequisites. Without output schema, the agent cannot predict the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters fully (100% coverage). The description adds no additional semantic value beyond what the schema provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get', the resource 'full Starknet ID profile', and the input (address or Starknet ID). Distinguishes from sibling tools that focus on balances, transactions, blocks, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus related siblings like 'resolve_starknet_address' or 'resolve_starknet_name'. The description does not specify context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the STRK token balance for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the function without mentioning read-only nature, error conditions, or response format, leaving significant gaps for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no waste. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks return value details (e.g., unit, decimals) and fails to mention network support despite the optional parameter. For a balance tool, this info is important but not critical given schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions Starknet ID just as schema does, but adds no new semantic detail like value units or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the STRK token balance for a Starknet address or ID, distinguishing it from siblings like get_starknet_eth_balance and get_starknet_token_balance by specifying the token type and identifier formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus similar balance tools (e.g., when to prefer STRK balance over native balances), nor any prerequisites or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the token balance for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| ownerAddress | Yes | Owner's Starknet address or Starknet ID | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It fails to disclose that this is a read-only operation, any required permissions, or what the response format looks like (e.g., raw balance vs. human-readable).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It is front-loaded and to the point, but could be more structured with separate sections for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain the balance format, decimals, or any constraints on the token/owner addresses, leaving an agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no extra meaning beyond what the schema already provides, so it meets the baseline for this metric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a token balance for a Starknet address or ID, which distinguishes it from sibling tools that handle native balances or NFTs. However, it doesn't specify that it's for ERC20 tokens, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_starknet_eth_balance, get_starknet_strk_balance, or get_starknet_native_balances. The description does not mention scope or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a token
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether the tool makes external network calls, any rate limits, or the nature of the request (e.g., read-only vs. state-changing). The description carries the full burden but fails to provide transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. However, it is somewhat under-specified, sacrificing completeness for brevity. Front-loading is acceptable but more detail could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the complexity of a token info lookup, the description does not explain what information is returned (e.g., token name, symbol, decimals) or any edge cases. It is minimally complete but lacks sufficient detail for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema adequately documents both parameters. The description adds no further meaning beyond what the schema already provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about a token' is clear but vague. It does not specify what kind of information (e.g., name, symbol, decimals, total supply) is returned, and it does not distinguish from sibling tools like get_starknet_token_balance which also deal with tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_starknet_token_balance or get_starknet_nft_balance. The description lacks any context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total supply of a token
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description gives no behavioral details such as return format, units (e.g., raw integer vs. decimals), or whether it works for all token types. The description is minimal and lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. It is concise but could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more details about return value, edge cases, or typical usage. It is too sparse to be fully useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no value beyond the schema; the schema already explains both parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the total supply of a token, which distinguishes it from sibling tools like get_starknet_token_balance (balance for an address) and get_starknet_token_info (other metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context about prerequisites or limitations. The description simply states what it does without advising on scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a transaction
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details are disclosed beyond a generic description. With no annotations, the description should cover aspects like mutability, authentication requirements, or rate limits, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point, but it may be too brief for such a complex domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential information about what 'details' are returned, network context, and how it differs from sibling tools. It is incomplete given the complexity and number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'transaction details', but it does not differentiate from the sibling tool 'get_starknet_transaction_receipt', which also gets transaction-related details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_starknet_transaction_receipt' or other StarkNet tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction receipt
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
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 only repeats the tool name without adding any behavior details (e.g., error handling, default network, or data returned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (2 words) but lacks structure and detail. It earns its place by stating purpose, but is too brief to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and good schema coverage, the description fails to explain what a receipt is or how it differs from get_starknet_transaction. No output schema; description is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get transaction receipt', which clearly identifies the action and resource. However, it does not distinguish from sibling tools like get_starknet_transaction, which might also involve receipt data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of supported Starknet networks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any details about behavioral traits such as caching, data freshness, or potential delays. Since no annotations are provided, the description should compensate, but it remains minimal. It does not reveal if the list is static or dynamic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains zero extraneous information. It is appropriately concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, sibling tools are all different), the description is mostly sufficient. However, it could be improved by hinting at the output format (e.g., an array of network names) to help an agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not add parameter semantics, but none are needed. Schema coverage is 100% as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a list of supported Starknet networks'. It uses a specific verb ('Get') and resource ('supported Starknet networks'), and uniquely distinguishes it from sibling tools that operate on specific Starknet data or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context. Agents must infer its applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the address for a Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Starknet ID to lookup (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get the address', implying a read operation, but does not mention error handling for invalid names, default network behavior, or any rate limiting. The agent lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is front-loaded and efficient, earning its place without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate. However, it fails to mention that the network parameter defaults to mainnet or what the return format is. For a tool with no annotations, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional detail beyond the schema, but it does reinforce the purpose. Baseline 3 is appropriate as the description does not detract or significantly add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the address for a Starknet ID' clearly states the verb (get), the resource (address), and the input (Starknet ID). It effectively differentiates from sibling tools like resolve_starknet_name, which likely does the reverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., resolve_starknet_name), nor does it mention any prerequisites, limitations, or when not to use it. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Starknet ID for an address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address to lookup (must be a valid address, not a name) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states a read operation ('Get'). It does not disclose behavioral traits such as error handling (e.g., if address is not found), rate limits, or authentication requirements, which are important for an agent to invoke the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient. However, it could be slightly improved by specifying the return value or differentiating from siblings without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema, the description is incomplete: it does not describe the return value (what the 'Starknet ID' is), default behavior for the optional 'network' parameter, or error states. For a simple lookup tool, this leaves gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the parameters. The tool description adds no additional meaning beyond restating the purpose; it does not clarify parameter interactions, defaults, or constraints beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('Starknet ID for an address'), but it does not differentiate from the sibling tool 'resolve_starknet_address'. The term 'Starknet ID' is ambiguous—whether it's a numeric identifier or a domain name—making it less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like 'resolve_starknet_address' or 'validate_starknet_domain'. The description implies usage for looking up an address, but lacks context for exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer ETH from one account to another
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient's Starknet address or Starknet ID | |
| from | Yes | Sender's Starknet address | |
| amount | Yes | Amount to transfer in ETH (human readable format, not wei) | |
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as transaction finality, gas implications, or potential failures. The only behavioral note is about the private key usage, which is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description and schema cover the basic functionality, the tool has 6 parameters and no output schema or annotations. Additional context (e.g., network implications, error handling) would improve completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 6 parameters. The description adds no additional semantic value beyond what is already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Transfer' and resource 'ETH' with the context 'from one account to another', effectively distinguishing it from sibling tools like 'transfer_starknet_strk' and 'transfer_starknet_token'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contexts where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer STRK from one account to another
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient's Starknet address or Starknet ID | |
| from | Yes | Sender's Starknet address | |
| amount | Yes | Amount to transfer in STRK (human readable format, not wei) | |
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the basic transfer action but does not disclose that it requires a private key, signs transactions, or modifies state irreversibly. Details about fee handling, error behavior, and confirmation are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and front-loaded with the verb. However, it is too minimal and adds little value beyond the tool name. It could be restructured to include key context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, financial transfer, required private key) and lack of output schema or annotations, the description is insufficient. It does not cover confirmation behavior, error cases, network defaults, or security considerations, making it incomplete for an AI agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters described in the schema (e.g., 'from', 'to', 'amount', 'privateKey', 'maxFee', 'network'). The description adds no additional parameter information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Transfer), the asset (STRK), and the scope (from one account to another). It distinguishes from sibling tools like transfer_starknet_eth and transfer_starknet_token by specifying STRK. However, it omits the specific blockchain (Starknet), which is implied by the tool name and siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., transfer_starknet_eth, call_starknet_contract). There is no mention of prerequisites such as sufficient balance or correct network, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer ERC20 tokens from one account to another
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient's Starknet address or Starknet ID | |
| from | Yes | Sender's Starknet address | |
| amount | Yes | Amount to transfer in token's standard units (human readable format, not in smallest unit) | |
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only says 'Transfer' without detailing whether the transaction is signed immediately, what happens to nonces, or if it waits for confirmation. This is minimal for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, earning its place. However, it could be expanded slightly to include key context like the need for token approval or network selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too sparse. It does not mention return values, error cases, or prerequisites (e.g., sufficient balance, token allowance), leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds no additional parameter meaning beyond the schema, but the schema itself is well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transfer ERC20 tokens from one account to another', which is a specific verb+resource. It distinguishes from sibling tools like transfer_starknet_eth and transfer_starknet_strk that transfer specific tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for arbitrary ERC20 transfers but provides no explicit guidance on when to use this tool versus alternatives like transfer_starknet_eth for ETH, or considerations like token approvals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a string is a valid Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Starknet ID to validate (with or without .stark) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior like what 'valid' means or return format, but it only repeats the purpose, leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, no output schema or behavioral details; validation criteria and expected result are missing, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear description; 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'a valid Starknet ID', distinguishing it from sibling tools like resolve_starknet_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives; the purpose is implied but no context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0call_starknet_contractcheck_starknet_nft_ownershipcheck_starknet_transaction_statusexecute_starknet_contractget_starknet_blockget_starknet_block_transactionsget_starknet_chain_infoget_starknet_contract_classget_starknet_eth_balanceget_starknet_native_balancesget_starknet_nft_balanceget_starknet_profileget_starknet_strk_balanceget_starknet_token_balanceget_starknet_token_infoget_starknet_token_supplyget_starknet_transactionget_starknet_transaction_receiptget_supported_starknet_networksresolve_starknet_addressresolve_starknet_nametransfer_starknet_ethtransfer_starknet_strktransfer_starknet_tokenvalidate_starknet_domainScored across 25 tools
Each tool has a clearly distinct purpose, targeting specific operations such as balance queries for different tokens (ETH, STRK, native, generic), NFT checks (ownership vs balance), transfers, and contract interactions. No two tools are ambiguous.
All tool names follow a consistent 'verb_starknet_noun' pattern using snake_case (e.g., get_starknet_eth_balance, transfer_starknet_token). The verbs are appropriate and consistent across the set.
25 tools is on the higher side but justifiable for a comprehensive Starknet server covering blocks, transactions, contracts, tokens, NFTs, IDs, and transfers. Each tool serves a specific function without redundancy.
The tool set covers major Starknet operations: reading/writing contracts, querying balances, transfers, block/transaction info, NFT ownership, and domain resolution. Minor gaps like event querying or contract deployment exist, but core workflows are covered.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
