Why Omnial MCP exists
Your AI is limited by what it can reach.
It can talk, draft, analyse, plan. But the moment a task needs something real — live data, a scraped page, a transcription, an image, a verified contact — it stops. Because every one of those capabilities lives behind a vendor's account, a key, a bill and a contract nobody wants to babysit. This is the door we built instead: one connection, one balance, and your AI does the reaching.
The wall
Every capability your AI wants is locked behind its own door.
Not a hard wall — a thousand small ones, each run by a different company, each with its own rules.
A new account for every job
Search is one vendor. Enrichment is another. Media is another. Each wants its own signup, its own API key, its own bill and its own dashboard. Your AI does not care which one it is — but you end up running the procurement department for it.
A schema is not a teacher
A tool's input schema tells an AI which fields exist. It does not tell it which phrasing earns the good result, which option costs extra, or what fails quietly. An AI handed a raw spec uses the tool badly — and still gets the bill.
Cost is a mystery until after
Most tools price you after the fact, or not at all. Your AI cannot plan around a price it cannot see, and you cannot budget against a number you only find on the invoice. “How much did that cost?” should never be a question you answer with a spreadsheet.
The door
One connection. One balance. The rest is your AI's job.
Connect it once, and the loop your AI runs for the rest of its life looks like this — in the order it happens, and only the last one spends anything.
Say what you need
Your AI asks for the capability in plain words — “find this company's open roles”, “transcribe this call” — and gets ranked matches, each one carrying the reason it matched. If nothing matches, it says so plainly rather than guessing.
It reads the manual
Before it spends a cent, it reads the hand-written usage doc for that exact tool: what each option really does, the patterns that work, what drives the price. A schema tells it the shape; the manual teaches it the craft.
It prices the call, then makes it
It can price the exact input it is about to send — and spend nothing. When it runs the real thing, the call runs behind a hold on your balance: your AI can only ever spend what you have put in.
It pays for that one call
The actual cost settles out of your balance, to the billionth of a dollar, and any remainder of the hold is released. A call that failed is not charged for. You buy the work, per use — not a subscription to the possibility of it.
A single call is typically a fraction of a cent — on many of them, less than a tenth of a penny. That is the whole point of the balance: the unit of purchase is the thing your AI actually did, priced at what it actually cost, with nothing left over sitting in somebody else's ledger.
No monthly plans. No per-vendor accounts. No key per provider. No context wasted stuffing your AI with a definition for every tool it might ever touch — it finds the one it needs, the moment it needs it.
Who it is for
Built for the person, the builder and the business.
The same door works differently for each of you, and none of it requires becoming a different person to use.
The business owner
You get an AI that does, not just advises. It researches, pulls the data, drafts the asset, checks the number — and hands you the result. You never become the procurement department for your own intelligence.
The developer
One surface your AI actually uses well: a real contract on every tool, a price for the exact input before it runs, a manual that teaches it, and a balance you can meter. Fewer keys, fewer dashboards, fewer surprise invoices, and a call you can explain to the penny.
The agency and the builder
Put the capability inside your product or behind your own agent. Your users get the outcome, and you do not have to stand up, pay for and babysit a stack of upstream subscriptions to get it.
Why you can trust it with real money
The decisions that make it safe to hand to an AI.
An AI with a balance is an AI with spend authority. These are the six decisions that make that authority safe — stated plainly, with the technical detail underneath for the reader who wants it.
It knows what it will get back — before it pays
Every tool declares not only what it takes but what it gives back. Your AI sees the shape of the answer before it commits, so it is never learning the format by paying for a call and looking.
omnial_inspect returns the input schema and the output schema together, with the pricing model, a cost estimate for your exact input, measured latency and success rate, and the rate limits your key is held to. Declaring an output schema is a condition of shipping at all.
Money is exact, all the way down
Nothing near a balance is a floating-point number. A real rate card is quoted at a thousandth of a cent, and a system that rounds it into a float quietly accumulates a gap between what it charged and what it says it charged.
Balances are integer nanodollars (one in a billion of a dollar) on the wire, in the database and in every step of the arithmetic. The ledger is append-only — entries are only ever added — with a full balance snapshot on each, so any balance can be re-derived from its own history.
A price is a price
Real pricing is conditional: a base that depends on the mode, an extra past a threshold, a separate charge per page. A price that has to be flattened to fit is a price somebody is wrong about.
Conditions here are a predicate union (gte, lt, in, not), so “more than ten results” is expressible, and a composite price is a sum over exactly the components that apply to that call. The catalog build proves those components are mutually exclusive and refuses a price that knowingly omits a real charge.
Your AI can stop a run — and find one it lost
Two failures that cost real money: a long job started with the wrong input, and a crashed process that no longer holds the handle to a run still holding its money. Both have an answer.
omnial_cancel asks the provider to stop first, then settles and releases what is left of the hold — in that order, deliberately. omnial_runs lets a restarted agent enumerate its own in-flight runs. Where a tool cannot be stopped, the system refuses honestly instead of pretending.
No confident garbage
A wrong answer and a refusal look identical to an agent — so the surface is built to refuse. When it does not know, it says so and gives you the reason, rather than guessing and spending your money on the guess.
Search always answers, ranked, and every hit carries the reason it matched — including the plain admission that nothing matched and this is the nearest entry. A tool you can decline beats a tool you never saw. The same ranking serves this website's own search box, so what you can check here is what your agent sees.
A teacher, not just a spec
The differentiator is the usage doc. A schema tells an AI which fields exist; it does not tell it that a video model wants camera-motion language in the prompt, or that a scraper bills per result so one query at a time is cheaper.
Each tool ships a hand-authored usage.md — what the parameters really do and how they interact, the patterns that work, the failure modes worth anticipating, and what drives the bill. A tool cannot ship without one, and it cannot ship a worked example that does not validate against its own input schema. Your AI receives the full document at runtime, byte for byte.
Where we are today
A page that only lists wins is an advertisement.
These are the entries on the same list that go the other way — stated in the same voice, because the honest version is the one you can act on.
One live integration
We have one genuine vendor integration, now promoted to live and callable — the first real, working integration on this platform. Every other provider in the catalog remains synthetic: an invented vendor with a full contract, a modelled rate card and a hand-written usage doc, reachable only at a reserved host that resolves to nothing. Breadth is the honest gap today, and it is the reason to read most of this page as an argument about architecture rather than a finished buying decision.
No resource lifecycle
Everything here is request-shaped: a run holds money, executes and settles. Nothing in the model represents a provider artifact that outlives a call — a session, a sandbox, a rented proxy — and must be handed back. The first provider that provisions one would stretch the model rather than just use it, so that question is now asked of every candidate provider before a single file is written. That is not the same as having built it.
For developers and agencies
Are our tools powering your product, or are they your product?
The short version of a rule we state carefully: calling our tools to do your own product's work is something we consent to. Our catalog itself — the tool listings, the hand-authored usage docs, the course content we publish on this service, and the browsable, searchable presentation of them — being what you offer your users is not, and no agreement changes that.
Permitted: Omnial MCP is two layers. The server layer is permitted — our tools powering features inside your own product or your own backend systems, calling them programmatically with your own API key, so your users never need to know Eden Engine exists and you never have to sign up for and manage a stack of upstream provider subscriptions yourself. That includes your own AI agent, running inside your own agent harness — a commercial one included — calling our MCP server under your own branding to do your own product's work: your agent is calling the server layer to serve your own users' tasks, not distributing our catalog. For example: your SaaS backend calling omnial_execute to power a feature inside your product, or a commercial agent-harness product whose agent calls omnial_execute as one step in a task it runs for its own user, with nothing in your product naming Eden Engine or Omnial MCP — is something we consent to either way. Integration like this needs no whitelabel agreement, no special pricing, and no conversation with us first — the same self-serve signup and API key every integration uses is the only door, and there is no different one for a customer-facing product, commercial agent harness included. See the docs for exactly what is live to call today. That permission is about integration, not about what you do with a provider's data once you have it — a provider's data still comes with its own data-use restrictions, listed in the Terms' acceptable-use section.
Not permitted: the agent layer — our catalog itself: the tool listings, the hand-authored usage docs, the course content we publish on this service, and the browsable, searchable presentation of them — being, in whole or in substantial part, what you offer your users, whether or not you compete with us. That holds however you get there. Taking a copy of it, storing or caching it as something your users browse or search instead of coming to us, and proxying it live through your own agent so your users see the catalog under your brand are all “being us with a different name,” not integration, and none of it is something we consent to. Every tool and every usage doc under your brand is one example of that, not the bar you must clear before it counts — a partial copy, or a standing picker built from a slice of the catalog that your users go to in order to find tools, is still the catalog being what you offer your users, whether or not it competes with us. A derivative work — a paraphrase, translation, or summary of the listings or the usage docs that you publish, store, or hand your users as a substitute for coming to us for it (not a summary your agent gives one user in the course of running one task), a machine-generated adaptation of either, or using either to train a model you offer to third parties — is treated the same way. For example: standing up a lookalike tool directory or agent-tool product — by scraping this catalog, or by wiring an agent that mirrors omnial_search and omnial_learn live for your own users to browse — is not something we consent to, even if that browsing surface sits inside an otherwise legitimate agent harness that calls the server layer correctly everywhere else. The line is what your users can reach: your agent calling our tools to do your product's own work is the server layer; your agent exposing our catalog for your users to browse is the agent layer, and that is the clone. Ordinary use looks like naming the tool your agent is about to call and what it will cost, or summarising what one task needs for one user — not a page, a standing picker, or an index your users go to instead of coming to us.
If you want to do something in this area on the server layer — reselling access to the tools at scale, or a bulk or enterprise arrangement beyond ordinary integration, for example — ask first. We can license an expanded server-layer arrangement under a separate written agreement (what the terms call a Server-Layer Expansion Agreement), signed by an authorized officer on each side, that expressly names this exception; simply using the service, agreeing to our terms, or emailing us about a possible deal does not create that license, and you may not assume it is covered by the permission above. The agent layer is never part of that conversation: no agreement of any kind reaches the agent layer, and nothing on this page or in our terms changes that. Reach out or write to pixellabsweb3@gmail.com and we will work out the details directly.
Check any of it yourself.
Every tool page publishes the full contract and the pricing model, itemised charge by charge. Your agent receives the usage doc separately, at runtime. The install is a file you hand to your AI — it does the rest, and comes back to tell you it is ready.
Early access: our first provider integration is live — browsable and callable, the first real entry in this catalog. Every other provider is still below live; most are synthetic and reachable only at a reserved .example host, and one, echoco, is a non-commercial internal fixture instead. What that means.