Skip to content
Eden Engine

Docs

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

Omnial MCP 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 started

Four steps, about five minutes.

  1. Create an account

    Sign up with an email address. There is no password: creating the account and signing in both work by a link emailed to you, valid for 15 minutes and usable once. Nothing is created until you open that link.

  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 doing it by hand? Send it /SKILL.md, a plain-text document written for an agent to read and act on directly, with no JavaScript and no sign-in required to fetch it. The same document, with the config for your specific client and a copy button, is on the install page. (The older /install.md URL serves the identical body and is not going away.)

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.

Client configs

The exact file your client expects.

The shapes genuinely differ: one client roots its config at servers rather than mcpServers, another names the endpoint serverUrl rather than url, and getting one key name wrong costs your first ten minutes. Each tab is the whole file, not a fragment.

Paste a key to have it written straight into the snippet below. 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 the snippet uses a placeholder you can fill in later.

Project-scoped .mcp.json is checked in and shared with the repo; the CLI form below writes it for you.

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

.mcp.json
key placeholder, replace before use
{
  "mcpServers": {
    "omnial": {
      "type": "http",
      "url": "https://mcp.eden-engine.com/mcp",
      "headers": {
        "Authorization": "Bearer omn_live_REPLACE_WITH_YOUR_KEY"
      }
    }
  }
}
or, from the terminal
claude mcp add --transport http omnial https://mcp.eden-engine.com/mcp --header "Authorization: Bearer omn_live_REPLACE_WITH_YOUR_KEY"
  • Claude Code needs the explicit "type": "http". 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 MCP tools are named omnial_* because this product is Omnial MCP (in full, Eden Omnial MCP), one product under the Eden Engine umbrella. The names are part of the wire protocol your client speaks, so they are shown here exactly as your agent will call them.

The tool surface

Eight tools, and what each one promises.

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

ToolPurpose
omnial_searchKeyword query to ranked tools, each carrying the reason it matched. It always answers with what it found. An empty list means the catalog genuinely carries 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. Against its 44-query set the right tool is first 43 times. 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 is visible as a weak match rather than dressed up as a confident one.
omnial_inspectThe full contract: input schema, output schema, pricing, a cost estimate for your actual input, latency and success rate.Latency and success rate are measured from this deployment's own runs, so they read as unknown until it has made some.
omnial_learnHand-authored instructions for a tool you have already chosen: what its parameters actually do, worked examples, failure modes, cost shape.
omnial_executeRuns the tool. Supports dry_run to price a call without spending anything. 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 are charged what the call actually cost, and a call that costs more than its quote is charged up to 2x the quote. Above that, Omnial MCP absorbs the difference.
omnial_run_statusPolls a run handle for anything that could not return inline.
omnial_balanceAvailable and held balance, so an agent can reason about its own budget.
omnial_cancelStops a run you no longer want: the provider is asked to stop the job, then the run settles cancelled and whatever is left of the hold is released. An agent that passed the wrong input to a long job can stop paying for it instead of waiting for the provider to finish. Stopping a job that is already running can still cost you what the provider had incurred by then, where it reports one.It refuses rather than pretends. Stopping a job is a capability 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 and keeps billing would be a loss with nobody to attribute it to. A synchronous run is refused too, with the same honesty: abort your own request instead, which aborts the provider call with it.
omnial_runsLists this workspace's runs, newest first; by default only the ones still in flight, which are the ones still holding money. 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.
Worth repeating

No SDK to install, no OAuth flow to complete.

Your first call

Search, inspect, learn, price, run.

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. find something that can do the job
omnial_search({ query: "scrape a product page" })

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

// 3. how to use it well, from its author
omnial_learn({ tool: "crawlco/scrape" })

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

// 5. run it
omnial_execute({
  tool: "crawlco/scrape",
  input: { url: "https://example.com/product/1" }
})

// and, 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.

Long-running runs

Anything slow returns a handle.

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

agent
omnial_execute({ tool: "genco/videogen-1-pro-t2v", input: { /* ... */ } })
// -> { 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.

Errors and refusals

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 a capability a provider has to declare; no tool in this catalog declares one today, and 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. A missing provider credential is a fact about the deployment, not about the catalog.

Limits

The numbers worth knowing 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. Truncation is a delivery decision, never a storage one.
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.

One more thing worth knowing before you wire this in: calling these tools to power your own product, under your own brand, is permitted; making our catalog itself — the listings, the hand-authored usage docs your agent reads through omnial_learn, or this directory's agent-tool surface — what you offer your users, in whole or in substantial part, whether copied or proxied live, is not. See /legal/terms#acceptable-use for the policy, and /why#whitelabel for worked examples of it. Integration permission is separate from data-use restrictions: a provider's data still carries its own, listed in the same /legal/terms#acceptable-use section.

Status

What is real today.

Early access: what is real and what is not

Omnial MCP's catalog is no longer empty: our first provider integration, a genuine vendor account, has been promoted all the way to live — it is browsable at /tools and callable today, the first real, working integration on this platform. Every other provider defined so far remains below live. Most are synthetic: an invented vendor with a full input and output contract, a modelled pricing structure and a hand-authored usage doc, reachable only at a reserved .example host that resolves to nothing. One entry, echoco, is not synthetic and is not a vendor either: it is an internal fixture that calls a real, free public test endpoint solely to prove the pipeline end to end, and nothing about it is for sale. Nothing about those remaining entries is a working paid integration, and no figure on this site attached to them is revenue. What that live integration proves, and what the platform around it was already built and tested for, is real: the append-only ledger, hold-before-the-call and settle-after, the pricing engine, the eight MCP tools, and now real, callable tools behind them.

A synthetic provider is a complete catalog entry (input and output schemas, a modelled pricing structure, rate and usage limits, a hand-authored usage doc, worked examples validated against its own schema) pointed at a reserved .example host. The catalog linter requires that disclosure and refuses a fabricated provider whose egress hosts are not reserved, so nothing in this catalog can quietly reach a real vendor.

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; most of it is not stocked yet. If you want to be told as more of it fills in, an account is the way to be reachable.