Skip to content
Eden Engine

Docs

Connect a client, make a call, read the bill.

Omnial is one HTTP MCP endpoint with a bearer token. No SDK to install, no OAuth flow to complete. If your client speaks MCP over HTTP, it is a config file away.

Get connected in about five minutes.

  1. Create an account

    Sign up with Google, GitHub or an email link. There is no password. An emailed link is valid for 15 minutes and works once, and no account is created until you open it.

  2. Mint an API key

    In the dashboard, create a key. It is shown once, at creation, and only its prefix is stored in readable form afterwards. There is no way to retrieve it later, so save it then.

    Give it the scopes it needs and no more. A key without runs:execute can search, inspect and read usage docs, and will be refused by omnial_execute. A per-key spend cap bounds what that key can spend in aggregate.

  3. Point your MCP client at the endpoint

    The endpoint is below, the credential is an Authorization: Bearer header, and the config block for your client is in the next section.

  4. Ask your agent to find a tool

    If the connection is healthy, eight tools appear in your client. Ask it to search the catalog for a capability and it will use them.

Setting this up with an agent instead of by hand? Send it /SKILL.md, a plain-text document written for an agent to read and act on, with no JavaScript and no sign-in needed to fetch it. The same document, with the config for your client and a copy button, is on the install page. The older /install.md URL serves the same text.

Endpoint

MCP endpoint
https://mcp.eden-engine.com/mcp

Authentication

header
Authorization: Bearer omn_live_REPLACE_WITH_YOUR_KEY

A static header, on every request. The MCP specification makes authorization optional and every developer-facing client supports a static header natively, so there is no OAuth flow in this version.

The exact file your client expects.

Each client uses a different file and key names; pick yours and we'll write it. Each tab is the whole file, not a fragment.

Paste a key to fill in the commands and snippets below. Most clients read it from your environment (OMNIAL_API_KEY) rather than the file. It stays in this browser tab — it is not sent to us, not stored, and not part of the page's HTML. Leave it blank and a placeholder is used that you can fill in later.

The CLI form writes the entry for you. Without --scope it saves to your local scope, not .mcp.json, so keep --scope project (shared with the repo) or switch it to user (all your projects).

Goes in .mcp.json (project) or ~/.claude.json (user)

This snippet holds no key. Put it in your environment first:

export OMNIAL_API_KEY=omn_live_REPLACE_WITH_YOUR_KEY

On Windows PowerShell:

setx OMNIAL_API_KEY "omn_live_REPLACE_WITH_YOUR_KEY"
.mcp.json
{
  "mcpServers": {
    "omnial": {
      "type": "http",
      "url": "https://mcp.eden-engine.com/mcp",
      "headers": {
        "Authorization": "Bearer ${OMNIAL_API_KEY}"
      }
    }
  }
}
or, from the terminal
claude mcp add --transport http --scope project omnial https://mcp.eden-engine.com/mcp --header 'Authorization: Bearer ${OMNIAL_API_KEY}'
  • The key is read from the OMNIAL_API_KEY environment variable, so the checked-in .mcp.json never holds a secret. Keep the single quotes around the header so your shell leaves ${OMNIAL_API_KEY} for Claude Code to fill in.
  • In a hand-written entry, "type": "http" is required. Without it the entry is read as a stdio server and the url is ignored.
  • Run `claude mcp list` afterwards; a healthy entry reports connected.

The tools are named omnial_* because they are Omnial's. The names are part of the wire protocol your client speaks, so they are shown exactly as your agent calls them.

Eight tools, and what each one promises.

The catalog is not exposed as one MCP tool per entry: listing it would use tens of thousands of tokens of your agent's context before it did any work.

  • omnial_search

    Find tools by keyword. Each hit says why it matched.

    Why

    It always answers with what it found. An empty list means the catalog has none of those terms, not that the engine declined to rank.

    Tuned to answer rather than refuse: returning a tool you can decline beats returning nothing, so search always ranks what it found. Relevance is shown relative to the best match in that answer, not as a probability, and every hit says which keyword or field it matched on, so a weak match shows as a weak match.

  • omnial_inspect

    The full contract: schemas, pricing, and a cost estimate for your input.

  • omnial_learn

    A usage guide for a tool you picked: what its parameters do, worked examples, failure modes, cost shape.

    Why

    Each guide is written for its tool and checked against the tool's schema.

  • omnial_execute

    Runs the tool. dry_run prices a call without spending anything.

    Why

    The quote is held while the call runs and the charge follows what the call actually cost.

    A quote is not a cap: the quote is held while the call runs, you pay the call's final price, and a call whose final price is above its quote is charged up to 2x the quote. Above that, Omnial absorbs the difference.

  • omnial_run_status

    Polls a run handle for anything that could not return inline.

  • omnial_balance

    Available and held balance, so an agent can plan its own budget.

  • omnial_cancel

    Stops a run you no longer want and releases what is left of its hold.

    Why

    The provider is asked to stop the job first, then the run settles as cancelled. Stopping a job that is already running can still cost what the provider had incurred by then, where it reports one.

    No tool supports stopping a call yet. Stopping a job is something a provider has to declare, and no tool in this catalog declares one today, so cancel answers with a refusal naming the tool. Releasing your hold while the provider keeps working would leave the cost with nobody. A synchronous run is refused too: abort your own request instead, which aborts the provider call with it.

  • omnial_runs

    Lists this workspace's runs, newest first. By default only the ones still in flight.

    Why

    Run handles are opaque and stateless, so an agent whose process restarted has no other way to find the runs it left behind. Returns handles omnial_run_status and omnial_cancel accept.

