Maestro Api

Query Maestro APIs over HTTP using the SIWX + JWT + x402 credit purchase flow. Resolve the exact endpoint from docs.gomaestro.org before requesting or paying.

Security Scan

The skill's instructions match the Maestro SIWX + x402 payment flow, but it requires signing with a private key and making real on-chain payments while its registry metadata declares no required credentials or provenance — this mismatch and the sensitivity of signing operations merit caution.

Purpose & Capability

The skill's name and description match the runtime instructions: resolving docs.gomaestro.org, performing unauthenticated requests, doing SIWX authentication, and buying credits via the x402 flow. Asking for a wallet signer and funds is coherent with the stated purpose. Minor concern: the package metadata declares no required environment variables or primary credential even though the SKILL.md explicitly says the agent will need a PRIVATE_KEY or a runtime wallet signer and on-chain funds.

Instruction Scope

SKILL.md is narrowly scoped to resolving an operation page in docs.gomaestro.org, issuing the HTTP request, handling 402/SIWX/JWT flows, and performing the specified payment retry. It does not instruct broad system scanning or exfiltration, and it contains concrete steps (confirm before first paid mainnet request). The instructions do ask the agent to perform signing and to send payment headers and JWTs — exactly what this API requires.

Install Mechanism

No install spec and no code files — instruction-only skill. This reduces disk-write/remote-code risks; there are no external downloads or package installs to review.

Credentials

The functional flow requires a signing capability (PRIVATE_KEY or runtime CDP wallet signer) and on-chain funds (USDC + gas). That is proportionate to making paid Maestro requests, but those are highly sensitive credentials. The skill's metadata lists no required env vars or primary credential, so there's a mismatch between what it will need at runtime and what is declared in the registry. Because the agent will be asked to sign EIP-191 and EIP-712 messages and potentially submit payments, users should not paste long‑term private keys into prompts; a hardware/external signer, ephemeral key, or explicit gating is recommended.

Persistence & Privilege

The skill does not request always:true, has no special OS or install privileges, and does not modify other skills. Model invocation is allowed (normal). Nothing in the files requests persistent agent-level changes.

What to consider before installing

This skill performs real Maestro API calls and may ask you to sign messages and pay on-chain. Before using it: (1) do not paste a long‑term private key into a chat prompt — prefer a hardware or external signer or an ephemeral/test key; (2) demand explicit, human confirmation before any mainnet payment (network, pay_to address, amount in USDC atomic units, and the docs page used); (3) test on a non‑mainnet network first; (4) verify docs.gomaestro.org is the correct official docs URL and confirm the operation page it resolved; (5) consider using a wallet that can produce signatures without exposing raw private key material (browser wallet, HSM, or wallet-connect flow). The skill's registry metadata lacks declared credentials and has no homepage or source, so you should be cautious about trusting it with real funds or private keys.

Use this skill when the user wants a direct HTTP call to a Maestro endpoint. The intended path is short: resolve the exact operation page, send the real request, satisfy the live SIWX challenge, and only buy credits if the server still returns 402.

Fast Path

1. Resolve the exact operation page in docs.gomaestro.org.
2. Read the page's .md form and use its OpenAPI block as the source of truth.
3. Build the request URL from servers: plus the operation path.
4. Send the real request with no auth or payment headers.
5. If the response is 200, return the data.
6. If the response is 402 with extensions.sign-in-with-x, sign the SIWX challenge and retry the exact same request with sign-in-with-x.
7. If that retry returns 200, return the data.
8. If that retry returns 402 plus Authorization: Bearer <jwt>, buy credits from the latest accepts[] entry and retry the exact same request with Authorization and X-PAYMENT.
9. Reuse the JWT for follow-up queries until it expires or Maestro asks for more credits.

Resolve Endpoint From Docs

Use docs only to find the exact operation page. Do not browse broadly once you have it.

• Start with https://docs.gomaestro.org/llms.txt only if the operation page is not already obvious.
• Prefer operation pages over quick-start pages.
• Read the .md page and extract:
  • operation line -> path
  • servers: -> base URL for the chosen network
  • parameters and body schema -> request shape
• Combine server.url + path.
• Do not derive the REST host from the SIWX domain or URI.
• Useful Bitcoin routing shortcuts:
  • confirmed chain data -> Blockchain Indexer API
  • mempool-aware or pending data -> Mempool Monitoring API
  • mempool.space-style routes -> Esplora API
  • wallet balances or wallet activity -> Wallet API

Minimal Prerequisites

Ask only for what is required to sign and pay:

• PRIVATE_KEY, or a runtime CDP wallet signer
• enough USDC and native gas on one network from the live 402 response
• no API key

Request Rules

• Keep method, path, query parameters, and body unchanged across the unauthenticated request, the SIWX retry, and the paid retry.
• Always use the latest 402 response for supported_chains, accepts[], asset, pay_to, and price limits.
• Confirm before the first paid mainnet request.
• If a paid retry still fails, report:
  • docs page used
  • selected network
  • selected amount
  • signer address
  • minimal next action

Read Only When Needed

Read SIWX + x402 Reference only when you need the exact signing or header details:

• sign-in-with-x payload format
• X-PAYMENT payload format
• EIP-4361 SIWX message template
• ERC-3009 EIP-712 domain and message fields
• response header meanings
• failure cases and common pitfalls