Starknet 블록체인을 위한 포괄적인 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 AI 에이전트에게 Starknet 네트워크와 상호 작용하고, 블록체인 데이터를 쿼리하고, 지갑을 관리하고, 스마트 계약과 상호 작용할 수 있는 기능을 제공합니다.
Related MCP server: AMOCA Solana MCP Server
Starknet MCP 서버는 모델 컨텍스트 프로토콜(Model Context Protocol)을 활용하여 AI 에이전트에 블록체인 서비스를 제공합니다. Starknet 생태계에 대한 포괄적인 인터페이스를 제공하여 AI 어시스턴트가 자연어를 통해 Starknet 블록체인 데이터 및 운영과 상호 작용할 수 있도록 지원합니다.
주요 기능은 다음과 같습니다.
블록체인 상태(잔액, 거래, 블록) 읽기
카이로 스마트 계약과 상호 작용
토큰 전송(ETH, STRK 및 기타 ERC20 토큰)
NFT 및 토큰 메타데이터 작업
StarknetID 도메인 확인(Ethereum의 ENS와 유사)
적절한 트랜잭션 처리를 통해 읽기 및 쓰기 작업 모두 수행
모든 서비스는 일관된 MCP 도구 및 리소스 인터페이스를 통해 제공되므로 AI 에이전트가 Starknet 블록체인 기능을 쉽게 발견하고 사용할 수 있습니다. Starknet 주소를 허용하는 모든 도구는 StarknetID도 지원하여 사람이 읽을 수 있는 ID를 자동으로 식별하여 백그라운드에서 주소를 확인합니다.
Starknet 통합 : Starknet.js를 사용한 전체 Starknet 블록체인 통합
네트워크 지원 : 메인넷과 세폴리아 테스트넷 모두 지원
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 네트워크를 지원합니다:
메인넷 : 주요 스타크넷 생산 네트워크
세폴리아(Sepolia ) : 이더리움 세폴리아에 대한 스타크넷의 테스트넷
Bun 1.0.0 이상(권장)
Node.js 18.0.0 이상
시작하는 가장 쉬운 방법은 npx 사용하여 패키지를 직접 실행하는 것입니다.
지엑스피1
이렇게 하면 먼저 설치할 필요 없이 최신 버전이 자동으로 다운로드되어 실행됩니다.
자주 사용할 계획이라면 전역으로 설치할 수 있습니다.
# Install globally
npm install -g @mcpdotdirect/starknet-mcp-server
# Then run from anywhere
starknet-mcp-server
starknet-mcp-server http# Add to your project
npm install @mcpdotdirect/starknet-mcp-server
# Using yarn
yarn add @mcpdotdirect/starknet-mcp-server
# Using pnpm
pnpm add @mcpdotdirect/starknet-mcp-server그런 다음 package.json 스크립트에 다음을 추가합니다.
"scripts": {
"starknet-mcp": "starknet-mcp-server",
"starknet-mcp-http": "starknet-mcp-server http"
}소스에서 실행하거나 로컬로 개발하려는 경우:
# Clone the repository
git clone https://github.com/mcpdotdirect/starknet-mcp-server.git
cd starknet-mcp-server
# Install dependencies
npm install
# Start the stdio server
npm start
# Or start the HTTP server
npm run start:http자동 재로드를 사용한 개발의 경우:
# Development mode with stdio
npm run dev
# Development mode with HTTP
npm run dev:http서버는 다음과 같은 기본 구성을 사용합니다.
기본 네트워크 : 메인넷
서버 포트 : 3000 (HTTP 모드)
서버 호스트 : 0.0.0.0(모든 네트워크 인터페이스에서 접근 가능)
이러한 값은 애플리케이션에 하드코딩되어 있습니다. 수정해야 하는 경우 다음 파일을 편집할 수 있습니다.
네트워크 구성: src/core/chains.ts
서버 구성: src/server/http-server.ts
Starknet MCP 서버는 두 가지 모드로 실행할 수 있습니다.
# Run the server in stdio mode (for CLI tools and AI assistants)
npx @mcpdotdirect/starknet-mcp-server
# Run the server in HTTP mode (for web applications)
npx @mcpdotdirect/starknet-mcp-server httpHTTP 서버는 기본적으로 포트 3000에서 실행되며 실시간 통신을 위해 REST API와 SSE(Server-Sent Events)를 모두 제공합니다.
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 서버 구성을 감지하여 사용합니다.
웹 애플리케이션을 개발 중이고 SSE(Server-Sent Events)를 통해 HTTP 서버에 연결하려는 경우 다음 구성을 사용할 수 있습니다.
{
"mcpServers": {
"starknet-mcp-sse": {
"url": "http://localhost:3000/sse"
}
}
}Claude CLI를 사용하는 경우 다음 두 가지 명령만으로 MCP 서버에 연결할 수 있습니다.
# Add the MCP server using npx
claude mcp add starknet-mcp-server npx @mcpdotdirect/starknet-mcp-server
# Start Claude with the MCP server enabled
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();Cursor에서 파일을 열어 놓으면 Cursor에 다음 작업을 요청할 수 있습니다.
"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를 찾아보세요."
"스타크넷 메인넷의 최신 블록에는 무엇이 있나요?"
"거래 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
}
);이 명명 규칙은 Cursor 및 기타 AI 도구와의 호환성을 보장합니다.
자세한 내용은 다음과 같습니다.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
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.
