plunger

Official

Overview Schema Source Related Servers Discussions Admin

set_variable

Idempotent

Stores a named variable for later requests to reuse as {{name}}, such as a token from a login response; it persists across calls and runs; secrets are stored in the system credential store and masked.

Instructions

Set a variable that later requests use as {{name}}, for example a token you read from a login response. It persists between calls and runs and is shared with the Plunger window, the CLI and other agents. A secret (or a credential-looking name such as token or api_key) is kept in the system credential store and masked in results. A variable the user defined in the window cannot be changed.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	The name, used in requests as {{name}}. Letters, digits, _ - and . only, at most 64 characters.
`value`	Yes	The value. For a secret it is stored in the system credential store and never returned.
`secret`	No	Keep it as a secret: masked in results, and never written to a file. A name that looks like a credential (token, password, api_key, secret...) is always secret.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`value`	No	Only for non-secret variables.
`secret`	Yes	Secret values are masked in the window and never returned here.
`source`	Yes	`window` for a variable the user defined, `agent` for one set from the CLI or MCP.
`has_value`	Yes
`remembered`	Yes	Kept in the operating system's credential store between runs.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations' idempotentHint/destructiveHint, the description discloses scope of persistence (across calls and runs), cross-surface sharing (Plunger window, CLI, other agents), secret handling (system credential store, masked in results, never written to a file), and the immutable user-defined-variable case. That is exactly the operational context annotations cannot convey.

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?

Four sentences, front-loaded with the action and the {{name}} reference, then escalating to persistence, sharing and secret semantics. Dense but every sentence carries distinct information; slightly more detail than a minimally lean version.

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?

With an output schema present and 100% parameter coverage, the description need not explain return values and instead covers the behaviors that matter: persistence, sharing, masking, and the one failure mode. Nothing an agent needs before calling is missing.

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

Parameters3/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 explains name, value and the secret flag in detail. The description restates the secret/credential-name behavior for parameters but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

The first sentence gives a specific verb and resource ('Set a variable') plus the exact consumption syntax {{name}}, which immediately distinguishes it from list_variables and delete_variable. The example (a token read from a login response) anchors the purpose concretely.

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 supplies a motivating use case ('a token you read from a login response') and a genuine when-not constraint ('A variable the user defined in the window cannot be changed'), so an agent knows a case where the call will fail. It does not, however, point at siblings such as list_variables for checking existing definitions.

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

Deploy Server