Starknetブロックチェーン向けの包括的なモデルコンテキストプロトコル（MCP）サーバー。このサーバーは、AIエージェントにStarknetネットワークとのインタラクション、ブロックチェーンデータのクエリ、ウォレットの管理、スマートコントラクトとのインタラクション機能を提供します。
Related MCP server: AMOCA Solana MCP Server
Starknet MCPサーバーは、モデルコンテキストプロトコル（Model Context Protocol）を活用してAIエージェントにブロックチェーンサービスを提供します。Starknetエコシステムへの包括的なインターフェースを提供し、AIアシスタントが自然言語でStarknetブロックチェーンのデータや操作を操作できるようにします。
主な機能は次のとおりです。
ブロックチェーンの状態（残高、取引、ブロック）の読み取り
Cairoスマートコントラクトとのやり取り
トークン（ETH、STRK、その他のERC20トークン）の転送
NFTとトークンメタデータの操作
StarknetIDドメインの解決（EthereumのENSに類似）
適切なトランザクション処理で読み取りと書き込みの両方の操作を実行する
すべてのサービスは、MCPツールとリソースの一貫したインターフェースを通じて公開されているため、AIエージェントはStarknetブロックチェーンの機能を容易に発見し、利用できます。Starknetアドレスを受け入れるすべてのツールはStarknetIDもサポートしており、人間が読めるIDをバックグラウンドで自動的にアドレスに変換します。
Starknet 統合: Starknet.js を使用した完全な Starknet ブロックチェーン統合
ネットワークサポート：メインネットとSepoliaテストネットの両方をサポート
StarknetID 統合: Starknet ID からアドレスへの解決、およびその逆
ネイティブトークンのサポート: ETHとSTRKの両方のネイティブトークンをサポート
スマートコントラクトインタラクション: Starknet スマートコントラクトの呼び出しとクエリ
デュアルトランスポート: さまざまな統合ニーズに合わせて stdio サーバーまたは HTTP サーバーとして実行します。
AI対応: Claude、GPT、その他のAIアシスタントと併用できるように設計されています
クエリチェーン情報（チェーンID、最新ブロック）
ブロックの詳細とトランザクションを調べる
取引の領収書とステータスを表示する
住所情報と契約データを取得する
任意のアドレスのETHとSTRKの残高を取得
アカウント間でETHとSTRKを転送する
ネイティブトークンの合計残高を表示する
ERC20トークンの残高と情報を取得する
ERC20トークンの転送
トークンの供給とメタデータを表示する
トークンの所有権を確認する
トークンIDでNFTの所有権を確認する
NFTコレクション情報を取得する
アドレスのNFT残高を表示する
読み取り専用コントラクト関数を呼び出す
トランザクション確認による契約書き込みの実行
契約保管情報を取得する
ABI と契約クラス情報を表示する
Starknet アドレスを Starknet ID に解決する
Starknet IDをアドレスに解決する
検証データ付きの完全なStarknet IDプロファイルを取得する
Starknetドメインを検証する
サーバーは次の Starknet ネットワークをサポートしています。
メインネット: Starknetの主要実稼働ネットワーク
Sepolia : イーサリアムの Sepolia 上の Starknet のテストネット
Bun 1.0.0以上（推奨）
Node.js 18.0.0以上
最も簡単な方法は、 npxを使用してパッケージを直接実行することです。
# Run the stdio server without installation
npx @mcpdotdirect/starknet-mcp-server
# Run the HTTP server without installation
npx @mcpdotdirect/starknet-mcp-server httpこれにより、最初にインストールする必要なく、最新バージョンが自動的にダウンロードされて実行されます。
頻繁に使用する予定の場合は、グローバルにインストールできます。
# Install globally
npm install -g @mcpdotdirect/starknet-mcp-server
# Then run from anywhere
starknet-mcp-server
starknet-mcp-server http# Add to your project
npm install @mcpdotdirect/starknet-mcp-server
# Using yarn
yarn add @mcpdotdirect/starknet-mcp-server
# Using pnpm
pnpm add @mcpdotdirect/starknet-mcp-server次に、package.json スクリプトに次のコードを追加します。
"scripts": {
"starknet-mcp": "starknet-mcp-server",
"starknet-mcp-http": "starknet-mcp-server http"
}ソースから実行したり、ローカルで開発したりする場合:
# Clone the repository
git clone https://github.com/mcpdotdirect/starknet-mcp-server.git
cd starknet-mcp-server
# Install dependencies
npm install
# Start the stdio server
npm start
# Or start the HTTP server
npm run start:http自動リロードを使用した開発の場合:
# Development mode with stdio
npm run dev
# Development mode with HTTP
npm run dev:httpサーバーは次のデフォルト構成を使用します。
デフォルトネットワーク: メインネット
サーバーポート: 3000 (HTTP モード)
サーバーホスト: 0.0.0.0 (どのネットワークインターフェースからもアクセス可能)
これらの値はアプリケーションにハードコードされています。変更が必要な場合は、以下のファイルを編集してください。
ネットワーク設定の場合: src/core/chains.ts
サーバー構成の場合: src/server/http-server.ts
Starknet MCP サーバーは、次の 2 つのモードで実行できます。
# Run the server in stdio mode (for CLI tools and AI assistants)
npx @mcpdotdirect/starknet-mcp-server
# Run the server in HTTP mode (for web applications)
npx @mcpdotdirect/starknet-mcp-server httpHTTP サーバーはデフォルトでポート 3000 で実行され、リアルタイム通信用に REST API と Server-Sent Events (SSE) の両方を提供します。
Cursor から Starknet MCP サーバーに接続するには:
カーソルを開いて設定（左下の歯車アイコン）に移動します
左側のサイドバーの「機能」をクリックします
「MCPサーバー」セクションまでスクロールします
「新しいMCPサーバーを追加」をクリックします
次の詳細を入力してください。
サーバー名: starknet-mcp-server
タイプ: command
コマンド: npx @mcpdotdirect/starknet-mcp-server
「保存」をクリック
接続すると、Cursor 内で MCP サーバーの機能を直接使用できるようになります。サーバーは MCP サーバーリストに表示され、必要に応じて有効化/無効化できます。
チームと共有したり、プロジェクト間で使用したりできる、より移植性の高い構成にするには、プロジェクトのルート ディレクトリに.cursor/mcp.jsonファイルを作成します。
{
"mcpServers": {
"starknet-mcp-server": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server"
]
},
"starknet-mcp-http": {
"command": "npx",
"args": [
"@mcpdotdirect/starknet-mcp-server",
"http"
]
}
}
}このファイルをプロジェクトの.cursorディレクトリに配置すると (存在しない場合は作成します)、そのプロジェクトで作業するときに Cursor はこれらの MCP サーバー構成を自動的に検出して使用します。
Web アプリケーションを開発していて、Server-Sent Events (SSE) を使用して HTTP サーバーに接続する場合は、次の構成を使用できます。
{
"mcpServers": {
"starknet-mcp-sse": {
"url": "http://localhost:3000/sse"
}
}
}Claude CLI を使用している場合は、次の 2 つのコマンドだけで MCP サーバーに接続できます。
# Add the MCP server using npx
claude mcp add starknet-mcp-server npx @mcpdotdirect/starknet-mcp-server
# Start Claude with the MCP server enabled
claudeMCPサーバーを設定したら、Cursorで簡単に使用できます。例：
プロジェクトに新しい JavaScript/TypeScript ファイルを作成します。
// starknet-example.js
async function main() {
try {
// When using with Cursor, you can simply ask Cursor to:
// "Check the ETH balance of address 0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7 on Starknet mainnet"
// Or "Lookup the Starknet ID for address 0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7"
// Cursor will use the MCP server to execute these operations
// without requiring any additional code from you
} catch (error) {
console.error("Error:", error.message);
}
}
main();カーソルでファイルを開いた状態で、カーソルに次の操作を実行できます。
「vitalik.starkのETH残高を確認する」
「スタークネットの最新ブロックに関する情報を取得する」
「コレクション 0x 内の NFT #123 の所有者を検索します...」
// Example of using the MCP client to check an ETH balance using Starknet ID
const mcp = new McpClient("http://localhost:3000");
const result = await mcp.invokeTool("get_starknet_eth_balance", {
address: "vitalik.stark", // Starknet ID instead of address
network: "mainnet"
});
console.log(result);
// {
// wei: "1000000000000000000",
// ether: "1.0"
// }// Example of using the MCP client to resolve a Starknet ID to an address
const mcp = new McpClient("http://localhost:3000");
const result = await mcp.invokeTool("resolve_starknet_address", {
name: "vitalik.stark",
network: "mainnet"
});
console.log(result);
// {
// starknetId: "vitalik.stark",
// address: "0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5d",
// resolved: true
// }// Example of using the MCP client to call a smart contract function
const mcp = new McpClient("http://localhost:3000");
const result = await mcp.invokeTool("call_starknet_contract", {
contractAddress: "0x049d36570d4e46f48e99674bd3fcc84644ddd6b96f7c741b1562b82f9e004dc7", // ETH contract
entrypoint: "totalSupply",
calldata: [],
network: "mainnet"
});
console.log(result);
// {
// result: ["0x84b6c7d5970d5a73abe"]
// }Node.js プロジェクトで MCP サーバーをプログラム的に使用する場合:
// Start the MCP server as a child process
const { spawn } = require('child_process');
const mcpServer = spawn('npx', ['@mcpdotdirect/starknet-mcp-server']);
// Connect to it with the MCP client
const mcp = new McpClient({ process: mcpServer });
// Now you can use the client
const networks = await mcp.invokeTool("get_supported_starknet_networks", {
random_string: "any"
});
console.log("Supported networks:", networks);より高度な使用方法としては、HTTP API のラッパー クラスを作成したり、Axios などのライブラリを使用して API 呼び出しをよりクリーンにしたりできます。
このサーバーは、次の MCP ツールを実装します。
get_starknet_chain_info : Starknet ネットワークに関する情報を取得する
get_supported_starknet_networks : サポートされているStarknetネットワークのリストを取得します
get_starknet_eth_balance : Starknet アドレスまたは Starknet ID の ETH 残高を取得します。
get_starknet_token_balance : アドレスのトークンの残高を取得する
get_starknet_strk_balance : アドレスのSTRKトークン残高を取得する
get_starknet_native_balances : アドレスのすべてのネイティブトークン残高（ETH および STRK）を取得します。
resolve_starknet_name : アドレスのStarknet IDを取得する
resolve_starknet_address : Starknet IDのアドレスを取得する
get_starknet_profile : アドレスの完全な Starknet ID プロファイルを取得します
validate_starknet_domain : 文字列が有効なStarknet IDであるかどうかを確認する
get_starknet_block : 特定のブロックに関する情報を取得する
get_starknet_block_transactions : 特定のブロック内のトランザクションを取得する
get_starknet_transaction : トランザクションの詳細を取得する
get_starknet_transaction_receipt : トランザクションの領収書を取得する
check_starknet_transaction_status : トランザクションが確認されたかどうかを確認する
call_starknet_contract : コントラクトの読み取り専用関数を呼び出す
get_starknet_contract_class : 契約のクラス（ABI およびその他の情報）を取得します。
execute_starknet_contract : コントラクト呼び出しを実行する（書き込み操作）
get_starknet_token_info : トークンに関する情報を取得する
get_starknet_token_supply : トークンの総供給量を取得する
check_starknet_nft_ownership : アドレスが特定のNFTを所有しているかどうかを確認する
get_starknet_nft_balance : アドレスが所有するNFTの数を取得する
transfer_starknet_eth : あるアカウントから別のアカウントに ETH を転送する (金額は人間が読める形式で表示されます)
transfer_starknet_strk : あるアカウントから別のアカウントに STRK を転送する (金額は人間が読める形式で表示されます)
transfer_starknet_token : ERC20トークンをあるアカウントから別のアカウントに転送する（金額は人間が読める形式で表示）
サーバーは次の MCP リソースを提供します。
starknet://{network}/chain : 特定のネットワークのチェーン情報を取得する
starknet://networks : サポートされているすべてのネットワークのリストを取得します
starknet://{network}/block/{blockIdentifier} : 特定のブロックに関する情報を取得する
starknet://{network}/block/latest : 最新のブロックを取得する
starknet://{network}/address/{address} : アドレスに関する情報を取得する
starknet://{network}/tx/{txHash} : トランザクション情報を取得する
starknet://{network}/id/address/{address} : アドレスをStarknet IDに解決する
starknet://{network}/id/name/{name} : Starknet IDをアドレスに解決する
starknet://{network}/id/profile/{address} : アドレスのStarknet IDプロファイルを取得します。
LLM のやり取りの場合、サーバーは次のプロンプトを提供します。
explore_starknet_block : 特定のStarknetブロックに関する情報を探索する
explore_starknet_address : Starknet アドレスに関する情報を取得する
explore_starknet_transaction : Starknet トランザクションに関する情報を取得する
lookup_starknet_id : Starknet IDを検索するか、アドレスをStarknet IDに解決する
explore_starknet_id_profile : Starknet ID の完全なプロファイルを調べる
このサーバーをClaudeやGPTなどのAIアシスタントで使用する場合：
このMCPサーバーを使用するようにAIアシスタントを構成する
アシスタントはツールを使用してStarknetと対話することができます
クエリの例:
「アドレス0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5dのETH残高はいくらですか？」
「アドレス0x04d07e40e93398ed3c76981e449d3446f7c4e52aac5b3e8a37d7b0ca30845a5dのStarknet IDを検索してください」
「Starknet メインネットの最新ブロックには何が含まれていますか？」
「トランザクション 0x7e3a33ab42f2e24184763563b7b8482b53e3b89831ebc3eacf29d4d11f5198 に関する情報を取得します」
「Starknet ID vitalik.stark をアドレスに解決する」
秘密鍵はトランザクションの署名にのみ使用され、サーバーに保存されることはありません。
すべてのトークンの量は、 weiや最小単位ではなく、人間が読める形式（例：ETH、STRK、トークン単位）で指定されます。
操作を実行する前に、入力パラメータを常に検証してサニタイズする
本番環境での使用のために追加の認証メカニズムを実装することを検討する
実稼働環境ではHTTPサーバーにHTTPSを使用する
不正使用を防ぐためにレート制限を実装する
高価値サービスの場合は確認手順を追加することを検討してください
starknet-mcp-server/
├── src/
│ ├── index.ts # Main stdio server entry point
│ ├── server/ # Server-related files
│ │ ├── http-server.ts # HTTP server with SSE
│ │ └── server.ts # General server setup
│ ├── core/
│ │ ├── chains.ts # Chain definitions and utilities
│ │ ├── resources.ts # MCP resources implementation
│ │ ├── tools.ts # MCP tools implementation
│ │ ├── prompts.ts # MCP prompts implementation
│ │ └── services/ # Core blockchain services
│ │ ├── index.ts # Service exports
│ │ ├── balance.ts # Balance services
│ │ ├── blocks.ts # Block services
│ │ ├── clients.ts # Client utilities
│ │ ├── contracts.ts # Contract interactions
│ │ ├── starknetid.ts # Starknet ID services
│ │ ├── tokens.ts # Token services
│ │ ├── transactions.ts # Transaction services
│ │ ├── transfer.ts # Transfer services
│ │ └── utils.ts # Utility functions
├── package.json
├── tsconfig.json
└── README.mdカスタム ツール、リソース、またはプロンプトを追加する場合:
すべてのリソース、ツール、プロンプト名ではハイフン（ - ）の代わりにアンダースコア（ _ ）を使用してください
// Good: Uses underscores
server.tool(
"starknet_contract_call",
"Description of the tool",
{
contract_address: z.string().describe("The contract address")
},
async (params) => {
// Tool implementation
}
);この命名規則により、カーソルや他のAIツールとの互換性が確保されます。
詳細については以下をご覧ください。
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
Call a read-only function on a contract
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| calldata | No | Call data array (optional) | |
| entrypoint | Yes | Function name to call | |
| resultTypes | No | Expected return types for each result value (e.g., ['felt', 'uint256', 'address']) | |
| contractAddress | Yes | Contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only mentions 'read-only' but fails to disclose other behavioral traits like authentication or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but could benefit from a bit more detail; still it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks info on return values, errors, or network defaults, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3; description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calls a read-only function on a contract, distinguishing it from siblings which are mostly getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; no when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if an address owns a specific NFT
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| tokenId | Yes | Token ID to check | |
| ownerAddress | Yes | Owner's Starknet address or Starknet ID to check against | |
| tokenAddress | Yes | NFT contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It says 'check if an address owns a specific NFT', implying a read-only query. However, it does not disclose any behavioral traits such as network handling, error conditions, or whether it returns a boolean or other type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, clear sentence. Efficient but could be more descriptive without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ownership check with no output schema, the description is adequate. It covers the basic purpose and required parameters. Could improve by noting that it returns a boolean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no additional meaning beyond what the schema provides, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('check'), the resource ('NFT ownership'), and the subject ('an address'). It distinguishes from siblings like 'get_starknet_nft_balance' which returns a count, not a boolean ownership check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Implied usage for checking ownership of a specific NFT, but lacks when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a transaction is confirmed (finalized)
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'check if confirmed finalized' but does not disclose behavior for pending/failed transactions, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is front-loaded and direct. It is appropriately concise for a simple check, though it could benefit from a second sentence on behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple complexity, the description leaves out what 'confirmed' means and typical return values. Sibling tools provide richer context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds no additional meaning, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking if a transaction is confirmed (finalized). It uses a specific verb and resource, but does not differentiate from sibling tools like get_starknet_transaction or get_starknet_transaction_receipt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to prefer this over get_starknet_transaction or what conditions warrant using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a contract call (write operation)
| Name | Required | Description | Default |
|---|---|---|---|
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| calldata | No | Call data array (optional) | |
| entrypoint | Yes | Function name to call | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) | |
| accountAddress | Yes | Sender's Starknet address | |
| contractAddress | Yes | Contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It only says 'write operation' with no details on permissions, gas, transaction lifecycle, side effects, or whether the call is synchronous. Lacks behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which is concise but front-loads only the purpose. It lacks structure and additional information that would make it efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and a write operation, the description is incomplete. It does not explain the transaction flow, return value, or error scenarios, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what's in the schema; it does not explain parameter relationships or provide context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a contract call (write operation)', specifying the verb (execute), resource (contract call), and the nature (write operation). This distinguishes it from the sibling 'call_starknet_contract' which is likely read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies use for write operations but does not explicitly state when to use this tool versus alternatives like 'call_starknet_contract'. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific block
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| blockIdentifier | No | Block number, hash, or 'latest'/'pending'. Defaults to 'latest'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It merely says 'Get information' without specifying return behavior, error handling, or scope (e.g., whether it includes full transaction data).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but could benefit from slightly more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sibling tools with overlapping scope, the description is insufficiently complete. It omits any hint of what 'information' entails (e.g., block header, timestamp, etc.).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented in the schema. The description adds no extra semantic context beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves block information. However, it does not differentiate from the sibling tool 'get_starknet_block_transactions', which also targets blocks but for transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_starknet_block_transactions, or when not to use it (e.g., for chain-level info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transactions in a specific block
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| blockIdentifier | No | Block number, hash, or 'latest'/'pending'. Defaults to 'latest'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only says 'get transactions', implying a read operation but doesn't detail return format, error handling, or side effects. Important behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is front-loaded and efficient, though it could benefit from slightly more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 2 optional parameters, no output schema, and many sibling tools, the description is too sparse. It doesn't explain what blockIdentifier accepts (number, hash, etc.) or hint at the return type. More context is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already describes both parameters. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (transactions in a specific block). It distinguishes from siblings like get_starknet_block (block info) and get_starknet_transaction (single transaction), but does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or provide any exclusions or suggestions for related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a Starknet network
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states 'get information' without mentioning read-only nature, latency, or response format. Agent has no insight into side effects or data volume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Efficient but lacks detail; conciseness does not compensate for missing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description should explain return value structure (e.g., chain ID, block height). It does not, leaving agent uninformed about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. Description adds 'Defaults to Mainnet' which is not in schema, providing slight extra value. Baseline 3 aligns with minimal addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about a Starknet network' is clear in verb and resource but vague on what specific information is returned. It does not differentiate from sibling tools like get_starknet_block or get_supported_starknet_networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Agent must infer from name and description, which is insufficient among many similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the class (ABI and other information) of a contract
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| contractAddress | Yes | Contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. However, it only mentions the function's input and output in vague terms, failing to confirm that it is a read-only operation, any side effects, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. However, it is extremely brief and could be expanded slightly to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description does not clarify the structure or content of the return value beyond 'ABI and other information'. Missing details like error handling, rate limits, or examples make the description incomplete for an agent to safely use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it repeats 'contract' without elaborating on parameter details or providing context that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('the class (ABI and other information) of a contract'). It effectively distinguishes from sibling tools that deal with transactions, blocks, balances, etc., making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It simply states what it does without helping the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the ETH balance for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral transparency, but it only states the basic function. It fails to disclose traits like read-only nature, error handling, rate limits, or what happens if the address is invalid. This is insufficient for a tool that queries blockchain state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks information about return format (e.g., balance in wei or ether), error cases, or handling of invalid addresses. Given the tool's moderate complexity and lack of annotations or output schema, more context is needed for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds value for the address parameter by clarifying 'with or without .stark', but does not enhance the network parameter beyond the schema. Overall, slight improvement over schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), resource (ETH balance), and scope (Starknet address or Starknet ID), effectively distinguishing it from sibling tools like get_starknet_strk_balance or get_starknet_token_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to use get_starknet_strk_balance for STRK or get_starknet_token_balance for arbitrary tokens. It also doesn't mention prerequisites or context for using network parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all native token balances (ETH and STRK) for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully cover behavioral traits. It only states the function but omits details like error handling (invalid address/ID), rate limits, idempotency, or return format. This is insufficient for a data retrieval tool with potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear verb and resource, front-loaded, no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides basic purpose but lacks details on return structure, error conditions, and behavioral traits. With similar sibling tools, more context would be helpful but description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described (address can be ID, network defaults to mainnet). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves native token balances (ETH and STRK) for a Starknet address or ID, using specific verbs and resource. It distinguishes from sibling tools like get_starknet_eth_balance and get_starknet_strk_balance which fetch individual native tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for combining two native token queries into one call, but provides no explicit guidance on when to use this tool vs get_starknet_eth_balance or get_starknet_strk_balance. No when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of NFTs owned by an address for a specific collection
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| ownerAddress | Yes | Owner's Starknet address or Starknet ID | |
| tokenAddress | Yes | NFT contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lacks disclosure of edge cases (e.g., zero balance, invalid address) or any behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, clearly communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only balance query, the description is adequate. No output schema exists, but the return value (a number) is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the 3 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('number of NFTs'), and specifies the scope ('by address for a specific collection'). It distinguishes itself from sibling tool 'check_starknet_nft_ownership' which checks individual ownership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'check_starknet_nft_ownership'. Usage context is implied but not clarified with exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full Starknet ID profile for an address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID to lookup | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only restates the basic purpose. It does not disclose what 'full profile' includes, authentication needs, or any side effects. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description omits important context like what constitutes a Starknet ID profile, expected return format, and prerequisites. Without output schema, the agent cannot predict the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters fully (100% coverage). The description adds no additional semantic value beyond what the schema provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get', the resource 'full Starknet ID profile', and the input (address or Starknet ID). Distinguishes from sibling tools that focus on balances, transactions, blocks, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus related siblings like 'resolve_starknet_address' or 'resolve_starknet_name'. The description does not specify context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the STRK token balance for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address or Starknet ID (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states the function without mentioning read-only nature, error conditions, or response format, leaving significant gaps for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no waste. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks return value details (e.g., unit, decimals) and fails to mention network support despite the optional parameter. For a balance tool, this info is important but not critical given schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions Starknet ID just as schema does, but adds no new semantic detail like value units or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the STRK token balance for a Starknet address or ID, distinguishing it from siblings like get_starknet_eth_balance and get_starknet_token_balance by specifying the token type and identifier formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus similar balance tools (e.g., when to prefer STRK balance over native balances), nor any prerequisites or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the token balance for a Starknet address or Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| ownerAddress | Yes | Owner's Starknet address or Starknet ID | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It fails to disclose that this is a read-only operation, any required permissions, or what the response format looks like (e.g., raw balance vs. human-readable).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It is front-loaded and to the point, but could be more structured with separate sections for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain the balance format, decimals, or any constraints on the token/owner addresses, leaving an agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no extra meaning beyond what the schema already provides, so it meets the baseline for this metric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a token balance for a Starknet address or ID, which distinguishes it from sibling tools that handle native balances or NFTs. However, it doesn't specify that it's for ERC20 tokens, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_starknet_eth_balance, get_starknet_strk_balance, or get_starknet_native_balances. The description does not mention scope or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a token
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether the tool makes external network calls, any rate limits, or the nature of the request (e.g., read-only vs. state-changing). The description carries the full burden but fails to provide transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste. However, it is somewhat under-specified, sacrificing completeness for brevity. Front-loading is acceptable but more detail could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the complexity of a token info lookup, the description does not explain what information is returned (e.g., token name, symbol, decimals) or any edge cases. It is minimally complete but lacks sufficient detail for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema adequately documents both parameters. The description adds no further meaning beyond what the schema already provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get information about a token' is clear but vague. It does not specify what kind of information (e.g., name, symbol, decimals, total supply) is returned, and it does not distinguish from sibling tools like get_starknet_token_balance which also deal with tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_starknet_token_balance or get_starknet_nft_balance. The description lacks any context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total supply of a token
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description gives no behavioral details such as return format, units (e.g., raw integer vs. decimals), or whether it works for all token types. The description is minimal and lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. It is concise but could be slightly more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should provide more details about return value, edge cases, or typical usage. It is too sparse to be fully useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no value beyond the schema; the schema already explains both parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the total supply of a token, which distinguishes it from sibling tools like get_starknet_token_balance (balance for an address) and get_starknet_token_info (other metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context about prerequisites or limitations. The description simply states what it does without advising on scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a transaction
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details are disclosed beyond a generic description. With no annotations, the description should cover aspects like mutability, authentication requirements, or rate limits, but it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point, but it may be too brief for such a complex domain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential information about what 'details' are returned, network context, and how it differs from sibling tools. It is incomplete given the complexity and number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'transaction details', but it does not differentiate from the sibling tool 'get_starknet_transaction_receipt', which also gets transaction-related details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_starknet_transaction_receipt' or other StarkNet tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get transaction receipt
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | Transaction hash | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only repeats the tool name without adding any behavior details (e.g., error handling, default network, or data returned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (2 words) but lacks structure and detail. It earns its place by stating purpose, but is too brief to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and good schema coverage, the description fails to explain what a receipt is or how it differs from get_starknet_transaction. No output schema; description is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get transaction receipt', which clearly identifies the action and resource. However, it does not distinguish from sibling tools like get_starknet_transaction, which might also involve receipt data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of supported Starknet networks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any details about behavioral traits such as caching, data freshness, or potential delays. Since no annotations are provided, the description should compensate, but it remains minimal. It does not reveal if the list is static or dynamic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains zero extraneous information. It is appropriately concise for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, sibling tools are all different), the description is mostly sufficient. However, it could be improved by hinting at the output format (e.g., an array of network names) to help an agent understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not add parameter semantics, but none are needed. Schema coverage is 100% as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a list of supported Starknet networks'. It uses a specific verb ('Get') and resource ('supported Starknet networks'), and uniquely distinguishes it from sibling tools that operate on specific Starknet data or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context. Agents must infer its applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the address for a Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Starknet ID to lookup (with or without .stark) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get the address', implying a read operation, but does not mention error handling for invalid names, default network behavior, or any rate limiting. The agent lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is front-loaded and efficient, earning its place without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is minimally adequate. However, it fails to mention that the network parameter defaults to mainnet or what the return format is. For a tool with no annotations, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional detail beyond the schema, but it does reinforce the purpose. Baseline 3 is appropriate as the description does not detract or significantly add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the address for a Starknet ID' clearly states the verb (get), the resource (address), and the input (Starknet ID). It effectively differentiates from sibling tools like resolve_starknet_name, which likely does the reverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., resolve_starknet_name), nor does it mention any prerequisites, limitations, or when not to use it. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the Starknet ID for an address
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Starknet address to lookup (must be a valid address, not a name) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states a read operation ('Get'). It does not disclose behavioral traits such as error handling (e.g., if address is not found), rate limits, or authentication requirements, which are important for an agent to invoke the tool correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient. However, it could be slightly improved by specifying the return value or differentiating from siblings without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema, the description is incomplete: it does not describe the return value (what the 'Starknet ID' is), default behavior for the optional 'network' parameter, or error states. For a simple lookup tool, this leaves gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents the parameters. The tool description adds no additional meaning beyond restating the purpose; it does not clarify parameter interactions, defaults, or constraints beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('Starknet ID for an address'), but it does not differentiate from the sibling tool 'resolve_starknet_address'. The term 'Starknet ID' is ambiguous—whether it's a numeric identifier or a domain name—making it less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like 'resolve_starknet_address' or 'validate_starknet_domain'. The description implies usage for looking up an address, but lacks context for exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer ETH from one account to another
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient's Starknet address or Starknet ID | |
| from | Yes | Sender's Starknet address | |
| amount | Yes | Amount to transfer in ETH (human readable format, not wei) | |
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as transaction finality, gas implications, or potential failures. The only behavioral note is about the private key usage, which is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant information. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description and schema cover the basic functionality, the tool has 6 parameters and no output schema or annotations. Additional context (e.g., network implications, error handling) would improve completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 6 parameters. The description adds no additional semantic value beyond what is already in the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Transfer' and resource 'ETH' with the context 'from one account to another', effectively distinguishing it from sibling tools like 'transfer_starknet_strk' and 'transfer_starknet_token'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contexts where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer STRK from one account to another
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient's Starknet address or Starknet ID | |
| from | Yes | Sender's Starknet address | |
| amount | Yes | Amount to transfer in STRK (human readable format, not wei) | |
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the basic transfer action but does not disclose that it requires a private key, signs transactions, or modifies state irreversibly. Details about fee handling, error behavior, and confirmation are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and front-loaded with the verb. However, it is too minimal and adds little value beyond the tool name. It could be restructured to include key context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, financial transfer, required private key) and lack of output schema or annotations, the description is insufficient. It does not cover confirmation behavior, error cases, network defaults, or security considerations, making it incomplete for an AI agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters described in the schema (e.g., 'from', 'to', 'amount', 'privateKey', 'maxFee', 'network'). The description adds no additional parameter information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Transfer), the asset (STRK), and the scope (from one account to another). It distinguishes from sibling tools like transfer_starknet_eth and transfer_starknet_token by specifying STRK. However, it omits the specific blockchain (Starknet), which is implied by the tool name and siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., transfer_starknet_eth, call_starknet_contract). There is no mention of prerequisites such as sufficient balance or correct network, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer ERC20 tokens from one account to another
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient's Starknet address or Starknet ID | |
| from | Yes | Sender's Starknet address | |
| amount | Yes | Amount to transfer in token's standard units (human readable format, not in smallest unit) | |
| maxFee | No | Maximum fee to pay (optional) | |
| network | No | Network name (e.g., 'mainnet', 'sepolia'). Defaults to Mainnet. | |
| privateKey | Yes | Private key of the sender account (not stored, only used to sign the transaction) | |
| tokenAddress | Yes | Token contract address or Starknet ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only says 'Transfer' without detailing whether the transaction is signed immediately, what happens to nonces, or if it waits for confirmation. This is minimal for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, earning its place. However, it could be expanded slightly to include key context like the need for token approval or network selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is too sparse. It does not mention return values, error cases, or prerequisites (e.g., sufficient balance, token allowance), leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description adds no additional parameter meaning beyond the schema, but the schema itself is well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Transfer ERC20 tokens from one account to another', which is a specific verb+resource. It distinguishes from sibling tools like transfer_starknet_eth and transfer_starknet_strk that transfer specific tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for arbitrary ERC20 transfers but provides no explicit guidance on when to use this tool versus alternatives like transfer_starknet_eth for ETH, or considerations like token approvals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a string is a valid Starknet ID
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Starknet ID to validate (with or without .stark) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior like what 'valid' means or return format, but it only repeats the purpose, leaving ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, no output schema or behavioral details; validation criteria and expected result are missing, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear description; the tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'a valid Starknet ID', distinguishing it from sibling tools like resolve_starknet_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives; the purpose is implied but no context for selection is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0call_starknet_contractcheck_starknet_nft_ownershipcheck_starknet_transaction_statusexecute_starknet_contractget_starknet_blockget_starknet_block_transactionsget_starknet_chain_infoget_starknet_contract_classget_starknet_eth_balanceget_starknet_native_balancesget_starknet_nft_balanceget_starknet_profileget_starknet_strk_balanceget_starknet_token_balanceget_starknet_token_infoget_starknet_token_supplyget_starknet_transactionget_starknet_transaction_receiptget_supported_starknet_networksresolve_starknet_addressresolve_starknet_nametransfer_starknet_ethtransfer_starknet_strktransfer_starknet_tokenvalidate_starknet_domainScored across 25 tools
Each tool has a clearly distinct purpose, targeting specific operations such as balance queries for different tokens (ETH, STRK, native, generic), NFT checks (ownership vs balance), transfers, and contract interactions. No two tools are ambiguous.
All tool names follow a consistent 'verb_starknet_noun' pattern using snake_case (e.g., get_starknet_eth_balance, transfer_starknet_token). The verbs are appropriate and consistent across the set.
25 tools is on the higher side but justifiable for a comprehensive Starknet server covering blocks, transactions, contracts, tokens, NFTs, IDs, and transfers. Each tool serves a specific function without redundancy.
The tool set covers major Starknet operations: reading/writing contracts, querying balances, transfers, block/transaction info, NFT ownership, and domain resolution. Minor gaps like event querying or contract deployment exist, but core workflows are covered.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
