Skip to main content
Glama
Sign In
wundervault

wundervault

Official
by wundervault
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

vault_call

Calls web services using vault-stored secrets without exposing credentials: the broker attaches the secret, sends the request, and returns the response with the secret removed.

Instructions

Call a web service with a vaulted secret that is never returned to you: the broker attaches the secret, sends the request and gives you the answer with the secret removed.

Two ways to call. Describe the request yourself with request (origin, method, path, and optional query, body and your own headers). Or run a named operation the owner defined, with operation_id and typed args: the operation fixes the origin and route, returns only the fields it permits, and is signed with a key derived from the secret itself, so a definition altered in transit is refused. vault_entries_list shows which operations an entry offers.

Either way the entry decides how the secret is attached (a header, a query parameter, a username and password, or part of the web address) — you never choose that, and never see the secret.

Input Schema

NameRequiredDescriptionDefault
argsNoTyped arguments for operation_id, checked against its schema.
purposeYesWhy this is needed (audit log).
requestNoDescribe the call yourself: {origin:{scheme,host,port}, method, path, body?, query?, headers?}. body: an object or array is sent as JSON; a string is sent as written (set content-type in headers, e.g. application/x-www-form-urlencoded). headers: your own, such as user-agent or an API version; the header that carries the secret, and framing headers, are refused. If the entry keeps its secret in the web address (Telegram, webhooks), path is only what comes AFTER the secret, e.g. /sendMessage, or / for the stored address as is. Tier 1 secrets proceed and are logged. Tier 2 secrets are refused until the owner approves this exact origin, method and path; the approval covers whatever headers and body it carries. STAMPED keys (AWS, X, SnapTrade, exchanges) never travel: add request.stamp describing how the service signs requests, either {builtin:"aws-sigv4", region, service}, {builtin:"oauth1"} for OAuth 1.0a (X, Tumblr, Flickr; optional signature_method:"HMAC-SHA256" and realm for NetSuite; nonce, timestamp and the Authorization header are written for you; the owner stores the four values as {"api_key","api_secret","access_token","access_token_secret"}), or {mac:"hmac-sha256"|"hmac-sha384"|"hmac-sha512", key:"utf8"|"base64"|"hex", message:[parts], encoding:"hex"|"base64"|"base64url", place:[{in:"header"|"query", name, value:"…{stamp}…"}]}. Parts: {text}, {var: method|path|query|path_and_query|body|host|key_id|body_json}, {header: name}, {body_field: name}, {sha256:[parts]}, {sha512:[parts]}, {sha256_hex:[parts]}, {json:{name: part}} (sorted keys, no spaces). Parts read the request before the stamp is placed; put timestamps and nonces in the request yourself. place values may use {stamp} and {key_id}. The owner approves each recipe once per address; the first call waits for that.
entry_idYesVault entry holding the credential.
operation_idNoA signed operation on the entry. Use this OR request, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.0
    • changedInput schema / properties / request / description
      Previous value: -"Describe the call yourself: {origin:{scheme,host,port}, method, path, body?, query?, headers?}. body: an object or array is sent as JSON; a string is sent as written (set content-type in headers, e.g. application/x-www-form-urlencoded). headers: your own, such as user-agent or an API version; the header that carries the secret, and framing headers, are refused. If the entry keeps its secret in the web address (Telegram, webhooks), path is only what comes AFTER the secret, e.g. /sendMessage, or / for the stored address as is. Tier 1 secrets proceed and are logged. Tier 2 secrets are refused until the owner approves this exact origin, method and path; the approval covers whatever headers and body it carries. STAMPED keys (AWS, SnapTrade, exchanges) never travel: add request.stamp describing how the service signs requests, either {builtin:\"aws-sigv4\", region, service} or {mac:\"hmac-sha256\"|\"hmac-sha384\"|\"hmac-sha512\", key:\"utf8\"|\"base64\"|\"hex\", message:[parts], encoding:\"hex\"|\"base64\"|\"base64url\", place:[{in:\"header\"|\"query\", name, value:\"…{stamp}…\"}]}. Parts: {text}, {var: method|path|query|path_and_query|body|host|key_id|body_json}, {header: name}, {body_field: name}, {sha256:[parts]}, {sha512:[parts]}, {sha256_hex:[parts]}, {json:{name: part}} (sorted keys, no spaces). Parts read the request before the stamp is placed; put timestamps and nonces in the request yourself. place values may use {stamp} and {key_id}. The owner approves each recipe once per address; the first call waits for that."New value: +"Describe the call yourself: {origin:{scheme,host,port}, method, path, body?, query?, headers?}. body: an object or array is sent as JSON; a string is sent as written (set content-type in headers, e.g. application/x-www-form-urlencoded). headers: your own, such as user-agent or an API version; the header that carries the secret, and framing headers, are refused. If the entry keeps its secret in the web address (Telegram, webhooks), path is only what comes AFTER the secret, e.g. /sendMessage, or / for the stored address as is. Tier 1 secrets proceed and are logged. Tier 2 secrets are refused until the owner approves this exact origin, method and path; the approval covers whatever headers and body it carries. STAMPED keys (AWS, X, SnapTrade, exchanges) never travel: add request.stamp describing how the service signs requests, either {builtin:\"aws-sigv4\", region, service}, {builtin:\"oauth1\"} for OAuth 1.0a (X, Tumblr, Flickr; optional signature_method:\"HMAC-SHA256\" and realm for NetSuite; nonce, timestamp and the Authorization header are written for you; the owner stores the four values as {\"api_key\",\"api_secret\",\"access_token\",\"access_token_secret\"}), or {mac:\"hmac-sha256\"|\"hmac-sha384\"|\"hmac-sha512\", key:\"utf8\"|\"base64\"|\"hex\", message:[parts], encoding:\"hex\"|\"base64\"|\"base64url\", place:[{in:\"header\"|\"query\", name, value:\"…{stamp}…\"}]}. Parts: {text}, {var: method|path|query|path_and_query|body|host|key_id|body_json}, {header: name}, {body_field: name}, {sha256:[parts]}, {sha512:[parts]}, {sha256_hex:[parts]}, {json:{name: part}} (sorted keys, no spaces). Parts read the request before the stamp is placed; put timestamps and nonces in the request yourself. place values may use {stamp} and {key_id}. The owner approves each recipe once per address; the first call waits for that."
  2. Addedv2.0.2

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so thoroughly: it explains that secrets are never returned, the broker attaches and strips them, the entry controls attachment, and Tier 1/Tier 2 approval behavior is described. It also discloses signed operations and complex stamped-key signing behavior, including owner approval for recipes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then structured around the two calling modes. It is long and dense, but the length is largely justified by the tool's complexity and security-sensitive behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and output schema, the description provides enough context to invoke the tool correctly: it covers secret handling, two call modes, approval tiers, operation signing, and secret placement. Nothing critical for correct invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents parameters extensively. The description still adds meaningful semantics beyond the schema by explaining the request-vs-operation_id choice and that the entry, not the caller, decides how the secret is attached.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: call a web service using a vaulted secret that is never exposed. It clearly scopes the tool to brokered HTTP calls, but it does not explicitly differentiate from siblings like vault_sign, vault_pay, or vault_ssh_exec beyond naming vault_entries_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly explains the two invocation modes: a self-described request or a named operation with typed args. It also points to vault_entries_list for discovering operations, giving useful context, but it does not explicitly state when to use this tool instead of the specialized sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools