Mezcal ExplorerMezcalDocs
QuickstartBuildAgentsReference
Open explorer
Documentation homeQuickstartConceptsMonitor 10 Wallets
BuildLaunch MatrixAPIAdvanced UtilitiesAgent HTTP quickstartRate limitsRoute examplesSelf-serve account routesSDKTypeScript SDK

Live reference

Interactive API referenceReference hub
AgentsAgent CLIMCP Quickstart
Reference Hub
Docs/Agents

Agents

Use Starkscan with coding agents through the CLI and hosted MCP transport.

API referenceReferenceQuickstartCLI

In this guide

Recommended orderFirst working setupWorking MCP config snippetBest first toolsWhy three paths existWhen not to start here
Loading documentation content…
PreviousTypeScript SDKUse the first-party Starkscan TypeScript client when you want typed explorer reads in application code.NextAgent CLIUse the Starkscan CLI for shell workflows, release validation, and local-first exports.

On this page

Recommended orderFirst working setupWorking MCP config snippetBest first toolsWhy three paths existWhen not to start here
Mezcal ExplorerMezcalDocumentation

One product surface across the explorer, HTTP API, CLI, SDK, and MCP transport. The docs should guide you into the right path instead of behaving like a separate app.

Open explorerAPI referenceBack to top

Agents

Use the Agents lane when a human or model is operating Starkscan through tools instead of raw REST requests.

Starkscan currently exposes three agent-facing paths:

  • CLI path: best for Codex, Claude Code, and local shell workflows
  • MCP path: best for remote clients that speak the Model Context Protocol
  • bounded HTTP path: best when a coding agent should stay on a fixed published route set without MCP

Recommended order

  1. Start with Agent HTTP quickstart if the agent will make direct HTTP requests
  2. Start with the CLI guide if you control the local shell
  3. Then move to MCP quickstart if you need remote agent access

First working setup

For most agent users, the shortest path is:

  1. install mezcal
  2. point it at the hosted external /api base
  3. let the client run mezcal mcp serve --transport remote

Shared environment:

export MEZCAL_BASE_URL="https://<your-mezcal-host>/api"
export MEZCAL_API_KEY="mzk_live_your_key_here"
export MEZCAL_CHAIN="SN_MAIN"

Working MCP config snippet

If your agent client wants a JSON config instead of a one-shot command, this is the minimum useful shape:

{
  "mcpServers": {
    "mezcal": {
      "command": "mezcal",
      "args": ["mcp", "serve", "--transport", "remote"],
      "env": {
        "MEZCAL_BASE_URL": "https://<your-mezcal-host>/api",
        "MEZCAL_API_KEY": "${MEZCAL_API_KEY}",
        "MEZCAL_CHAIN": "SN_MAIN"
      }
    }
  }
}

That is the practical parent-page answer for Claude Code, Codex-adjacent setups, Cursor-like MCP clients, and other tool-calling environments.

Best first tools

When you are replacing lightweight chain reads with an agent, start with:

  • status
  • block_detail
  • block_transactions
  • token_total_supply
  • token_balance_of
  • token_transfers

Those give the agent a narrow, typed Starkscan surface before it starts guessing at raw chain structure. For direct HTTP agents, the broader block route set is GET /v1/{chain}/block/{number_or_hash} for canonical block detail and GET /v1/{chain}/block/{number}/txs for the ordered block transaction list after you resolve a numeric block number. The {number_or_hash} placeholder here means block number or block hash. If you need the current head block, fetch GET /v1/{chain}/status first and then call /block/{number_or_hash} with the returned block number or block hash.

Why three paths exist

They solve different problems:

  • bounded HTTP is the safest path when an agent should stay on a fixed published route set
  • CLI is the fastest and simplest path for power users, local exports, and deterministic terminal workflows
  • MCP is the structured remote contract for tool-calling clients

That separation is intentional. It keeps direct HTTP agents on a bounded contract, keeps the local developer flow fast, and gives remote tool-calling clients a safer, more explicit auth and policy boundary.

When not to start here

  • Use Agent HTTP quickstart when the client should call the published REST surface directly.
  • Use the REST API for direct service integrations.
  • Use the SDK for typed application code.
  • Use the CLI when you need explicit commands or local exports more than tool calls.
  • Stay in the explorer app when the job is visual investigation rather than automation.