Skip to main content
Glama

profile_update

Update or create a local profile via JSON Merge Patch, excluding sensitive medical data.

Instructions

Create or patch the local profile. Never include diagnoses, medications or conditions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patchYesJSON Merge Patch (RFC 7386) applied to the profile. If no profile exists, it must be a complete profile; id, orp_version and timestamps are filled in.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileYes
warningsYes
readinessYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already establish that this is a readOnlyHint=false, destructiveHint=false operation, and the description confirms the write nature ('Create or patch') without contradicting them. It adds the 'local profile' scope and the prohibited-content guardrail, but does not disclose side effects such as overwrite behavior or persistence beyond what the schema's JSON Merge Patch detail implies.

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 entire description is two short sentences: one front-loaded with the action and resource, the second an imperative safety rule. There is no filler or redundant restatement of the schema.

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 tool with a rich patch schema, an output schema, and safety annotations, the description plus schema provides what an agent needs to invoke it correctly. The main omission is explicit routing relative to profile_get, but that is a usage-guidance issue and does not leave the invocation ambiguous.

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

Parameters3/5

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

The schema covers the single required parameter 'patch' at 100%, including the RFC 7386 merge-patch semantics and the complete-profile rule for new profiles. The tool definition itself adds no parameter-level meaning beyond 'Create or patch', which matches the baseline of 3 for high schema coverage.

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 description opens with the specific verb phrase 'Create or patch' and names the 'local profile' as the resource, which makes the tool's mutating purpose clear. It does not explicitly name sibling profile_get as a read alternative, so it misses the top level of differentiation.

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

Usage Guidelines3/5

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

'Never include diagnoses, medications or conditions' is an explicit content restriction and helps an agent avoid harmful payloads. However, the description gives no when-to-use guidance versus profile_get or other siblings, and the create-vs-patch condition is left to the schema's parameter description.

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