Un servidor integral de Protocolo de Contexto de Modelo (MCP) para la blockchain de Starknet. Este servidor proporciona a los agentes de IA la capacidad de interactuar con las redes de Starknet, consultar datos de la blockchain, gestionar billeteras e interactuar con contratos inteligentes.
Related MCP server: AMOCA Solana MCP Server
El servidor MCP de Starknet aprovecha el Protocolo de Contexto de Modelo para proporcionar servicios de blockchain a agentes de IA. Ofrece una interfaz integral con el ecosistema de Starknet, lo que permite a los asistentes de IA interactuar con los datos y operaciones de la blockchain de Starknet mediante lenguaje natural.
Las capacidades clave incluyen:
Lectura del estado de la blockchain (saldos, transacciones, bloques)
Interacción con los contratos inteligentes de El Cairo
Transferencia de tokens (ETH, STRK y otros tokens ERC20)
Trabajar con NFT y metadatos de tokens
Resolución de dominios StarknetID (similar a ENS para Ethereum)
Realizar operaciones de lectura y escritura con un manejo adecuado de las transacciones
Todos los servicios se exponen mediante una interfaz consistente de herramientas y recursos MCP, lo que facilita a los agentes de IA descubrir y utilizar la funcionalidad de la blockchain de Starknet. Todas las herramientas que aceptan direcciones de Starknet también son compatibles con StarknetID , lo que resuelve automáticamente las identidades legibles por humanos en direcciones en segundo plano.
Integración con Starknet : Integración completa de la cadena de bloques de Starknet mediante Starknet.js
Soporte de red : compatible con Mainnet y Testnet Sepolia
Integración de StarknetID : Resolución de identificaciones de Starknet a direcciones y viceversa
Compatibilidad con tokens nativos : compatibilidad con tokens nativos ETH y STRK
Interacción de contratos inteligentes : llamar y consultar contratos inteligentes de Starknet
Transporte dual : Ejecútelo como servidor stdio o servidor HTTP para diferentes necesidades de integración
Listo para IA : diseñado para usarse con Claude, GPT y otros asistentes de IA
Consultar información de la cadena (ID de la cadena, último bloque)
Explorar detalles de bloques y transacciones
Ver recibos y estados de transacciones
Obtener información de dirección y datos del contrato
Obtenga saldos de ETH y STRK para cualquier dirección
Transferir ETH y STRK entre cuentas
Ver saldos combinados de tokens nativos
Obtenga saldos e información de tokens ERC20
Transferir tokens ERC20
Ver el suministro de tokens y los metadatos
Verificar la propiedad del token
Verificar la propiedad de NFT por ID de token
Obtenga información sobre la colección de NFT
Ver saldos de NFT por dirección
Llamar a funciones de contrato de solo lectura
Ejecutar escrituras de contrato con confirmación de transacción
Obtenga información sobre el almacenamiento por contrato
Ver información de ABI y clase de contrato
Resolver direcciones de Starknet a ID de Starknet
Resolver las identificaciones de Starknet en direcciones
Obtenga perfiles completos de Starknet ID con datos de verificación
Validar dominios de Starknet
El servidor admite las siguientes redes Starknet:
Mainnet : La red de producción principal de Starknet
Sepolia : la red de prueba de Starknet en Sepolia de Ethereum
Bun 1.0.0 o superior (recomendado)
Node.js 18.0.0 o superior
La forma más fácil de comenzar es usar npx para ejecutar el paquete directamente:
# Run the stdio server without installation
npx @mcpdotdirect/starknet-mcp-server
# Run the HTTP server without installation
npx @mcpdotdirect/starknet-mcp-server httpEsto descargará y ejecutará automáticamente la última versión sin necesidad de instalarla primero.
Si planeas usarlo con frecuencia, puedes instalarlo globalmente:
# 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-serverLuego agrega a tus scripts package.json:
"scripts": {
"starknet-mcp": "starknet-mcp-server",
"starknet-mcp-http": "starknet-mcp-server http"
}Si desea ejecutar desde la fuente o desarrollar localmente:
# 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:httpPara desarrollo con recarga automática:
# Development mode with stdio
npm run dev
# Development mode with HTTP
npm run dev:httpEl servidor utiliza la siguiente configuración predeterminada:
Red predeterminada : Red principal
Puerto del servidor : 3000 (modo HTTP)
Host del servidor : 0.0.0.0 (accesible desde cualquier interfaz de red)
Estos valores están codificados en la aplicación. Si necesita modificarlos, puede editar los siguientes archivos:
Para la configuración de la red: src/core/chains.ts
Para la configuración del servidor: src/server/http-server.ts
Puede ejecutar el servidor MCP de Starknet en dos modos:
# 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 httpEl servidor HTTP se ejecuta en el puerto 3000 de forma predeterminada y proporciona una API REST y eventos enviados por el servidor (SSE) para la comunicación en tiempo real.
Para conectarse al servidor MCP de Starknet desde Cursor:
Abra Cursor y vaya a Configuración (ícono de engranaje en la parte inferior izquierda)
Haga clic en "Funciones" en la barra lateral izquierda.
Desplácese hacia abajo hasta la sección "Servidores MCP".
Haga clic en "Agregar nuevo servidor MCP"
Introduzca los siguientes datos:
Nombre del servidor: starknet-mcp-server
Tipo: command
Comando: npx @mcpdotdirect/starknet-mcp-server
Haga clic en "Guardar"
Una vez conectado, podrá usar las funciones del servidor MCP directamente desde Cursor. El servidor aparecerá en la lista de servidores MCP y podrá habilitarlo o deshabilitarlo según sea necesario.
Para una configuración más portátil que pueda compartir con su equipo o usar en diferentes proyectos, puede crear un archivo .cursor/mcp.json en el directorio raíz de su proyecto:
{
"mcpServers": {
"starknet-mcp-server": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server"
]
},
"starknet-mcp-http": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server",
"http"
]
}
}
}Coloque este archivo en el directorio .cursor de su proyecto (créelo si no existe) y Cursor detectará y utilizará automáticamente estas configuraciones de servidor MCP cuando trabaje en ese proyecto.
Si está desarrollando una aplicación web y desea conectarse al servidor HTTP con eventos enviados por el servidor (SSE), puede usar esta configuración:
{
"mcpServers": {
"starknet-mcp-sse": {
"url": "http://localhost:3000/sse"
}
}
}Si está utilizando Claude CLI, puede conectarse al servidor MCP con solo dos comandos:
# Add the MCP server using npx
claude mcp add starknet-mcp-server npx @mcpdotdirect/starknet-mcp-server
# Start Claude with the MCP server enabled
claudeDespués de configurar el servidor MCP, puede usarlo fácilmente en Cursor. Por ejemplo:
Crea un nuevo archivo JavaScript/TypeScript en tu proyecto:
// 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();Con el archivo abierto en Cursor, puedes pedirle a Cursor que:
Consulta el saldo de ETH de vitalik.stark.
Obtén información sobre el último bloque en Starknet.
"Buscar el propietario del NFT #123 en la colección 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"]
// }Si desea utilizar programáticamente el servidor MCP en su proyecto Node.js:
// 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);Para un uso más avanzado, puede crear una clase contenedora alrededor de la API HTTP o utilizar bibliotecas como Axios para llamadas de API más limpias.
Este servidor implementa las siguientes herramientas MCP:
get_starknet_chain_info : Obtener información sobre una red Starknet
get_supported_starknet_networks : Obtenga una lista de redes Starknet compatibles
get_starknet_eth_balance : obtiene el saldo de ETH para una dirección o ID de Starknet
get_starknet_token_balance : obtiene el saldo de cualquier token para una dirección
get_starknet_strk_balance : obtiene el saldo del token STRK para una dirección
get_starknet_native_balances : obtiene todos los saldos de tokens nativos (ETH y STRK) para una dirección
resolve_starknet_name : Obtener el ID de Starknet para una dirección
resolve_starknet_address : Obtener la dirección de una ID de Starknet
get_starknet_profile : obtiene el perfil de identificación de Starknet completo para una dirección
validate_starknet_domain : Comprueba si una cadena es un ID de Starknet válido
get_starknet_block : Obtener información sobre un bloque específico
get_starknet_block_transactions : Obtener transacciones en un bloque específico
get_starknet_transaction : Obtener detalles sobre una transacción
get_starknet_transaction_receipt : Obtener el recibo de la transacción
check_starknet_transaction_status : Comprueba si una transacción está confirmada
call_starknet_contract : Llamar a una función de solo lectura en un contrato
get_starknet_contract_class : Obtener la clase (ABI y otra información) de un contrato
execute_starknet_contract : Ejecutar una llamada de contrato (operación de escritura)
get_starknet_token_info : Obtener información sobre un token
get_starknet_token_supply : Obtener el suministro total de un token
check_starknet_nft_ownership : Comprueba si una dirección posee un NFT específico
get_starknet_nft_balance : obtiene la cantidad de NFT que posee una dirección
transfer_starknet_eth : transfiere ETH de una cuenta a otra (cantidades en formato legible para humanos)
transfer_starknet_strk : Transferir STRK de una cuenta a otra (cantidades en formato legible para humanos)
transfer_starknet_token : transfiere tokens ERC20 de una cuenta a otra (cantidades en formato legible para humanos)
El servidor proporciona los siguientes recursos MCP:
starknet://{network}/chain : Obtener información de la cadena para una red específica
starknet://networks : Obtenga una lista de todas las redes compatibles
starknet://{network}/block/{blockIdentifier} : Obtener información sobre un bloque específico
starknet://{network}/block/latest : Obtener el último bloque
starknet://{network}/address/{address} : Obtener información sobre una dirección
starknet://{network}/tx/{txHash} : Obtener información de la transacción
starknet://{network}/id/address/{address} : Resolver una dirección a un ID de Starknet
starknet://{network}/id/name/{name} : Resolver un ID de Starknet a una dirección
starknet://{network}/id/profile/{address} : Obtener el perfil de identificación de Starknet para una dirección
Para las interacciones LLM, el servidor proporciona estas indicaciones:
explore_starknet_block : Explora información sobre un bloque específico de Starknet
explore_starknet_address : Obtener información sobre una dirección de Starknet
explore_starknet_transaction : Obtener información sobre una transacción de Starknet
lookup_starknet_id : busca un ID de Starknet o resuelve una dirección a un ID de Starknet
explore_starknet_id_profile : Explora un perfil completo de Starknet ID
Al utilizar este servidor con asistentes de IA como Claude o GPT:
Configura tu asistente de IA para usar este servidor MCP
El asistente puede luego usar herramientas para interactuar con Starknet.
Consultas de ejemplo:
"¿Cuál es el saldo de ETH de la dirección 0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d?"
"Buscar el ID de Starknet para la dirección 0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d"
"¿Qué hay en el último bloque en la red principal de Starknet?"
Obtener información sobre la transacción 0x7e3a33ab42f2e24184763563b7b8482b53e3b89831ebc3eacf29d4d11f5198
"Resolver el ID de Starknet vitalik.stark a una dirección"
Las claves privadas se utilizan únicamente para firmar transacciones y nunca las almacena el servidor.
Todas las cantidades de tokens se especifican en formato legible para humanos (por ejemplo, ETH, STRK, unidades de token) en lugar de en wei o unidades más pequeñas.
Siempre valide y desinfecte los parámetros de entrada antes de ejecutar operaciones
Considere implementar mecanismos de autenticación adicionales para el uso en producción
Utilice HTTPS para el servidor HTTP en entornos de producción
Implementar la limitación de velocidad para evitar el abuso
Para servicios de alto valor, considere agregar pasos de confirmación
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.mdAl agregar herramientas, recursos o indicaciones personalizadas:
Utilice guiones bajos ( _ ) en lugar de guiones ( - ) en todos los nombres de recursos, herramientas y avisos.
// Good: Uses underscores
server.tool(
"starknet_contract_call",
"Description of the tool",
{
contract_address: z.string().describe("The contract address")
},
async (params) => {
// Tool implementation
}
);Esta convención de nomenclatura garantiza la compatibilidad con Cursor y otras herramientas de IA.
Para obtener más información sobre:
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
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.
