Skip to main content
Glama

Change a setting

set_setting
Idempotent

Change one workspace setting when asked. Reversible updates apply at once; irreversible changes need explicit approval first.

Instructions

Change one setting of this workspace when the person asks for it, and say so. Most are reversible and happen at once; the few that send the conversation or a secret somewhere else, let a program run, or open the workspace to others cannot be taken back, so calling this puts the question to the person for you and nothing changes until they say yes. The settings: name: what the workspace is called, on every page; server.addr: the address to serve on, from the next start; llm.provider: the kind of model: anthropic, openai-compatible, ollama, claude-code or command; llm.model: the model's name; llm.base_url: where an openai-compatible model answers; llm.max_tokens: the longest reply the model may give; llm.api_key_env: the NAME of the environment variable that holds the model's key; mcp.token_env: the NAME of the environment variable that holds the bearer token for /mcp; ui.controls: auto fades per-item controls until hovered; visible keeps them on screen (auto, visible); ui.pace: how changes arrive: calm, quick or still (calm, quick, still); ui.text: how large the words are: normal, large or larger (normal, large, larger); ui.spacing: room between lines, words and paragraphs: normal, or wide for people who read more easily with more room (normal, wide); ui.needs: what the person has said they need, in their words (I use a screen reader; keep things simple; I am colour blind): you follow it in every reply and every page you make. Set it the moment they tell you, and add to it, keeping what was there; ui.clock: how a time of day is said: 12 (2pm, 5:30pm) or 24 (14:00); empty follows the language, 12 for English (12, 24); ui.language: the workspace's language as a code (en, de, es, fr): the pages say it so screen readers use the right voice, and you reply in it; ui.lists: which lists the sidebar shows: filled (something in them, or made by the person) or all (filled, all); ui.developer: the design system and the guide for agents: hidden from the sidebar or shown (hidden, shown); ui.show: the parts of a page that are on every time. All of them are off by default, and a page shows no trace of an off one, so this is how something earns a permanent place: fields (a record's whole field list, including the ones its heading and chips already say), remind (the field for setting a reminder about a record, on its page), ask (the way to the assistant with the record in the box), day (the way to the record's day on the calendar), writing-help (the kinds of help with a piece of writing: spelling, tightening, feedback on structure), contents, place, outline and material (for longer writing), recording and write-up (for a meeting), or a connection key from get_record's related, such as points-here:task.project. +key adds one, -key takes it back, a list replaces them all, empty is none. Each is also one address away without this (?show=), so turn one on only when you have a reason the person wants it every time, and say the reason; chat.history_limit: how many past messages go to the model each turn; chat.system_prompt: words put before the built-in instructions to the model; update.mode: how a new version of sameway arrives: auto installs a release on its own and says so in the activity log, manual only says one is there and waits to be asked (either way it runs from the next start) (auto, manual); notify.desktop: a notification on this machine when a reminder rings, whether or not a page is open (on, off); notify.command: a command run when a reminder rings, with {title}, {text} and {url} in its arguments: a push service such as ntfy, an email, a text; actions.allow: the programs a command action may run, by name, comma separated (curl, python); empty means command actions run nothing; mqtt.broker: the MQTT broker for devices, such as tcp://192.168.1.10:1883; empty means none (takes effect at the next start); mqtt.client_id: how this workspace names itself to the broker; mqtt.username_env: the NAME of the environment variable that holds the broker username; mqtt.password_env: the NAME of the environment variable that holds the broker password; meetings.teams_client_id: the application (client) id of the person's own app in Microsoft Entra, for bringing Teams transcripts once a meeting is over; they then connect on the help page; meetings.teams_tenant: their Microsoft tenant id or domain; empty is any work or school account; meetings.zoom_account_id: the account id of the person's Zoom Server-to-Server OAuth app, for bringing Zoom transcripts; meetings.zoom_client_id: that Zoom app's client id; meetings.zoom_secret_env: the NAME of the environment variable that holds that Zoom app's client secret; publish.tabs: tabs anyone on the internet may read, people and AI services alike, with no login, by name, comma separated; empty is none. ONLY when the person explicitly asks to publish or make something public, never on your own; the person is asked before anything is published; publish.types: content types whose every record anyone on the internet may read, people and AI services alike, with no login, by name, comma separated; empty is none. ONLY when the person explicitly asks to publish; the person is asked first; tailnet.peers: the other computers hosting this same workspace, by their machine name on the tailnet, comma separated (bob-home, my-laptop): this copy keeps in step with each, both ways. Each has to host a copy of this workspace and have this computer's owner or a host let in. Empty is none; tailnet.name: the name of this computer on the person's Tailscale network, so their phone and other devices signed in to Tailscale as them open the workspace from anywhere at https://..ts.net; empty is off. It takes effect at once, and the steps to finish (signing in, turning on HTTPS) come back from this call and appear in the chat. Offer it when the person wants the workspace on their phone or away from this computer. A setting that holds a key or a token takes the NAME of the environment variable that holds it, never the key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYes
valueYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With annotations only supplying safety/idempotency hints, the description carries the behavioral load and does so richly: it distinguishes reversible from irreversible settings, explains that irreversible ones trigger a confirmation prompt ('nothing changes until they say yes'), specifies which settings take effect at next start vs immediately, and repeatedly warns that secrets must be given as env-var names, never values.

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

Conciseness2/5

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

The definition is a single enormous paragraph enumerating every setting inline. While the content is needed given 0% schema coverage, the structure is poor: no formatting, no per-key grouping, and important routing rules (e.g., the confirmation flow) are buried mid-stream. It is bloated and hard to parse.

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?

For a high-complexity tool with a 37-value enum, no output schema, and 0% schema descriptions, the definition covers essentially everything an agent needs: each key's meaning, valid values, defaults, effect timing, safety conditions, and even the note that setup steps are returned from the call.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must supply all parameter meaning. It documents every one of the 37 enum values for 'key' with type, allowed values, default-off behavior and timing. This is exactly the compensation the low coverage requires.

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 opening sentence states a clear verb+resource: 'Change one setting of this workspace.' An agent can distinguish it from siblings like update_sameway or add_workspace. The purpose is clear, though it is immediately swamped by the enum enumeration that follows.

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?

Explicit usage conditions are given: 'when the person asks for it,' 'Set it the moment they tell you,' and hard exclusions for publish settings ('ONLY when the person explicitly asks... never on your own'). It also notes confirmation behavior. Lacks a direct comparison to any sibling tool, keeping it from a 5.

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