Skip to main content
Glama

Set what this account does with confirmed findings

set_policy

Change the account-wide fix policy: whether to triage severity before deciding (triage_first), what a run whose confirmed findings are all low is worth (low_only: merge|fix), what one confirmed major means (any_major: fix_all|fix_majors), and after how many rounds of ONE change in a row with a confirmed medium+ the doors stop ordering fixes and say rethink – ship dark or split (rounds_before_rethink, default 3; rounds are counted by the meta.change_id you send). It also holds switches the server enforces for every client: deep (allow|never – deep hunts on this account) and stories (never|private|ask|auto – feed stories: off, private to the user, posted with the user's approval, or posted without asking). Widening what is published (stories auto, a boost of hours that posts without asking, author: handle over anonymous) is the user's alone: this tool applies the rest of the call and answers with a one-time confirm_url for the widening, which the user opens signed in to confirm (24 h; any later change of the policy cancels it). Partial: send only the fields you change. policy in get_balance and in this answer shows the account's own settings, what this tool writes, beside this API key's own deep_only and live_link (set on /me/keys, not here); policy_note says what applies to this key. Sending that document back as you read it, leave out deep_only and live_link and keep its seen unchanged: a field still equal to what you were shown is not a change and is not written. A change the user asks for is sent without seen. The policy is the account's, shared by every key, session and machine on it; each API key's own settings, which a person sets on the key page /me/keys, can narrow it for that key and set_policy cannot widen them. Change it only when the USER asks, never to make your own current task easier.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "set_policy"
  }
}

Input Schema

NameRequiredDescriptionDefault
deepNo`never` switches deep hunts off on this account: submit_review with any `deep` answers error `deep_disabled` and get_findings offers none. `allow` is the default; a key whose own settings switch them off stays off. Only on the user's word
seenNoOnly with a document sent back as you read it (get_balance or this tool's answer): its `seen`, unchanged; each field still equal to what you were shown is dropped as an echo. Never build or edit it, and leave it out of a change the user asks for.
boostNoHours during which stories go out without asking while stories is `ask`: `{"stories_auto": 6}` (1–24; 0 ends it now). Starting or lengthening one widens what is published: it comes back as a `confirm_url` for the user
authorNoWho signs a story: `handle` (the GitHub login) or `anonymous`. `anonymous` applies now; `handle` over anonymous comes back as a `confirm_url` for the user
snoozeNoPause an OFFER, not a feature, for N hours (1–168; 0 offers again): `{"deep": 24}` stops the deep-hunt offer, `{"stories": 24}` the question about posting a story, `{"earned": 24}` the reminder about earned rewards. Set it only when the user asks to hear less of it (or presses the button that says so), never on your own: a deep hunt the user asks for still runs.
storiesNo`never` switches feed stories off on this account: post_story, confirm_findings with only a `story` and the story link answer error `stories_disabled`; confirm_findings with verdicts beside a story still records the verdicts and carries `story_error` starting `stories_disabled`, and stops carrying the `share` block. `private` keeps the doors open but posts every story privately: it counts toward the free review and groups into species, it is kept off every public page (the user reads it on /me/stories), and the answer carries `visibility: "private"`. `ask` (the default; `allow` is its old name) posts a story only with the user's approval of it; it does not stop an automatic posting the user started for a while on /me/policy (policy_note names it): `boost: {"stories_auto": 0}` does. `auto` posts without asking once the server's story safety check is live (until then it asks, like `ask`): only the user sets it: set_policy answers with a `confirm_url` the user opens. A key whose own settings switch them off, or make them private, stays so. Only on the user's word
low_onlyNoA run whose confirmed findings are all low: `merge` as it is (default) or `fix` them
any_majorNoWith one confirmed medium+: `fix_all` confirmed findings (default) or `fix_majors` only
triage_firstNoGrade each finding's severity yourself before deciding what to do (default true)
rounds_before_rethinkNoRounds of one change in a row that may end with a confirmed medium+ before the stop sign (integer 1–10, default 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / stories / description
      Previous value: -"`never` switches feed stories off on this account: post_story, confirm_findings with only a `story` and the story link answer error `stories_disabled`; confirm_findings with verdicts beside a story still records the verdicts and carries `story_error` starting `stories_disabled`, and stops carrying the `share` block. `private` keeps the doors open but posts every story privately: it counts toward the free review and groups into species, it is kept off every public page (the user reads it on /me), and the answer carries `visibility: \"private\"`. `ask` (the default; `allow` is its old name) posts a story only with the user's approval of it; it does not stop an automatic posting the user started for a while on /me (policy_note names it): `boost: {\"stories_auto\": 0}` does. `auto` posts without asking once the server's story safety check is live (until then it asks, like `ask`): only the user sets it: set_policy answers with a `confirm_url` the user opens. A key whose own settings switch them off, or make them private, stays so. Only on the user's word"New value: +"`never` switches feed stories off on this account: post_story, confirm_findings with only a `story` and the story link answer error `stories_disabled`; confirm_findings with verdicts beside a story still records the verdicts and carries `story_error` starting `stories_disabled`, and stops carrying the `share` block. `private` keeps the doors open but posts every story privately: it counts toward the free review and groups into species, it is kept off every public page (the user reads it on /me/stories), and the answer carries `visibility: \"private\"`. `ask` (the default; `allow` is its old name) posts a story only with the user's approval of it; it does not stop an automatic posting the user started for a while on /me/policy (policy_note names it): `boost: {\"stories_auto\": 0}` does. `auto` posts without asking once the server's story safety check is live (until then it asks, like `ask`): only the user sets it: set_policy answers with a `confirm_url` the user opens. A key whose own settings switch them off, or make them private, stays so. Only on the user's word"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the one-time confirm_url handshake for widening actions (24 h expiry, cancelled by any later policy change), that the policy is account-wide and shared across keys/sessions, that key settings can only narrow and never be widened here, and how the `seen` echo suppresses unchanged fields. These are non-obvious behavioral traits an agent could not infer from the schema.

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

Conciseness3/5

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

The core purpose is front-loaded, but the body is one dense run-on paragraph with stacked parentheticals that is hard to parse on first read. It also duplicates in prose much of what the per-field schema descriptions already say at length (stories, deep, snooze), so several sentences do not earn their place twice.

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 10-parameter mutation tool with no output schema and no annotations, the description is thorough: it names the return surface (policy, policy_note, confirm_url), the error codes gated by deep/stories settings, and the safety boundary around user consent. Remaining gaps are minor, e.g. the exact response shape after a partial update is only loosely implied.

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 cross-field meaning the schema does not: rounds are 'counted by the meta.change_id you send', a document sent back must drop deep_only and live_link while keeping `seen` unchanged, and a user-requested change is sent without `seen`. That materially clarifies how parameters interact rather than restating individual field docs.

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 description opens with a concrete verb and resource: 'Change the account-wide fix policy', then enumerates exactly which knobs it writes (triage_first, low_only, any_major, rounds_before_rethink, deep, stories). It explicitly distinguishes itself from get_balance, which merely 'shows the account's own settings, what this tool writes', so an agent can separate read from write without opening either schema.

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

Usage Guidelines5/5

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

It states when to use ('Change it only when the USER asks, never to make your own current task easier') and when not (widening publication is 'the user's alone' and comes back as a confirm_url). It also routes agents elsewhere for adjacent concerns: key-level settings are 'set on /me/keys, not here' and 'set_policy cannot widen them'. Partial-update and seen-echo rules give explicit operational conditions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.