Skip to main content
Glama

identity_update_user_preferences

Idempotent

Deprecated: update the logged-in user's locale preferences, saving only the language field. Use the internal localLanguage preferences API instead.

Instructions

[DEPRECATED] Update the currently logged in user's locale preferences. Note that only language field will be saved.

Use this API instead: * /cloudapi/1.0.0/preferences/internal:localLanguage ### Access Policy | Role | Access | | ----- | ----- | | Platform operator | ✔️ | | Organization Owner | ✔️ | | Organization Member | ✔️ | | Service Account (Whitelisted Client) | ✔️ |

PUT /csp/gateway/am/api/loggedin/user/profile/locale-preferences

Input Schema

NameRequiredDescriptionDefault
bodyYesRequest body

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare idempotent, non-destructive, non-readOnly, and openWorld, so the remaining burden is modest. The description adds real behavioral context annotations cannot: deprecation status and the caveat that only the language field is persisted even if locale is supplied. It does not describe the response body, but with no output schema that is a minor gap.

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?

Deprecation and replacement are correctly front-loaded, and the field caveat is prominent. However, the raw markdown role table and the bare PUT path bloat the text without adding much beyond what an agent needs to select and call the tool.

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 one-parameter, fully-documented schema with annotations covering safety, the description supplies what is missing: deprecation, replacement, authorization roles, and the language-only persistence caveat. Return-value behavior is unspecified, which is the only notable gap.

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. The description exceeds that by clarifying that the `locale` property is effectively ignored and only `language` is saved — meaning an agent can skip populating locale despite it appearing in the schema.

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 (update), resource (locale preferences), and scope (currently logged-in user), and immediately flags the tool as deprecated with a named replacement. An agent can distinguish it from identity_update_user_profile and provider_update_user_preference without opening a 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?

Explicitly says [DEPRECATED] and names the replacement endpoint (/cloudapi/1.0.0/preferences/internal:localLanguage), giving a clear when-not-to-use signal. The role/access table adds who may call it, further grounding usage.

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