Skip to main content
Glama

Switch between PII and ASSIST mode

local_llm_set_mode
Idempotent

Change the conversation's processing mode to 'pii' for fully sanitized private-data handling or 'assist' for digested summaries of large outputs, keeping secrets and data local.

Instructions

Switch the server's mode for the rest of this conversation and return the instructions that apply in the new mode. 'pii': delegate everything that may touch private data; results are fully sanitized. 'assist': delegate anything context-free whose output would be larger than its digest; only secrets are scrubbed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes'pii' or 'assist'.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses meaningful behavior beyond the annotations: the mode change persists for the rest of the conversation, calling it returns the instructions for the new mode, and it details the sanitization behavior for each mode. The annotations only indicate idempotence and non-destructiveness; the description adds the stateful and return-value context.

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?

The description is two sentences, front-loads the primary action and result, and packs each mode's behavior into concise clauses. There is no filler or repetition of schema details.

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 tool with one parameter, a full schema, an output schema, and siblings covering execution, this description fully equips an agent to invoke it correctly. It covers the persistent side effect, the return value, and the precise mode semantics without needing to explain outputs already described by the output schema.

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?

The single parameter already has 100% schema description coverage, but the description adds substantial semantic value beyond the schema's simple

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 uses a specific verb and resource: 'Switch the server's mode' and explicitly names the two modes, 'pii' and 'assist'. It clearly distinguishes this tool as the mode-setter among siblings like local_llm_run, local_llm_delegate, and local_llm_status.

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?

The description gives clear, actionable context for when each mode is appropriate: use 'pii' for anything touching private data and 'assist' for context-free outputs larger than their digest. It does not explicitly name sibling tools or state when not to use set_mode, but the intended usage is well implied by the persistence wording: 'for the rest of this conversation.'

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