Compass OS: Career

follow company

follow_company

Idempotent

Follow a company for the user, apart from the roles they track: its new roles for their titles and posted pay are checked weekly and shown on the Companies page. Use it when the user asks to follow, watch or keep an eye on a company. Give the company's own website when the user said it; otherwise Compass OS finds it, and when two sites could be the company it answers with them so you can ask the user which. It asks the user first; a company already followed is left as it is. Nothing is sent to the company and no one who works there is looked up. 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>"
    },
    "name": "follow_company"
  }
}

Input Schema

Name	Required	Description	Default
`company`	Yes	The company's name, as the user said it.
`website`	No	The company's own website (instacart.com), when the user gave it or picked it; without it Compass OS finds it, and asks when it isn't sure.

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 9, 2026

changedInput schema / properties / website / description

Previous value: -"The company's own website (instacart.com), when the user gave it or it's certain; without it the follow guesses <name>.com."New value: +"The company's own website (instacart.com), when the user gave it or picked it; without it Compass OS finds it, and asks when it isn't sure."

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true) by disclosing consequences an agent must anticipate: it asks the user first, an existing follow is left unchanged, nothing is sent to the company and no employees are looked up, and undo is available for 24 hours. The disambiguation behavior — returning competing sites so the agent can ask the user which — is a genuinely useful non-obvious trait.

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 core action and the "use it when" trigger are front-loaded, and most sentences carry distinct facts (confirmation, idempotency, privacy, undo window). It is a dense paragraph with mild restatement — the ambiguous-site fallback appears both in the description and the website schema text — which costs a little tightness.

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?

An output schema exists, yet the description still explains the one return case the agent must handle (multiple candidate sites requiring a user choice) rather than restating field contents. For a two-parameter, confirmed, reversible mutation, nothing needed for correct invocation 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, and the description adds real meaning on top: the website argument is only passed when the user supplied or picked it, and omitting it triggers automatic lookup with a clarifying question when ambiguous. It does not add format guidance beyond the schema's example format, keeping it just above baseline.

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 ("Follow a company for the user") and immediately carves out scope against role tracking ("apart from the roles they track"), which separates it from track_job and remove_jobs in the sibling list. An agent can tell what this does and what it does not do without opening the schema.

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

Usage Guidelines4/5

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

Gives an explicit trigger phrase set: "Use it when the user asks to follow, watch or keep an eye on a company." The contrast with tracked roles implies the boundary with job-tracking tools, but no sibling alternative is named outright for the related-but-different intent.

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?