@ordinal402/ordinal-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ORDINAL_URL | No | Marketplace origin. | https://www.ordinal402.xyz |
| ORDINAL_MCP_TOKEN | No | Only if the marketplace endpoint is gated. | |
| ORDINAL_PRIVATE_KEY | No | Payer key, 0x + 64 hex. Without it, paid calls explain why they cannot run. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_servicesA | Browse published Ordinal services. Optionally filter by free-text query, category, or a maximum price per call. Returns id, slug, name, description, price, and reliability metrics. |
| get_service_detailsA | Full detail for one service: input/output JSON Schema, price, example request and response, documentation, and the x402 settlement terms. Call this before try_service or call_service so the input matches the schema. |
| try_serviceA | Run a service without paying. Validates the input against the service schema and returns the provider's real response, but settles no payment and records no usage. Use this for demos and for checking output shape before committing to a paid call. |
| call_serviceA | Execute a real paid call, settled on Robinhood Chain from this machine's wallet (no key configured yet). The payment is signed locally; the private key never leaves this machine. Returns the provider response plus the settlement transaction. |
| check_payment_statusA | Look up a Robinhood Chain transaction by hash and report whether it succeeded, how many confirmations it has, and its explorer URL. |
| wallet_addressA | Reports which wallet this bridge will pay from, and whether a key is configured at all. Useful before a paid call. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct action: browsing, inspecting, trying, calling, checking payment status, and checking wallet identity. The try_service versus call_service distinction is clearly drawn by payment and settlement semantics.
Five of six tools follow a clear verb_noun snake_case pattern. The sole exception is wallet_address, which is a noun phrase rather than a get_* verb, but it remains readable and predictable.
At six tools, the set is tightly scoped to the service marketplace workflow: discover, inspect, try, pay, verify, and wallet identity. There is no bloat or redundancy.
The core lifecycle from discovery through paid execution to settlement verification is covered. Minor gaps exist: there is no transaction history tool and no way to configure the wallet within the MCP surface, but agents can work around both.