Compass OS: Career

move job

move_job

DestructiveIdempotent

Move a tracked role to another pipeline stage, naming it by company and title as list_pipeline shows them. Use it when the user reports progress (they applied, got an interview, an offer, or a no); track_job adds a new role, and remove_jobs takes one out. It asks the user first and changes only the stage; it never applies or contacts the company. Returns the new stage and a link to the role's card. 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": {
      "company": "<company>",
      "stage": "<stage>"
    },
    "name": "move_job"
  }
}

Input Schema

Name	Required	Description
`stage`	Yes	The pipeline stage to move the role to
`title`	No	The role's title as the pipeline lists it; leave it empty when the user named only the company
`company`	Yes	The employer's name, e.g. "Stripe"

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"
+}

Changed4 schema fields changedNov 4, 2026

addedInput schema / properties / company / description

Added value: +"The employer's name, e.g. \"Stripe\""

addedInput schema / properties / stage / description

Added value: +"The pipeline stage to move the role to"

changedInput schema / properties / title / description

Previous value: -"The role's title; leave it empty when the user named only the company"New value: +"The role's title as the pipeline lists it; leave it empty when the user named only the company"

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?

Annotations declare a non-read-only, destructive, idempotent write; the description adds real context beyond them: it asks the user for confirmation first, changes only the stage, never applies or contacts the company, and is reversible via undo within 24 hours. That confirmation requirement and the reversibility window are exactly the traits annotations cannot express.

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?

Well front-loaded with the action and identifier convention first, then usage, then side effects. Four sentences are mostly justified, though the track_job/remove_jobs contrast is somewhat redundant with the sibling names and could be tightened.

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 destructive-but-reversible mutation tool, the description covers trigger, identifier format, side-effect scope, confirmation behavior, return value, and rollback window. With an output schema present, the brief return mention is sufficient rather than padded.

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% (including an enum for stage and a note that title is optional), so the baseline is 3. The description still adds meaning by tying parameter values to how list_pipeline displays them, clarifying that company and title must match existing pipeline entries.

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 and resource ('Move a tracked role to another pipeline stage') and pins down the identifier format by cross-referencing list_pipeline. An agent can immediately tell this apart from track_job (adds) and remove_jobs (removes).

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?

Gives an explicit trigger ('use it when the user reports progress – applied, interview, offer, no') and names the adjacent alternatives with their differing behaviors (track_job adds, remove_jobs takes out, undo reverses). Both when-to-use and when-to-use-something-else are covered.

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?