How it works

One call, from “I need a capability” to a settled charge.

Your agent connects to one endpoint with one credential. What follows is the whole loop: five moves, eight tools, and money that is held before the call and settled after it.

Install it on your agent New to MCP? Start here

The lifecycle

Discover, inspect, learn, execute, settle.

Five steps, in the order an agent takes them. Only one of them spends anything.

Discover a tool by the words you would type
omnial_search
A keyword query comes back as a ranked list, best first. Every hit carries match_reasons: which authored keyword it hit, which query terms appear in its name, its taxonomy or its description, or the plain admission that nothing matched and this is the nearest entry.
It always answers. An empty list means the catalog genuinely holds none of those terms, not that the engine declined to rank. The relevance beside each hit is that hit's score over the best score in the same answer, not a probability and not comparable between queries.
Filtering by a category that does not exist is refused, with the list of real categories attached. A typo that silently matched zero rows would read to an agent as “this catalog cannot do that”.
Read the contract before committing to it
omnial_inspect
The full contract: input schema, output schema, the pricing model, a cost estimate for the exact input you pass, measured latency and success rate, and the rate limits your key and workspace are held to.
The input is validated against the tool's own schema before it is priced. Quoting a confident price for an input the tool would reject sends an agent off to budget for a call that can never run.
Latency and success rate are measured from this deployment's own runs, so they read as unknown until it has made some.
Read instructions written for an agent
omnial_learn
Returns the tool's usage.md, byte for byte: the full document, not a summary, and not something this app publishes anywhere on the website — this call is the only way to read it. It is written for a reader who has already chosen the tool: what the parameters really do and how they interact, the patterns that work, the failure modes worth anticipating, and the shape of the bill.
A tool cannot ship without one. What it says is its author's to decide; that it exists, and that its worked examples are legal calls against its own input schema, is the build's.
Price the call, then make it
omnial_execute
dry_run: true prices the exact input and spends nothing. No provider is contacted. It answers the affordability question rather than failing it: not enough balance comes back as sufficient_balance: false with the shortfall, not as an opaque error.
For real, the run holds its quote before the provider is called. That hold is what the call is expected to cost, not a cap on the charge: settlement follows what the call actually cost, bounded at 2x the quote. Fast tools return inline; anything slower returns a run handle.
Provider output is capped at 32 KiB inline. Past that the result is replaced by an envelope that says it is not the result, how big the real one is, and where to fetch it whole. An agent that pays for a call and then loses its context window to the answer has been served badly.
Settle: charge the actual, release the rest
On success the actual cost is charged and the remainder of the hold released. Where the call cost more than its quote, the excess is charged too and can take the balance negative: a debt, which stops new runs until it is cleared. Above 2x the quote we absorb the difference and quarantine the tool. On failure the hold is released in full: a run that did not come back is not charged for.
The ledger is append-only and every entry carries a full balance snapshot, so each run's page can show estimated, held and actual side by side with the entries that moved the money.

Settlement runs the same three bands on every call: at or under the quote you pay the actual cost, above it up to 2x the quote the excess is charged too, and past that the platform absorbs the rest and pulls the tool from the catalog. The 32 KiB inline cap is enforced identically for every provider, with no per-tool exception.

The money

Metered per call, against a balance you put there first.

No plan, no seat, no minimum. What a call costs is decided before it runs and reconciled after it.

The balance is prepaid, and every run moves through it in two steps rather than one: the quote is held while the provider works, and the actual cost is charged when it answers. That is what makes a failed call free and a cheap call cheap: you are not billed the estimate, you are billed the result.

Amounts are integers of a billionth of a dollar end to end, on the wire and in the ledger, so a charge far below a cent is exact rather than rounded into existence. An agent can read its own balance mid-task and decide whether it can afford the next move.

What moves, and when

Search, inspect, learn: Free. No provider is contacted and no money moves.
dry_run: Free. Prices the exact input and answers whether the balance covers it.
Execute: Holds the quote, calls the provider, then charges what it actually cost and releases the remainder. A charge above the quote is bounded at 2x it.
Failure: Releases the hold in full.

Run out mid-run and the run fails

