Using the MCP Server

To get the best results from the Vault Documentation MCP Server, treat your queries like highly specific search engine terms. While the search_documentation and search_release_notes tools support natural language, they perform best when you include specific technical identifiers in your query.

Formatting Queries

The following best practices apply to both search_documentation and search_release_notes queries:

Be Surgical: Include the specific noun of what you are looking for. For example, "document", "picklist", or "RecordService".
Use Contextual Keywords: Add verbs such as "create", "update", "query", or "execute" to narrow down the documentation section.

Handling Parameters

You don't set tool parameters directly. Your LLM client reads your query and determines the appropriate parameter values to send to the MCP server.

search_documentation

The search_documentation tool accepts three parameters: source, app_family, and release.

For example, to search the limited release API documentation, phrase your query naturally:

Search the limited release API docs for the Generate API access token endpoint details.

Your LLM client sends release="limited" to the MCP server based on the context of your query. The same applies to source and app_family.

Query Example

> update single user api uri path parameters

Response

✦ The Update Single User API endpoint uses the following URI path parameter:

  URI Path Parameter

│ Parameter │ Description |
───────────┼───────────────────────────┤
│ {id} │ The system-assigned unique numeric ID of the user. You can also use the keyword me to update the profile of the currently authenticated user. │

  Endpoint Details
   * Method: PUT
   * URI Path: /api/{version}/objects/users/{id}
   * Content-Type: application/x-www-form-urlencoded

  Example Request

   1 curl -X PUT -H "Authorization: {AUTH_VALUE}" \
   2 -H "Content-Type: application/x-www-form-urlencoded" \
   3 -d "user_timezone__v=America/New_York" \
   4 -d "user_title__v=Senior Engineer" \
   5 "https://{server}/api/v26.1/objects/users/25001"

  Pro-Tip
  Since Vault v18.1, users are managed as Object Records. For most updates, it is recommended to use the generic Update Object Record endpoint instead:
  PUT /api/{version}/vobjects/user__sys/{id}

search_release_notes

The search_release_notes tool accepts three parameters: source, start_release, and end_release.

For example, to search for developer changes in a specific release, phrase your query naturally:

What new Vault API features were added in the most recent Vault release?

Your LLM client sends source="vault_developer_release_notes" and the appropriate start_release value to the MCP server based on the context of your query. To search across a range of releases, include both a start and end version in your query.

Query Example

> What new Vault API features were added in 26R2?

Response

✦ The following Vault API changes were introduced in 26R2:

  Global API Header Changes (Service Announcement)
  Starting with the 26R1.2 release, Vault API returns a numeric-only status
  line and no longer returns the Expires header.

  Grouping ID in Audit Exports
  The grouping_id attribute is now available in the document audit details
  for the Retrieve Audit Details and Retrieve Complete Audit History for a
  Single Document endpoints.

  API/SDK Support for Object Reference Notation for Document Fields
  Object reference notation can now be used to set object reference field
  values on a document via Vault API or Vault Java SDK.