The Starknet MCP Server enables AI agents and developers to interact with the Starknet blockchain through a comprehensive set of tools and resources:
Query blockchain data: Get chain info, block details, transactions, and address information
Interact with smart contracts: Call read-only functions, execute write operations, and retrieve contract class details (including ABI)
Manage tokens: Check balances, transfer, and view metadata for ETH, STRK, and ERC20 tokens using human-readable amounts
NFT operations: Check ownership, retrieve collection info, and view balances
StarknetID integration: Resolve addresses to IDs and vice versa, get profiles, and validate domains
Transaction management: Get details, receipts, and check transaction status
Network support: Interact with Starknet Mainnet and Sepolia testnet
Dual transport modes: Run as stdio server for CLI tools or HTTP server with SSE for web applications
AI assistant integration: Designed for use with Claude, GPT, and other AI assistants through MCP tools
Used as a recommended runtime environment for the MCP server, with specific compatibility for Bun 1.0.0 or higher
Supports interaction with Starknet on Ethereum's Sepolia testnet, providing integration between Starknet and Ethereum ecosystems
Supports Node.js 18.0.0 or higher as an alternative runtime environment for the MCP server
Built with TypeScript 5.0+, providing type safety and modern language features for the MCP server implementation
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Starknet MCP Server check my ETH balance for starknetid.eth"
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.
A comprehensive Model Context Protocol (MCP) server for the Starknet blockchain. This server provides AI agents with the ability to interact with Starknet networks, query blockchain data, manage wallets, and interact with smart contracts.
Related MCP server: AMOCA Solana MCP Server
The Starknet MCP Server leverages the Model Context Protocol to provide blockchain services to AI agents. It offers a comprehensive interface to the Starknet ecosystem, powering AI assistants with the ability to interact with Starknet blockchain data and operations through natural language.
Key capabilities include:
Reading blockchain state (balances, transactions, blocks)
Interacting with Cairo smart contracts
Transferring tokens (ETH, STRK, and other ERC20 tokens)
Working with NFTs and token metadata
Resolving StarknetID domains (similar to ENS for Ethereum)
Making both read and write operations with proper transaction handling
All services are exposed through a consistent interface of MCP tools and resources, making it easy for AI agents to discover and use Starknet blockchain functionality. Every tool that accepts Starknet addresses also supports StarknetID, automatically resolving human-readable identities to addresses behind the scenes.
Starknet Integration: Full Starknet blockchain integration using Starknet.js
Network Support: Supports both Mainnet and Sepolia testnet
StarknetID Integration: Resolution of Starknet IDs to addresses and vice versa
Native Token Support: Support for both ETH and STRK native tokens
Smart Contract Interaction: Call and query Starknet smart contracts
Dual Transport: Run as stdio server or HTTP server for different integration needs
AI-Ready: Designed to be used with Claude, GPT, and other AI assistants
Query chain information (chain ID, latest block)
Explore block details and transactions
View transaction receipts and status
Get address information and contract data
Get ETH and STRK balances for any address
Transfer ETH and STRK between accounts
View combined native token balances
Get ERC20 token balances and information
Transfer ERC20 tokens
View token supply and metadata
Check token ownership
Check NFT ownership by token ID
Get NFT collection information
View NFT balances for addresses
Call read-only contract functions
Execute contract writes with transaction confirmation
Get contract storage information
View ABIs and contract class information
Resolve Starknet addresses to Starknet IDs
Resolve Starknet IDs to addresses
Get complete Starknet ID profiles with verification data
Validate Starknet domains
The server supports the following Starknet networks:
Mainnet: The primary Starknet production network
Sepolia: Starknet's testnet on Ethereum's Sepolia
Bun 1.0.0 or higher (recommended)
Node.js 18.0.0 or higher
To install starknet-mcp-server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @mcpdotdirect/starknet-mcp-server --client claudeThe easiest way to get started is to use npx to run the package directly:
# Run the stdio server without installation
npx @mcpdotdirect/starknet-mcp-server
# Run the HTTP server without installation
npx @mcpdotdirect/starknet-mcp-server httpThis will automatically download and run the latest version without needing to install it first.
If you plan to use it frequently, you can install it globally:
# 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-serverThen add to your package.json scripts:
"scripts": {
"starknet-mcp": "starknet-mcp-server",
"starknet-mcp-http": "starknet-mcp-server http"
}If you want to run from source or develop locally:
# 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:httpFor development with auto-reload:
# Development mode with stdio
npm run dev
# Development mode with HTTP
npm run dev:httpThe server uses the following default configuration:
Default Network: Mainnet
Server Port: 3000 (HTTP mode)
Server Host: 0.0.0.0 (accessible from any network interface)
These values are hardcoded in the application. If you need to modify them, you can edit the following files:
For network configuration: src/core/chains.ts
For server configuration: src/server/http-server.ts
You can run the Starknet MCP Server in two modes:
# 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 httpThe HTTP server runs on port 3000 by default and provides both a REST API and Server-Sent Events (SSE) for real-time communication.
To connect to the Starknet MCP server from Cursor:
Open Cursor and go to Settings (gear icon in the bottom left)
Click on "Features" in the left sidebar
Scroll down to "MCP Servers" section
Click "Add new MCP server"
Enter the following details:
Server name: starknet-mcp-server
Type: command
Command: npx @mcpdotdirect/starknet-mcp-server
Click "Save"
Once connected, you can use the MCP server's capabilities directly within Cursor. The server will appear in the MCP Servers list and can be enabled/disabled as needed.
For a more portable configuration that you can share with your team or use across projects, you can create an .cursor/mcp.json file in your project's root directory:
{
"mcpServers": {
"starknet-mcp-server": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server"
]
},
"starknet-mcp-http": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server",
"http"
]
}
}
}Place this file in your project's .cursor directory (create it if it doesn't exist), and Cursor will automatically detect and use these MCP server configurations when working in that project.
If you're developing a web application and want to connect to the HTTP server with Server-Sent Events (SSE), you can use this configuration:
{
"mcpServers": {
"starknet-mcp-sse": {
"url": "http://localhost:3000/sse"
}
}
}If you're using Claude CLI, you can connect to the MCP server with just two commands:
# Add the MCP server using npx
claude mcp add starknet-mcp-server npx @mcpdotdirect/starknet-mcp-server
# Start Claude with the MCP server enabled
claudeAfter configuring the MCP server, you can easily use it in Cursor. For example:
Create a new JavaScript/TypeScript file in your project:
// 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();With the file open in Cursor, you can ask Cursor to:
"Check the ETH balance of vitalik.stark"
"Get information about the latest block on Starknet"
"Look up the owner of NFT #123 in collection 0x..."
// 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"]
// }If you want to programmatically use the MCP server in your Node.js project:
// 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);For more advanced usage, you can create a wrapper class around the HTTP API or use libraries like Axios for cleaner API calls.
This server implements the following MCP tools:
get_starknet_chain_info: Get information about a Starknet network
get_supported_starknet_networks: Get a list of supported Starknet networks
get_starknet_eth_balance: Get the ETH balance for a Starknet address or Starknet ID
get_starknet_token_balance: Get the balance of any token for an address
get_starknet_strk_balance: Get the STRK token balance for an address
get_starknet_native_balances: Get all native token balances (ETH and STRK) for an address
resolve_starknet_name: Get the Starknet ID for an address
resolve_starknet_address: Get the address for a Starknet ID
get_starknet_profile: Get the full Starknet ID profile for an address
validate_starknet_domain: Check if a string is a valid Starknet ID
get_starknet_block: Get information about a specific block
get_starknet_block_transactions: Get transactions in a specific block
get_starknet_transaction: Get details about a transaction
get_starknet_transaction_receipt: Get transaction receipt
check_starknet_transaction_status: Check if a transaction is confirmed
call_starknet_contract: Call a read-only function on a contract
get_starknet_contract_class: Get the class (ABI and other information) of a contract
execute_starknet_contract: Execute a contract call (write operation)
get_starknet_token_info: Get information about a token
get_starknet_token_supply: Get the total supply of a token
check_starknet_nft_ownership: Check if an address owns a specific NFT
get_starknet_nft_balance: Get the number of NFTs owned by an address
transfer_starknet_eth: Transfer ETH from one account to another (amounts in human-readable format)
transfer_starknet_strk: Transfer STRK from one account to another (amounts in human-readable format)
transfer_starknet_token: Transfer ERC20 tokens from one account to another (amounts in human-readable format)
The server provides the following MCP resources:
starknet://{network}/chain: Get chain information for a specific network
starknet://networks: Get a list of all supported networks
starknet://{network}/block/{blockIdentifier}: Get information about a specific block
starknet://{network}/block/latest: Get the latest block
starknet://{network}/address/{address}: Get information about an address
starknet://{network}/tx/{txHash}: Get transaction information
starknet://{network}/id/address/{address}: Resolve an address to a Starknet ID
starknet://{network}/id/name/{name}: Resolve a Starknet ID to an address
starknet://{network}/id/profile/{address}: Get the Starknet ID profile for an address
For LLM interactions, the server provides these prompts:
explore_starknet_block: Explore information about a specific Starknet block
explore_starknet_address: Get information about a Starknet address
explore_starknet_transaction: Get information about a Starknet transaction
lookup_starknet_id: Look up a Starknet ID or resolve an address to a Starknet ID
explore_starknet_id_profile: Explore a full Starknet ID profile
When using this server with AI assistants like Claude or GPT:
Configure your AI assistant to use this MCP server
The assistant can then use tools to interact with Starknet
Example queries:
"What's the ETH balance of address 0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d?"
"Look up the Starknet ID for address 0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d"
"What's in the latest block on Starknet mainnet?"
"Get information about transaction 0x7e3a33ab42f2e24184763563b7b8482b53e3b89831ebc3eacf29d4d11f5198"
"Resolve the Starknet ID vitalik.stark to an address"
Private keys are used only for transaction signing and are never stored by the server
All token amounts are specified in human-readable format (e.g., ETH, STRK, token units) rather than in wei or smallest units
Always validate and sanitize input parameters before executing operations
Consider implementing additional authentication mechanisms for production use
Use HTTPS for the HTTP server in production environments
Implement rate limiting to prevent abuse
For high-value services, consider adding confirmation steps
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.mdWhen adding custom tools, resources, or prompts:
Use underscores (_) instead of hyphens (-) in all resource, tool, and prompt names
// Good: Uses underscores
server.tool(
"starknet_contract_call",
"Description of the tool",
{
contract_address: z.string().describe("The contract address")
},
async (params) => {
// Tool implementation
}
);This naming convention ensures compatibility with Cursor and other AI tools
For more information about:
This project is licensed under the MIT License - see the LICENSE file for details.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcpdotdirect/starknet-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
