Connecting the Vault Documentation MCP proves that your client can reach the server. It does not guarantee that the client will choose the right search tool — or retrieve from the right documentation source.
The server exposes five tools, each tied to a different documentation surface: developer guides, API reference material, SDK Javadocs, VAPIL Javadocs, or Platform Help. A valid question can still produce a poor result when it is routed to the wrong one.
This guide explains what each tool searches, when to use it, and where the documentation boundary stops.
Five tools. Five scopes. One hard boundary: Vault Platform documentation only.
Choose the right tool
| Tool | Use it for | Think of it as |
|---|---|---|
search_developer_docs |
Concepts, guides, MDL, VQL, Direct Data API | “How does this feature work?” |
search_api_reference |
HTTP methods, URIs, parameters, headers, response schemas | “What is the exact API contract?” |
search_sdk_javadocs |
Vault Java SDK classes, methods, return types, exceptions | “How does this server-side SDK method behave?” |
search_vapil_javadocs |
Java wrappers and models for Vault REST API operations | “How do I call this API through VAPIL?” |
search_vault_help_docs |
Platform configuration, feature behavior, and usage | “What does this platform setting do?” |
These categories align with Veeva’s official definitions of the five tools.
A single search box would return noise. Five scoped tools return precision. The developer who needs an API URI does not want SDK Javadocs in the results.
I tested each tool with queries I already knew the answers to. The sections below cover only what the table above does not.
search_developer_docs
Searches the Vault Developer Portal for platform development features. Covers the Vault Java SDK, Vault API, Metadata Definition Language (MDL), Vault Query Language (VQL), and Direct Data API.
Use this when you need conceptual information about how platform features work.
Test query example: I ran VQL query object filter syntax. search_developer_docs returned the WHERE clause specification, supported operators, and example filter expressions.
Important limitation: It returns documentation, not live query results. If you want to actually execute a VQL query against your tenant, use the Vault API directly.
search_api_reference
Searches the Vault API Reference for specific technical details: endpoint request details (URI paths, headers, parameters), endpoint response details (returned attributes, response structure), and response status information including error types.
Use this when you need the exact shape of an API call. Not the concept behind it. The actual URI, the required headers, the response fields.
Test query example: I ran update single user api uri path parameters. search_api_reference returned PUT /api/{version}/objects/users/{id}, the required path parameter id, and the request/response field details.
Important limitation: It returns the API specification, not a live API call. To execute the endpoint against your Vault, use the Vault API directly with appropriate authentication.
search_sdk_javadocs
Searches the Vault Java SDK Javadocs. Returns package overviews, field and constructor information, method details (parameters, return types, exceptions), class and interface descriptions, and code examples.
Use this when you are writing Java code against the Vault Java SDK — the server-side SDK used inside Vault custom code — and need to know what a method accepts, what it returns, or what exceptions it throws.
Test query example: I ran Vault Java SDK authentication OAuth2. search_sdk_javadocs returned the OAuth2 authentication class, method signatures, and token handling examples.
Important limitation: The Vault Java SDK runs inside Vault. If you are building an external Java integration against the Vault REST API, the tool you probably want is search_vapil_javadocs.
search_vapil_javadocs
VAPIL is Veeva’s open-source Java library for the Vault REST API. Use this tool when you need the Java class, method, request, or response model corresponding to a Vault API operation.
Use this when you need the Java wrapper or model for a Vault REST API call from an external Java application or integration.
Test query example: I ran VAPIL document download response model. search_vapil_javadocs returned the document response class, the fields available on it, and the method used to invoke the download operation.
Important limitation: Unlike the other four tools, VAPIL only supports general release documentation. Limited release VAPIL docs are not available through the MCP. The release parameter is not accepted here.
search_vault_help_docs
Searches the Platform Vault Help Docs. Returns configuration information, usage instructions, feature overviews, and configuration options.
Use this for platform-level configuration questions. Object lifecycle configuration, workflow setup, platform feature behavior. Not application-specific configuration.
Test query example: I ran object lifecycle state entry actions configuration. search_vault_help_docs returned the entry actions configuration syntax, available action types, and the platform behavior when an object enters a specific state.
Important limitation: Platform configuration only. If you need to view or change configuration inside your tenant, use Vault Admin or the Vault API directly.
Shared parameters
Four of the five tools accept the same parameters:
query(required): the search stringrelease(optional, defaults to"general"):"general"for current production docs,"limited"for the upcoming Vault versionlimit(optional): cap on returned results
search_vapil_javadocs accepts only query and limit — no release parameter.
The hard boundary: documentation, not your Vault
It can search: Published Vault Platform developer documentation — Developer Portal, API Reference, SDK Javadocs, VAPIL Javadocs, and Platform Help.
It cannot access: Your tenant, records, documents, custom configuration, audit trails, permissions, workflows, or application-specific documentation. It also cannot create, update, execute, or trigger anything inside Vault.
Veeva itself describes the Documentation MCP as a reference source that cannot perform Vault actions and returns Platform documentation only.
Application-specific developer sites may display the Vault Documentation MCP setup page within their own navigation, but the MCP server itself still returns Vault Platform documentation only.
The Docs MCP vs the Vault MCP Server
Part 2 mentioned there is another Vault MCP server. Here is the distinction:| Vault Docs MCP | Vault MCP Server | |
|---|---|---|
| Endpoint | https://docs.veevavault.dev/mcp |
Tenant-specific |
| Authentication | None | Vault credentials |
| What it does | Searches published documentation | Invokes permitted Vault AI agent actions |
| Risk profile | Documentation retrieval only | Can operate on documents and object records |
Because the Documentation MCP retrieves published documentation and cannot act inside a Vault, it presents a substantially different — and generally lower — risk profile than the authenticated Vault MCP Server. Organizations should still assess its use under their own AI governance, SDLC, and validation procedures.
The authenticated Vault MCP Server dynamically exposes permitted Vault AI agent actions as MCP tools. Those actions can operate on documents and object records when the action is active, API Access is enabled, and the authenticated user has permission.
The Docs MCP answers “What does Veeva say?” The Vault MCP Server answers “What am I permitted to do here?”.
Queries that work vs queries that leave too much room for routing
Veeva recommends treating MCP queries like precise search terms rather than conversational questions. Include specific technical identifiers. Use contextual keywords like Create, Update, Query, Execute. Drop filler phrases. The tools support natural language, but they perform best with specific identifiers.
Query formula: Technology or source + target noun + operation + requested detail.
Examples that work:
Vault API Update Single User URI path parametersVQL object query WHERE filter syntaxVault Java SDK RecordService method exceptionsVAPIL document download response model
Queries that leave too much room for routing:
"How do I update a user's API endpoint?"— too conversational, missing technical identifiers"Tell me about Vault"— too broad, no specific source or feature"How does Clinical Trial Management work?"— out of scope (application-specific)"What are the best practices for Vault integrations?"— opinion-based, not in documentation
The pattern is clear. Specific technical terms return results. Vague questions return noise.
Test results
I ran each of the five working queries through the MCP. Here is what came back:
| Query | Tool Called | What It Returns |
|---|---|---|
update single user api uri path parameters |
search_api_reference |
PUT /api/{version}/objects/users/{id}, required path parameter id, request/response field details |
VQL query object filter syntax |
search_developer_docs |
VQL WHERE clause syntax, supported operators, example filter expressions |
Vault Java SDK authentication OAuth2 |
search_sdk_javadocs |
OAuth2 authentication class, method signatures, token handling examples |
VAPIL document download response model |
search_vapil_javadocs |
Document response class, available fields, download method signature |
object lifecycle state entry actions configuration |
search_vault_help_docs |
Entry actions configuration syntax, available action types, state transition behavior |
What comes next
Five tools. Five scopes. One hard boundary: Vault platform documentation only.
But the Docs MCP is only one piece of a confusing landscape. Type "Vault MCP" into a search engine and you will get four entirely different products, one of which has nothing to do with Veeva at all.
In Part 4, I will sort through the confusion: what each Vault MCP product actually is, how they differ, and which one you need.