Skip to main content
Glama

setup_set

Set a single non-secret config key for your iOS subscription app setup. Secrets are rejected (use setup_credentials for those) and an empty value clears the key.

Instructions

Set ONE non-secret config key (e.g. asc_key_id, team_id, support_email). Secrets are refused: use setup_credentials so they never pass through the chat. An empty value clears the key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
valueYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.4/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the burden and does so reasonably: it discloses the secrets-refusal policy and the clear-on-empty-value behavior, both non-obvious traits. It does not state whether an existing key is overwritten, where the value persists, or whether auth is needed.

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

Conciseness5/5

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

Three short sentences, zero filler, with the core constraint ('ONE non-secret config key') and the critical exclusion (secrets) front-loaded. Every sentence earns its place.

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?

An output schema exists, so return values need no explanation, and the description covers the constraining behaviors an agent needs before calling. The main residual gap is the relationship to the sibling config_set and confirmation of overwrite behavior.

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 0% and neither parameter is documented in the schema, so the description must compensate. It does: it gives example key values and defines the special semantics of 'value' (empty string clears the key) and 'key' (one at a time, non-secret only). It could be firmer about overwrite semantics for non-empty values.

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?

States a specific verb and resource ('Set ONE non-secret config key') with scope ('ONE'), and enumerates concrete key examples (asc_key_id, team_id, support_email). An agent immediately knows this mutates a single config entry rather than being a generic setup tool.

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?

Explicitly tells the agent what NOT to use this for (secrets → setup_credentials, 'so they never pass through the chat') and what an empty value does. However it gives no guidance relative to the sibling 'config_set', which appears to serve a very similar purpose, leaving routing between the two ambiguous.

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