Compass OS: Career

update profile

update_profile

DestructiveIdempotent

Replace one section of the user's profile with what the user said is true: headline or summary (in text), skills (the whole new list), or role (one role's accomplishments, by company and title as get_profile shows them: the whole new list in bullets, or a single one by its number in line with the new wording in text). Read the section with get_profile first. Use add_profile_line to add an accomplishment without replacing the others, and edit_material or edit_resume to change a resume instead. It asks the user first and overwrites only that section. Returns the updated section. Once it's saved, undo can put it back within 24 hours.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "section": "<section>"
    },
    "name": "update_profile"
  }
}

Input Schema

Name	Required	Description
`line`	No	For role: the number of the one accomplishment to reword, from 1, as get_profile numbers them
`text`	No	The new headline or summary; for role with line, the accomplishment's new wording
`title`	No	For role: the role's title, as get_profile shows it
`skills`	No	For skills: the whole new list, e.g. ["SQL", "Roadmapping"]
`bullets`	No	For role without line: the role's whole new list of accomplishments
`company`	No	For role: the role's company, as get_profile shows it
`section`	Yes	Which section to replace

Output Schema

Name	Required	Description
`text`	Yes	The answer, or what was done, in plain words for the user: the same text as content
`undo`	No	On a saved write: its undo handle, for undo within 24 hours
`widget`	No	The card the host draws with it, e.g. "pipeline"; "confirm" means a write waits for the user's Yes and nothing is saved yet

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedOutput schema / properties / undo

Added value: +{
+  "description": "On a saved write: its undo handle, for undo within 24 hours",
+  "type": "string"
+}

Changed8 schema fields changedNov 4, 2026

addedInput schema / properties / bullets / description

Added value: +"For role without line: the role's whole new list of accomplishments"

addedInput schema / properties / company / description

Added value: +"For role: the role's company, as get_profile shows it"

addedInput schema / properties / line / description

Added value: +"For role: the number of the one accomplishment to reword, from 1, as get_profile numbers them"

addedInput schema / properties / section / description
```
Added value: +"Which section to replace"
```

addedInput schema / properties / skills / description

Added value: +"For skills: the whole new list, e.g. [\"SQL\", \"Roadmapping\"]"

addedInput schema / properties / text / description

Added value: +"The new headline or summary; for role with line, the accomplishment's new wording"

addedInput schema / properties / title / description

Added value: +"For role: the role's title, as get_profile shows it"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "text": {
+      "description": "The answer, or what was done, in plain words for the user: the same text as content",
+      "type": "string"
+    },
+    "widget": {
+      "description": "The card the host draws with it, e.g. \"pipeline\"; \"confirm\" means a write waits for the user's Yes and nothing is saved yet",
+      "type": "string"
+    }
+  },
+  "required": [
+    "text"
+  ],
+  "type": "object"
+}

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructive=true, idempotent=true), the description discloses the confirmation flow ("It asks the user first"), the bounded blast radius ("overwrites only that section"), the return value, and a concrete recovery path ("undo can put it back within 24 hours"). Those are the exact behavioral facts an agent needs before invoking a destructive write, and they go well past what the annotations alone convey.

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

Conciseness4/5

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

The scoping verb and the section list are front-loaded, and every sentence carries information (sections, prerequisite, alternatives, confirmation, undo). The first sentence is a deeply nested parenthetical that is hard to parse on one pass, which costs a point against otherwise tight writing.

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?

With an output schema present, the description need not explain return shape and only notes "Returns the updated section." For a destructive, conditional multi-mode write tool it covers preconditions, alternate tools, confirmation, scope of overwrite, and recovery, so nothing material is missing.

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 earns extra by stating the section-to-parameter contract in one place (skills means the whole new list, role without line means all bullets, role with line means a single reworded accomplishment keyed by get_profile's numbering). It largely restates the per-parameter schema text, but the consolidated conditional mapping clarifies which fields are meaningful for each enum value.

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 names a specific verb and resource ("Replace one section of the user's profile") and enumerates exactly which sections and payloads are valid: headline/summary text, whole skills list, or role accomplishments by company and title. It also names the siblings it is not (add_profile_line, edit_material, edit_resume), so an agent can select it 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 gives an explicit precondition ("Read the section with get_profile first") and explicit routing rules to alternatives: add_profile_line for appending an accomplishment, edit_material or edit_resume for resume changes. When-not-to-use is covered by those same exclusions, leaving nothing to inference.

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

All Compass OS: Career tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?