Your internal API is already an agent tool.
Nobody needs to build an MCP server for it. Point Govna at the OpenAPI description your API already publishes, review the operations you want reachable, and they arrive as governed tools — behind the same approval screen, the same rules and the same receipts as everything else.
A description on Monday, a governed tool on Tuesday
No integration to write, and nothing for the API team to change.
Point at the description
Any OpenAPI 3.0 to 3.2 document your service already publishes. Govna reads it and normalises every operation.
Review what becomes a tool
Choose the operations you want reachable, and see the exact request shape each one accepts. Operations Govna cannot safely support are kept visible, with the reason.
Publish a version
The published set is frozen. Calls are bound to that exact version and that exact operation — never to whatever the document says today.
One address for your MCP servers and your APIs
An agent does not know or care which is which. Both arrive as tools on the same connection, under the same approval, with the same rules running and the same receipt at the end. Your team learns one model, not two.
https://agw.govna.io/mcp Whatever your API already uses
Credentials live in the vault, never in the database, and a rotation never changes what an approved session was allowed to reach.
The description changed. The published version did not — until someone reviews it.
A new document is a proposal, not a deployment
When your API team edits the description, the running set does not move. Changed and removed operations stop immediately; unchanged ones keep working; the new version waits for a person.
Where to go next
Two readers, two different next steps.