Skip to main content
Glama
Sign In

Compass OS: Career

by dev.compass-os
OverviewDiscussionsAdmin

log win

log_win

Add a new win (something the user did, and its result) to their wins log, for resumes, reviews and Rewinds later. Give the company and title of the role it happened in (from get_profile) when it isn't the current one; without them it goes to the role its date falls in. Use edit_win to change a logged win and add_profile_line for a resume accomplishment; an interview story belongs in the story bank instead. It asks the user first and only adds: logging it twice makes two wins. Returns the saved win with its tags. 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": {
      "what": "<what>"
    },
    "name": "log_win"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateNoWhen it happened, as YYYY-MM-DD; leave empty for today
whatYesWhat the user did, in their words
titleNoThe title of the role it happened in, as get_profile shows it
resultNoWhat came of it, ideally with a number, e.g. "cut onboarding time 30%"
companyNoThe company of the role it happened in, as get_profile shows it; leave empty to go by the date

Output Schema

NameRequiredDescriptionDefault
textYesThe answer, or what was done, in plain words for the user: the same text as content
undoNoOn a saved write: its undo handle, for undo within 24 hours
widgetNoThe 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.

  1. Changed2 schema fields changed
    • changedInput schema / properties / company / description
      Previous value: -"The company of the role it happened in, as profile_gaps shows it; leave empty to go by the date"New value: +"The company of the role it happened in, as get_profile shows it; leave empty to go by the date"
    • changedInput schema / properties / title / description
      Previous value: -"The title of the role it happened in, as profile_gaps shows it"New value: +"The title of the role it happened in, as get_profile shows it"
  2. Changed1 schema field changed
    • addedOutput schema / properties / undo
      Added value: +{
+  "description": "On a saved write: its undo handle, for undo within 24 hours",
+  "type": "string"
+}
  3. Changed6 schema fields changed
    • addedInput schema / properties / company / description
      Added value: +"The company of the role it happened in, as profile_gaps shows it; leave empty to go by the date"
    • addedInput schema / properties / date / description
      Added value: +"When it happened, as YYYY-MM-DD; leave empty for today"
    • addedInput schema / properties / result / description
      Added value: +"What came of it, ideally with a number, e.g. \"cut onboarding time 30%\""
    • addedInput schema / properties / title / description
      Added value: +"The title of the role it happened in, as profile_gaps shows it"
    • addedInput schema / properties / what / description
      Added value: +"What the user did, in their words"
    • 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"
+}
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive, closed-world, and the description adds real behavior on top: it confirms with the user before writing, warns that duplicate logging creates two distinct wins, and states an undo window of 24 hours. The remaining gap is that it does not cover validation failures or what happens when the date matches no role, but the mutation semantics are otherwise well disclosed.

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 opening sentence front-loads purpose and definition, then alternatives and behavioral caveats follow in a logical order with no filler. 'Returns the saved win with its tags' is redundant given a populated output schema and costs a few words, keeping it just short of a 5.

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 confirmation-gated write tool with full schema coverage and an output schema, the description supplies everything the structured fields cannot: sibling routing, the company/title resolution rule, duplicate-creates-two-wins behavior, and the undo window. An agent can invoke it correctly without further context.

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 a bump by explaining the resolution logic behind company/title — supply them from get_profile when the win is not in the current role, otherwise the win is assigned to whichever role the date falls in. That adds meaning beyond the schema's 'leave empty to go by the date' by tying the fallback to the role timeline.

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 ('Add a new win ... to their wins log') and immediately defines the domain object in parentheses as 'something the user did, and its result', so the agent knows what qualifies. It also states the downstream consumers (resumes, reviews, Rewinds), which separates it from addProfileLine and addStory before either schema is opened.

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?

Explicit routing: 'Use edit_win to change a logged win and add_profile_line for a resume accomplishment; an interview story belongs in the story bank instead.' It also gives the conditional rule for supplying company/title (only when the role is not the current one, taken from get_profile). Both the when-to-use and the when-not-to-use cases are covered with named siblings.

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 toolsInspect
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