Your product can do it. Your agents can't reach it. Pontil Tools generates agent-ready tools from your existing codebase — surfaced at runtime, scoped to the authenticated user, with no backend rewrite.

Most agent projects don't stall because the model is wrong. They stall because the product the agent needs to act on isn't reachable.
Your internal APIs cover a fraction of what your product actually does. The rest lives in controller logic, UI workflows, and business rules that were never meant to be called by a machine. An agent can reason perfectly well about what it should do, then hit a wall when it tries to do it — because the path to that capability doesn't exist in a form it can call.
The gap is widening, not closing. Across more than 5,700 developers surveyed in Postman's 2025 State of the API report, 89% now use generative AI in their daily work — but only 24% design their APIs with AI agents in mind. The product surface and the agent demand are moving in opposite directions. Building the missing surface by hand is a two-to-five-year project most teams can't fund against the roadmap, so the agent work waits.

Pontil Tools turns the capability already built into your product into tools an agent can discover and call — at the permission level of whoever it's acting for. You decide what gets exposed; Pontil keeps it current as the product changes. It's the producer side of the agent-tools market: exposing your own product outward to agents, not pulling third-party data inward. That's the job most of the market doesn't do.
No manual docs, no new API surface to build first. The scanner reads what's already there — controllers, resolvers, routing — and generates structured, annotated action definitions from the APIs your product already exposes. Source stays in your environment.

Raw actions map to low-level calls; tools map to the tasks someone would actually ask an agent to do. Your team composes tools from the generated actions, with AI assistance and human review at every step. Destructive operations aren't exposed by default. You define what an agent can reach.

Deterministic invocation, retries, timeouts, rate limiting, and observability — handled at the runtime layer, not pushed onto your agents or your product. Every call executes as the authenticated user, with their permissions, their data visibility, and their audit trail. No shared service account.

Current definitions are fetched at call time, scoped to the user and tenant. When a tool changes, agents pick it up without a redeploy. The SDK sits alongside your existing framework rather than replacing it, and the runtime is callable over HTTP for anything the SDK doesn't yet bind.

Pontil Tools is built for teams shipping agents against their own product — not orchestration frameworks or browser-automation workarounds that reverse-engineer the UI. Because generation runs against systems you own, it plugs into your engineering practice: CI triggers regeneration, tests point at the generated tools, your SIEM reads the audit trail. Reverse-engineered approaches can't — no contract, no way to catch silent drift before production.
MCP awareness runs ahead of adoption: 70% of developers know the Model Context Protocol but only 10% use it regularly. The point holds whichever standard wins — agents are already calling your APIs, and that surface needs to be generated, governed, and maintained. Pontil Tools outputs MCP-compatible format alongside REST, so you're not betting on one protocol.
Connect forward, to AI agents
Connect outward, to customers and partners
Connect inward, to the external tools your users need
One engine — generation, runtime, and maintenance — pointed three ways. See how it works across all three, or read the security model for the trust-boundary and auth detail.
No. The scanner reads the codebase directly. If you have a spec it can use it; if you don't, it doesn't matter. Most products have partial or no formal spec for their internal surface — that's the common case, not the exception.
That's the core use case. Internal APIs, BFF layers, and controller logic that was never meant to be published are all in scope for the scanner. The output is a structured definition Pontil generates — not a republished version of your internal docs.
The scanner detects the change, updates the affected definitions, and flags them for human review before they reach the live tools. Your team approves what changes. Tools don't silently break.
No. The SDK works alongside LangChain, LlamaIndex, CrewAI, or a custom loop — it handles what the agent can do, not the reasoning. The runtime is callable over HTTP for anything the SDK doesn't yet bind.
No. Definitions are fetched from the runtime at call time, so agents pick up changes automatically without a code change on your side.
Tools, identities, and rate limits are scoped per tenant and per user. An agent acting for a user in tenant A only sees the tools and data that user is entitled to in tenant A. Isolation is enforced at the runtime, not left to the agent.