The model decides what to do. Then it needs to act — and your API doesn't expose what the UI has always done. Pontil generates the tools your agents need from your existing APIs, and keeps them current as the product changes.
The PoC worked. The agent reasoned through the task, picked the right action — and then there was no tool to call, because the API never exposed what the UI does.
This is where agent projects stall: not on the model, on access. Your product spent years being built for the interface, and the API kept up with some of it. Now you're the one expected to ship the agent roadmap on top of a surface that can't reach half of what the product does.
A rewrite isn't yours to authorise and wouldn't land in time anyway. Building connectors by hand pulls you off AI work and into platform firefighting.

Pontil operates in the tools layer — between the model that reasons and the product that gets acted on. It's one of three connection directions on the platform; this is the one you care about.

Scans your codebase and produces structured action definitions from the endpoints that exist, including the surface behind your UI — not just the published API.

Composes those actions into higher-level tools that map to real tasks, with the people who know the product approving what gets exposed.

A managed runtime executes calls deterministically and handles failure, rate limiting, observability, and auth lifecycle. The SDK surfaces the tools available to the current user and fetches current definitions at call time — so agents see the latest version of a tool without a redeploy.
You could build this. The first version isn't the hard part — a handful of hand-written tool definitions against your main endpoints will demo well.
The hard part is everything after: coverage across the product surface, keeping definitions in sync every time the product ships, auth and rate limiting at the runtime layer, and the observability to know what an agent actually did on whose behalf. That's the work that pulls your team off the AI roadmap and never compounds.
Pontil automates generation and maintenance and aligns it to your SDLC, so the tools stay current without becoming your team's second job. Where your API genuinely can't express something, that's a real limit — we'll tell you rather than paper over it.
Pontil runs inside the infrastructure you already operate. Your code and data stay within your trust boundary, calls execute as the authenticated user, and audit trails are written where your security team already reads them. It's also protocol-agnostic — you're not tying your agents to one protocol that might be replaced next year.

Want to learn more about our security and the trust boundary?
Demos use the handful of actions your API already exposes. Production needs the full surface — including what only the UI could do — plus auth, rate limiting, and tools that don't break when the product ships a change. That coverage-and-maintenance gap is where projects stall, and it's what Pontil closes.
MCP is a protocol for exposing tools to agents. Pontil is protocol-agnostic and focuses on the harder problem: generating the tools from your codebase in the first place, and keeping them current. The protocol you expose them through is a choice, not the point.
No. Pontil generates action definitions from your codebase and composes them into tools, with your team reviewing and approving what gets exposed. The default is generation with human oversight, not hand-authoring from scratch.
Generation and maintenance are automated and can align to your SDLC. When the product changes, the affected tools are regenerated rather than drifting behind — and because they're generated from your codebase, breaking changes surface in your pipeline.
No. Every call executes as the authenticated user. The SDK scopes calls to that identity at the call site, so an agent can't act outside the permissions the user already has.