When the user is an AI agent: designing veterinary software for MCP

For most of veterinary software's history, integration meant a developer reading an API reference and writing code against specific endpoints. That is changing fast. The next thing to call your API may be an AI agent acting for a veterinarian, and agents behave differently from developers in ways that matter for how you build.

This post looks at what the evidence says about that shift, and what a veterinary system needs to be safe for agents to use.

APIs are for developers, MCP is for agents

The Model Context Protocol (MCP) is an emerging standard that lets an AI system discover what a piece of software can do, authenticate with it, and use its data and actions directly. The Companion Animal Veterinary Software Guide (CAVSG) Part VI puts the distinction clearly: "OpenAPI is your interface for human developers. MCP is your interface for AI agents. You need both."

The practical difference is who does the work. With an open API, a practice hires a developer or buys an application to connect, say, its scheduling software to its practice records. With MCP, the report's example is a practice owner asking an AI assistant for "a dashboard that shows me all patients overdue for heartworm testing, sorted by last visit date, with one-click texting to the client," and the agent building it against the practice's data directly.

| | Traditional API | MCP server |
|---|---|---|
| Who integrates | A developer writing code | An AI agent at runtime |
| How capabilities are found | Documentation, read by a person | Described by the server, discovered by the agent |
| When the integration is built | Before release | At the moment the user asks |
| Main risk | Bugs in the integration code | An agent doing something the user did not intend |
| What has to be strong | Endpoint design and documentation | Permissions, consent, approvals and audit |

Veterinary vendors are moving. In the CAVSG Part IX Companion, published in May 2026, more than one practice software vendor lists an open MCP server on its roadmap alongside a developer portal.

The agents are coming whether or not you build for them

Part of the pressure comes from agents that do not need an API at all. Dr. Ivan Zak, an emergency veterinarian with more than two decades of experience building veterinary software and PIMS integrations, wrote in his April 2026 response to the CAVSG innovator survey:

"With recent releases from Claude, including a Chrome extension capable of reading the entire UI through rapid screenshots, and the new Codex release that enables control of the full computer and screen environment, traditional integrations are becoming increasingly unnecessary. This applies both to cloud software products and to on-premise solutions."

He went on: "Ultimately, the most interconnected PIMS will win in this market."

The CAVSG authors draw the obvious conclusion. Systems that are open to agents become the platform other tools connect to, and in Part VII's phrase, the one that is closed "gets routed around."

Being routed around is worse than it sounds for a clinical system. An agent reading screenshots of your interface is working without your permission model, without your audit log, and without any way for you to tell it which fields it must never change. If agents will reach practice data either way, it is far safer for them to do it through a door you designed.

Trust is the actual product

CAVSG Part IV makes the argument that should shape every design decision here:

"The real moat is not CRUD screens, but trust: identity and permissions, consent, audit trails, data integrity, and an 'agent-safe' execution boundary: least-privilege access, approvals, rollback, and visibility into what changed."

That list is close to a specification. Here is what each item means when the caller is an agent working in a veterinary practice.

Identity for the agent as well as the user. Record which agent acted, on whose behalf, and under what grant. "Dr. Smith" and "an assistant acting for Dr. Smith" are different entries in a clinical record.

Least-privilege scopes. An agent building a heartworm reminder list needs to read patients, visit dates and test history, and perhaps send messages. It does not need to edit prescriptions. Make scopes narrow enough that an overbroad grant is a deliberate choice.

Approvals on consequential actions. Sending a message to a client, changing a medication, or writing to the medical record should pause for a person to confirm, at least by default. Reads within scope usually do not need to.

Rollback and a complete audit trail. Every write an agent makes should be traceable to a request and reversible. Agents will misunderstand instructions. A system that can show exactly what changed and undo it turns a clinical incident into a correction.

Visibility for the practice. The practice should be able to see which agents have access and what they did yesterday. IDEXX made the governance point directly in its CAVSG response, asking whether practices know what third-party agents are accessing. It is a fair question, and a good system answers it on a single screen.

A note on clinical responsibility

Agents change who performs an action. They do not change who is responsible for it. In veterinary medicine the licensed veterinarian holds clinical responsibility, and systems built for agents should make that easier to exercise rather than harder. In practice that means approvals for anything clinical, clear labeling of agent-generated content in the record, and never letting an agent's output reach a client or a patient's treatment without a person in the loop.

This is the same principle the American College of Veterinary Radiology and the European College of Veterinary Diagnostic Imaging set out for AI in 2025: AI should always be used with a qualified veterinary professional in the loop.

What to build this year

If you maintain veterinary software, the evidence points to a short list. Publish a documented API if you do not have one. Add an MCP server that exposes the same capabilities with scopes, approvals and logging built in rather than added later. Treat the audit log as a product feature that practices can read. And assume that if you do not give agents a safe door, they will find an unsafe one.

We are designing viggoVet's developer platform around this model, because a platform that works alongside every other system in a practice has to be a trustworthy place for both developers and agents to connect.