Five steps: search, inspect, learn, run, settle.

Written as your agent will call them. Every tool page in the catalog carries the same block with that tool's slug filled in.

agent
// 1. search: find something that can do the job
omnial_search({ query: "scrape a web page as HTML" })

// 2. inspect: what does it take, what does it return, what will it cost
omnial_inspect({
  tool: "omnial/web-scrape-html",
  input: { url: "https://example.com/product/1" }
})

// 3. learn: the usage guide written for this tool
omnial_learn({ tool: "omnial/web-scrape-html" })

// 4. run: price this exact call first (spends nothing, calls nobody)
omnial_execute({
  tool: "omnial/web-scrape-html",
  input: { url: "https://example.com/product/1" },
  dry_run: true
})

// then run it
omnial_execute({
  tool: "omnial/web-scrape-html",
  input: { url: "https://example.com/product/1" }
})

// 5. settle happens on our side: the actual cost is charged and the
//    rest of the hold is released. Check the balance at any time.
omnial_balance({})

Worth knowing

Slugs
Always provider/tool. omnial_search returns them; a slug that does not exist is refused with a pointer back to search rather than guessed at.
Categories
Data, not schema. Every search response carries the valid list, and an unknown value is refused with that list attached.
Estimates
omnial_inspect and dry_run both validate your input against the tool's own schema before pricing it.

Anything slow returns a handle.

A long job does not finish inside a request. Fast tools answer inline; everything else hands back an opaque run handle.

agent
omnial_execute({ tool: "omnial/agent", input: { prompt: "..." } })
// returns { run: "<opaque handle>", status: "RUNNING" }

omnial_run_status({ run })   // poll it
omnial_runs({})              // list this workspace's in-flight runs
omnial_cancel({ run })       // ask the provider to stop it

Why omnial_runs exists

Handles are opaque and stateless: nothing on the server maps your agent to its runs between calls. If your process restarts, this is the only way to find the runs it left behind, which are also the runs still holding your money.

A failure is a result your agent can read, not an exception.

A run that failed
Comes back as an error result, from omnial_execute and from omnial_run_status alike: a failed paid call is never indistinguishable from a successful one. QUEUED and RUNNING are not errors: the hold is taken and the job is live.
Not enough balance
A dry_run answers with sufficient_balance: false and the shortfall rather than failing opaquely. A real call in the same state is refused before any provider is contacted, and nothing is charged.
An unknown category or slug
Refused, naming what is valid. Silently matching zero rows would read as “this catalog cannot do that”.
Cancel on a tool that cannot be stopped
Refused, naming the tool. Stopping a job is something a provider has to declare, and no tool in this catalog declares one today. Releasing your hold while the provider keeps working would be worse than saying no.
A tool this deployment cannot execute
Withheld from search results and counted separately, with the cause named.

The numbers to know before you hit them.

Inline output: 32 KiB
Larger provider output is replaced by an envelope saying it is not the result, how large the real one is, and where to fetch the whole thing with the same API key. Nothing is discarded.
Provider response: 16 MiB
A response larger than this is refused loudly as a typed failure naming the limit and the bytes read, and the connection is cut rather than drained.
Rate limits
omnial_inspect returns the per-key and per-workspace request rates your calls are held to. The public catalog and its search are rate-limited per address.
Spend
Bounded by your balance, by any per-key spend cap, and, on any single run, by the enforced ceiling of 2x its quote. The quote itself is what gets held while the call runs; it is not a cap on the charge.

Both limits are enforced, not just documented: an inline result over 32 KiB is replaced with a fetch link rather than silently cut, and a provider response over 16 MiB is refused outright and the connection closed rather than drained to fit.

Building on Omnial? Calling tools from your product is fine; reselling the catalog isn't. Details

What is real today.

Live catalog

Omnial's catalog is live: real, working integrations are browsable at /tools and callable today. What's listed there is exactly what you can run right now, gated by the same live-provider check that decides what gets billed. The append-only ledger, hold-before-the-call and settle-after, the pricing engine and the eight MCP tools in front of all of it are the same infrastructure a live call actually runs on. The catalog keeps growing as more integrations clear verification and go live.

What that means for you right now

Everything on this page works: connect a client, then have your agent search, inspect, read a usage doc, and price a call. Real, callable tools are live in the catalog today, and it keeps growing as more integrations clear verification. If you want to be told as new ones go live, an account is the way to be reachable.