Skip to main content
Glama

vars

Store variables server-side to persist across calls, so commands, paths, URLs, and headers can reference them by name without re-sending data.

Instructions

Server-side variables that persist between calls, so a value never has to be re-sent through the conversation. Store once, then reference it as ${vars.} in later calls — in a command, cwd, env, a path, a URL, a header, a git message, a bulk step. list shows names, types and sizes but NOT full values (that is the saving). Mark a token secret:true and it stays usable via ${vars.…} while never being echoed back. shell_bulk assign, shell_exec assign and http_request assign all write here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jsonNoload: parse the file as JSON instead of storing it as text.
nameNoVariable name. Letters, digits, _ . - starting with a letter or _.
pathNoload: file to read into the variable. save: file to write the variable to.
textNoappend: the text (or array element) to add.
deltaNoincr: how much to add. Default 1.
namesNoget/delete: act on several names at once.
valueNoset: the value — any JSON type. A string is itself ${...}-expanded, so you can compose from other variables.
actionYesset | get | list | delete | clear | append (to a string/array) | incr (numeric) | load (read a file into a variable) | save (write a variable to a file).
revealNoget: return a secret value in plain text. Only when you actually need to read it.
secretNoset/load: never echo this value back in get or list. It still works in ${vars.…}.
ttl_msNoset: forget the variable after this long.
confirmNoclear: required, since it drops every variable.
max_bytesNoget: byte cap on the returned value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it does well: it discloses that list shows names/types/sizes but not full values, that secret:true values remain usable via ${vars.…} while never being echoed, and that clear drops every variable. It omits permission/auth requirements and error behavior, keeping it short of a 5.

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?

Three sentences, front-loaded with the core concept and followed by reference syntax and behavioral notes. The middle list of contexts is long but each item is informative; little is wasted, though it could be tightened.

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

Completeness4/5

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

For a 9-action, 13-parameter tool with no output schema, the description covers the crucial cross-cutting behaviors (persistence, reference syntax, secret handling, list redaction) that an agent cannot infer from the schema. The per-action semantics rest on the 100%-covered schema, so the combination is nearly complete; only auth/permission context is 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 coverage is 100% so the baseline is 3, but the description adds genuine semantics beyond the schema: the ${vars.<name>} expansion syntax, that a set value string is itself ${...}-expanded for composition, and the secret/reveal trade-off. These enrich interpretation rather than merely restating parameter names.

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 description clearly identifies the resource (server-side variables that persist between calls) and its core value proposition (store once, reference via ${vars.<name>}). It conveys the multi-action nature by naming list, secret marking, and the writing tools, though it never frames itself explicitly as an action-dispatched store, so an agent must open the schema to grasp the full action set.

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 gives a clear when-to-use rationale ('so a value never has to be re-sent through the conversation') and enumerates the contexts where references work (command, cwd, env, path, URL, header, git message, bulk step). It also clarifies that secret values are excluded from list output, but gives no explicit when-not-to-use or disambiguation against sibling read/write tools.

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