You ran the setup command from Part 1. The /mcp output shows the Vault Docs MCP as connected.
That proves one thing: your client can reach the server.
It does not prove that the client will choose the right tool, retrieve the right documentation, or turn the result into a correct answer.
The /mcp command confirms the pipe exists. It does not confirm the water is flowing. That requires a test query — something you already know the answer to, asked through the MCP. If the response matches what you would find in the Developer Portal, the connection is working.
I tested the same Vault questions across Claude Code, Gemini CLI, and Gemini Code Assist. The same five search tools sit behind all three clients. What changes is how each client decides when to call them, which tool it selects, and how it presents the result.
That difference matters more than the setup command.
What Connection Actually Means
The Vault Docs MCP at https://docs.veevavault.dev/mcp is a read-only path to Veeva’s published Vault Platform documentation.
That is the entire surface area.
It does not connect to your Vault tenant. It cannot see customer data, custom objects, configuration, documents, records, permissions, or workflows. It does not execute actions in Vault.
The setup commands from Part 1 take under two minutes per client. No authentication. No Vault credentials. No API keys. The MCP server is hosted by Veeva and serves published documentation to clients that can reach the endpoint.
The /mcp command confirms the path exists. A connected status tells you the client can reach the server.
The next question is whether it uses it correctly.
Test Before You Trust It
Start with a question whose answer you can independently verify.
Veeva’s own query-formatting guide uses this example: update single user api uri path parameters
The expected result includes: PUT /api/{version}/objects/users/{id}
The important part is that you already know where to verify it.
A meaningful MCP test has four checks:
- Did the client called the Vault Docs MCP?
- Did it selected the appropriate search tool?
- Did the returned documentation match the source?
- Did the client preserve that information accurately in its final answer?
Structured output is not the same thing as a correct answer. A model can return a clean, structured, confident answer and still call the wrong tool, retrieve the wrong documentation, or distort the result after retrieval.
That distinction becomes expecially important when comparing clients.
Three Clients, Three Behaviors
The same five tools sit behind all three clients. In my testing, the difference is how each client routes your questions to those tools — and what it does with the response.
Claude Code: Automatic Routing, Concise in My Tests
In my testing, Claude routed Vault-related questions to the appropriate MCP tool without explicit instruction. Ask about an API endpoint and it calls the API reference tool. Ask about a Java SDK method and it calls the SDK Javadocs tool. You do not need to specify which tool — Claude automatically selects based on context.
That worked well for targeted technical questions. Ambiguous questions were less predictable.
"How does Vault handle authentication?" could reasonably lead to developer documentation, API reference material, or Vault Help. The tool selected determines the scope of the answer.
Specific prompts produced better results: "Vault Java SDK OAuth2 authentication" worked better than "Vault auth".
Test query example: "Vault API Update Single User endpoint URI path parameters." Claude calls search_api_reference, returns the endpoint URI PUT /api/{version}/objects/users/{id}, required path parameters id, and key request/response fields. Compare the results against the Developer Portal — they should match.
Verification: Type /mcp in the chat. The Vault Docs MCP should appear in the server list with a connected status. Then run a test query: "Vault API Update Single User endpoint URI path parameters." If the response includes structured endpoint documentation, the routing is working.
Gemini CLI: Same Tools, More Explanation
Gemini CLI also selected MCP tools automatically based on the question.
With the same prompts in my tests, the main difference was what happened after retrieval. Gemini tended to add more explanation around the documentation it returned.
That is not necessarily a problem. Sometimes the extra context is useful. It is less useful when you want a specification rather than an explanation.
Compare: Tell me about the Update Single User endpoint
with: Show only the URI path, method, required path parameters, headers, and response fields for Update Single User.
The first invites interpretation. The second asks for a reference answer.
Test query example: Use the same known query as Claude Code above. Then compare not only the retrieved endpoint information, but how much the client adds around it.
Verification: Confirm the server with /mcp, confirm that an MCP tool was actually called, and compare the result with the source documentation. If the answer buries the specification in explanation, ask explicitly for concise reference output.
Gemini Code Assist (IntelliJ): MCP Results Meet IDE Context
Gemini Code Assist requires a few clicks instead of a terminal command.
- Open Settings (or Preferences on macOS)
- Navigate to Tools > Gemini > MCP Servers
- Add a new server with
"httpUrl": "https://docs.veevavault.dev/mcp" - Wait for the connection confirmation
- Open Gemini Code Assist chat in Agent Mode and type
/mcpto verify the server
The httpUrl field handles the StreamableHTTP transport automatically.
Where this client differs: Where this became more interesting in my testing was the combination of MCP retrieval with project and IDE context.
When the question was tied to a Vault Java SDK class or method already in the working context, Gemini could combine that context with documentation retrieved through the MCP. The result was a more natural workflow for class- and method-level questions than starting with a standalone search query.
Test query: Open code that uses a Vault SDK class and ask a specific question about the class or method while it is in context.
Verification: /mcp in Agent Mode to confirm the server is connected. Then place your cursor on a Vault SDK class, open the Gemini chat, and ask about the class. The response should include method signatures and Javadoc content specific to that class.
The important check is still the same: confirm that the client actually used the MCP and that the documentation it returned matches the source.
IDE context can improve the question. It does not eliminate the need to verify the answer.
Common Failure Modes
Most failures fall into four categories. The first two prevent the MCP from working at all. The last two are easier to miss because everything can appear to be working.
The Client Cannot Reach the Server
Corporate proxies and firewall egress rules create the same practical problem: the client cannot reach docs.veevavault.dev over HTTPS. If outbound traffic is restricted to approved domains, the endpoint must be allowed through the relevant proxy or firewall.
No prompt or client-side MCP setting can fix a blocked network path.
The Client Does Not Support the Connection
Older client versions may not support the remote HTTP transport required by the server.
If the configuration is correct but the client reports a transport or connection error, check the client version before troubleshooting the MCP itself.
Connected, but the MCP Was Never Used
This is the /mcp trap.
A connected status confirms that the client can reach the server. It does not prove that the client used one of the five Vault documentation tools when answering your question.
The client may answer from model knowledge instead. For any meaningful test, inspect the tool activity and confirm that the Vault Docs MCP was actually invoked.
Connected, but the Wrong Answer Came Back
This is the most important failure mode because it can look like success.
An ambiguous prompt may lead the client to the wrong documentation surface. The correct tool may retrieve an incomplete match. The client may also retrieve the right information and then summarize it incorrectly.
That is why the best first test is a known query. Do not ask only whether the server connected.
Ask whether the right tool was called, whether the source matched the question, and whether the final answer preserved what the source actually said.
Where the Documentation Boundary Stops
The Vault Documentation MCP Server knows the documentation. It does not know your Vault
It cannot see your documents, records, custom objects, fields, picklists, workflows, permissions, configuration, or audit trails. It cannot tell you why a field is missing for a specific user, what changed in your production Vault yesterday, or which documents are waiting for approval.
It also does not search application-specific documentation for products such as Clinical, Safety, RIM, Quality, Medical, Commercial, SiteVault, or CRM.
And it cannot take action.
It does not create records, update documents, start workflows, change metadata, or execute anything in a tenant. That boundary is what makes the Vault Docs MCP simple and secure: public documentation in, reference context out.
The mistake is expecting documentation access to become tenant awareness because both appear inside the same AI client.
For tenant-specific context or execution, you cross a different trust boundary. And Veeva now has a different MCP server for that.
Beyond Documentation: The Other Vault MCP Server
The naming is easy to confuse because there are now two different Veeva MCP servers serving fundamentally different purposes.
The Vault Docs MCP Server is public and read-only. It gives an AI client access to published Vault Platform documentation.
The Vault MCP Server is authenticated and tenant-specific. It allows external AI clients to invoke eligible Vault AI agent actions that have API Access enabled.
That distinction matters.
The Vault MCP Server is not a generic pipe that gives an AI client unrestricted access to everything in a Vault. The client sees actions that have been intentionally exposed, and those actions run within the access of the authenticated Vault user.
Available now in 26R1.4 Limited Release and planned for General Release in 26R2, the Vault MCP Server changes the architecture significantly.
A client can now use one Veeva MCP server to search public documentation and another to invoke governed actions inside an authenticated Vault environment.
Those are different capabilities with different risk profiles:
- Documentation MCP: What does Veeva say?
- Vault MCP: What am I permitted to do here?
The question is no longer only whether the AI can answer, it is what the AI is allowed to see, what it is allowed to do, and how those boundaries are controlled.
What Customers Are Building
The distinction between documentation, tenant context, and execution is not theoretical.
Life sciences companies are already building at each layer. Some are using Veeva-native agents inside regulated workflows. Others are building the data and software foundations that AI depends on. Others are redesigning entire processes around AI-assisted work.
The architectures differ, but the direction is consistent.
- Moderna: AI inside MLR review. Moderna became the first company to go live with Vault AI in PromoMats. Quick Check Agent reviews content against editorial, brand, market, channel, and compliance guidelines before formal review, while Content Agent helps users analyze and work with document text and images. Moderna’s published experience is one of the clearest examples of agentic AI moving from pilot to a regulated business process. Read Moderna’s seven-step implementation guide.
- Boehringer Ingelheim: AI in a regulated production process. Boehringer Ingelheim spent four months piloting Vault AI capabilities including Quick Check Agent and Content Agent. Its published lessons focus less on the model and more on what implementation actually requires: machine-readable content, change management, rapid feedback loops, and measurement of accuracy, utilization, and cycle time. Read the implementation lessons.
- Bayer: From system of record to system of insights. Bayer is connecting Vault CRM, Veeva Data Cloud, and globally harmonized reference data to support AI-driven commercial insights. The useful lesson is not that AI replaces the underlying system. The quality and consistency of the data underneath it determine what the AI can do. Hear Bayer discuss its approach.
- GSK: Building an AI-ready enterprise. GSK describes its early move to Vault CRM as part of creating an AI-ready foundation. Its approach focuses on identifying high-value processes, embedding a data-centric mindset, and training people for the specific ways AI changes their work. Hear GSK discuss the AI-ready enterprise.
- Teva: Commercial AI and data science. Teva’s Global Head of Digital Commercial discusses how the company is applying AI and data science to commercial innovation and why the surrounding data and technology ecosystem matters. Watch Teva’s AI use cases.
- AstraZeneca and Incyte: AI in regulatory processes. In a 42-minute session with Veeva, leaders from AstraZeneca and Incyte discuss AI readiness, common implementation failures, deployment strategy, scalability, and how to move toward measurable business outcomes in regulatory operations. Watch the regulatory AI session.
Some use Veeva-native agents inside an existing application. Some are building the data and software foundation that AI depends on. Others are redesigning a regulated process around AI-assisted work.
The common pattern is simpler: AI becomes useful when it can reach trusted context and participate in a defined business process.
The Vault Docs MCP handles one part of that equation: giving an AI client trusted Veeva documentation as context.
Broader AI transformation adds even more layers: enterprise data, specialized models, workflow redesign, validation, governance, and organizational change.
The companies furthest along are connecting every layer into a coordinated AI ecosystem.
What Comes Next
A successful MCP connection is just the beginning.
The server can be reachable while the client never uses it. The client can call a tool and still choose the wrong one. The right documentation can be retrieved and still become the wrong answer.
Verification matters. So do boundaries.
The Vault Docs MCP Server gives an AI client trusted reference context without access to a customer environment. The Vault MCP Server crosses into authenticated, tenant-specific actions through a different and more controlled trust model.
Understanding that difference is the foundation for everything that comes next.
In Part 3, I will go inside the five tools behind the Vault Docs MCP: what each one searches, where their coverage overlaps, and how to write queries that consistently reach the right documentation.