Question 1

Where does my key actually live?

Accepted Answer

In your OS keychain, the same vault your machine already uses for passwords. Gecko reads it on your machine at the moment of the call and sends it only to the API's own domain. It never enters the agent, your files, or Gecko's servers

Question 2

What can Gecko see?

Accepted Answer

The API's shape (endpoints, parameters, schemas) and the tools it generates from that. Not your responses, not your data, not your keys. The call goes from your machine to the API's own host. Gecko routes the intent, not the payload

Question 3

What if an API tries to trick my agent?

Accepted Answer

It happens: a manipulated description or example crafted to steer an agent into a dangerous move. Gecko screens everything an API says before your agent sees it, and quarantines anything suspicious. Running today, on every API it reads

Question 4

What if my API has no OpenAPI spec?

Accepted Answer

We read the docs. For Mintlify, Redoc, and Scalar we discover the spec behind the page. If we can't find one, we tell you what to paste

Question 5

Is it free?

Accepted Answer

The engine is open source and free. Providers pay a flat per-API fee, never a take-rate

Question 6

Does it work outside Claude Code?

Accepted Answer

Yes. Any MCP client (Cursor, Windsurf, Claude Desktop) connects via the hosted endpoint in one line. Python library if you prefer to call it directly. Recorded mode ($0, fully offline) works everywhere

Question 7

How is this different from an MCP wrapper?

Accepted Answer

MCP is the pipe. A wrapper just opens it: every endpoint becomes a tool, auth is still your problem, and when your agent needs to pick the right call across five APIs, the wrapper has nothing to say. Gecko adds the layer that makes the pipe worth using: it reads the API first, builds a graph of what to call and when, seals your key, and answers when the agent has to choose. We are not replacing MCP. We run on top of it

Question 8

What's a 'mainnet fork', and why does a rehearsal on one count as evidence?

Accepted Answer

A fork is a local copy of the real chain's current state: real programs, real balances, real compute. You can transact against it for free without touching the actual network. It's not a mock: the fork answers with the same logic and state the real chain would, so a call that's correct on the fork is correct against reality, not against a fiction we wrote

Question 9

Why a coffee shop?

Accepted Answer

We needed a real, live, on-chain surface with real money at stake to test against, not a synthetic one. A storefront built on a widely-referenced example program turned out to be exactly that: the defects we found in it are the same class of defect sitting in every project built from the same example

ORE program

Use cases

Tools served now

ORE program

Use cases

Tools served now