Skip to main content
Glama

set_config

Writes a validated, audited daemon configuration section for admin-scoped changes, merging keys and rejecting unknown or protected values. Use dry_run to preview the plan before applying.

Instructions

Write a daemon config section (admin-scoped, validated, audited).

Input Schema

NameRequiredDescriptionDefault
valuesYesKeys to merge into that section: an omitted key keeps its stored value, a null value deletes a NULLABLE key (reverting it to its default; a null on a non-nullable key is a 422 ``config.invalid``), and a nested table is merged one level deep. An unknown key is refused (422 ``config.invalid``) rather than silently dropped; ``auth_token`` is refused (403).
dry_runNotrue = validate and return the plan (what would change) with zero writes; nothing is built, deployed or audited as a change.
sectionYesConfig section to write, one per call (e.g. ``proxy``, ``services``, ``retention``). An unknown name is a 404 ``config.unknown_section``.
if_matchNoETag from a previous read of this section, sent as ``If-Match``: the write is refused with 409 ``config.stale`` if the config changed since. Omit to write unconditionally (no ETag is fetched for you); ``*`` always matches.
idempotency_keyNoCaller-chosen key: a retry with the same key replays the first result instead of acting twice. Omit and a fresh key is minted per call, so each call acts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries real weight, and it does disclose three useful traits not in the schema: admin scoping, validation, and that the change is audited. It omits reversibility, the effect on the running daemon (reload vs restart), and any rate or concurrency behavior, so it is helpful but incomplete.

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?

A single front-loaded sentence with no filler and the key qualifiers packed into the parenthetical. It is arguably too terse rather than padded, but every word earns its place.

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

Completeness3/5

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

The rich schema covers parameters, error codes, and safety mechanisms, and no output schema exists to explain. What is missing is context an agent would want for a destructive write: whether it takes effect immediately, what to do on config.stale, and how it relates to apply_config.

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% and the property descriptions already explain merge semantics, dry_run, if_match, and idempotency in detail. The tool description adds nothing beyond that, which is the baseline case for a fully documented schema.

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?

States a specific verb ('Write') and resource ('daemon config section'), and the parenthetical scoping qualifiers make it clear this mutates a section of the daemon configuration. It does not explicitly differentiate itself from close siblings like apply_config or set_app_config, so an agent must infer that this is the per-section write primitive.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all: nothing tells the agent to prefer this over apply_config, set_app_config, set_variable, or set_secret, nor when to use dry_run first. Only the 'admin-scoped' hint implies a permission prerequisite.

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