A call that exhausts the balance while it is in flight does not pause and wait for you. It fails. Auto top-up exists for exactly that, and it is the one billing setting worth turning on before your agent has anything to do.

The full charge model, itemised (including the parts that cost you) is on the pricing page.

Runs that outlive the call

A video render does not finish inside a request.

Anything slow returns a handle instead of a result, and three tools exist for what happens next.

Poll it

The handle is server-minted and opaque, and it is passed back as an argument. Nothing in this system keeps session state. A run that failed is reported as a failure here, not as an ordinary success with bad news in the prose.

omnial_run_status

Find one you lost

Handles are stateless, so an agent whose process restarted has no other way to find the runs still holding its money. It lists this workspace's runs, in-flight by default.

omnial_runs

Stop one

Asks the provider to stop the job, then settles the run cancelled and releases whatever is left of the hold. Stopping a job already in flight can still cost you what the provider had incurred by then, where it reports one. The provider is told first and the money released second: settling first and then failing to reach the provider would release money against a live job.

omnial_cancel

Cancel refuses more often than it succeeds today

Stopping a job in flight is a capability a provider has to declare, and no tool in this catalog declares one yet. So omnial_cancel refuses, naming the tool, rather than releasing your hold while the provider keeps working and keeps billing. The success path is built and proven end to end; what it needs is a provider that supports it.

The surface

Eight tools, not one per catalog entry.

Listing a whole catalog through MCP would consume tens of thousands of tokens of an agent's context before it did any work. Every claim below is the one made on the connect page and in the docs, from one source.

Tool	Purpose
omnial_search	Keyword 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_inspect	The 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_learn	Hand-authored instructions for a tool you have already chosen: what its parameters actually do, worked examples, failure modes, cost shape.
omnial_execute	Runs 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_status	Polls a run handle for anything that could not return inline.
omnial_balance	Available and held balance, so an agent can reason about its own budget.
omnial_cancel	Stops 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_runs	Lists 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.

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 list above is kept in lockstep with what the server actually registers, so it cannot drift from what your agent sees on connecting.

End to end

What the loop looks like in practice.

Four calls, in the order an agent makes them. Slugs and inputs are illustrative; every tool page carries the same block filled in for that tool.

agent

// 1. find a tool for the job, in the words you would type
omnial_search({ query: "transcribe an audio file" })
//    -> ranked hits, each with match_reasons and a set-relative relevance

// 2. read the contract and price YOUR input
omnial_inspect({
  tool: "transcribeco/transcribe-prerecorded",
  input: { audio_url: "https://example.com/call.mp3" }
})
//    -> input_schema, output_schema, pricing, estimate, limits

// 3. read the usage doc before calling it
omnial_learn({ tool: "transcribeco/transcribe-prerecorded" })

// 4. price it for real, then run it
omnial_execute({ tool: "...", input: { /* ... */ }, dry_run: true })
omnial_execute({ tool: "...", input: { /* ... */ } })
//    -> a result, or a handle to poll with omnial_run_status

The connection

One endpoint, one header, one file on your machine.

There is nothing to install and no SDK to add to your project. Every client above speaks Streamable HTTP over one URL, authenticated by a static bearer header, so connecting is a config file and a key. The exact block differs per client: the root key and even the field the endpoint goes in are genuinely not the same between them, so the page that asks which one you use writes it for you.

The fastest version of all of this is not doing it by hand at all: hand your agent SKILL.md and it writes its own config, then tells you what it needs from you.

Get the exact config for your agent Full connection docs

.mcp.json · Claude Code

{
  "mcpServers": {
    "omnial": {
      "type": "http",
      "url": "https://mcp.eden-engine.com/mcp",
      "headers": {
        "Authorization": "Bearer omn_live_REPLACE_WITH_YOUR_KEY"
      }
    }
  }
}

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

See it against a real catalog entry.

Every tool page carries its full contract and its pricing model, itemised charge by charge. Omnial MCP hands the complete usage doc to your agent separately, at runtime, not on the page. Eden Engine builds the platform around them; the notice beside this says exactly how far that has got.

Install it Browse the catalog How billing works

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.