Compass OS: Career

find jobs

find_jobs

Read-onlyIdempotent

List the best roles from the user's last job scan that aren't tracked yet, up to six, ranked by Role fit (level and scope, industry, results and must-haves read against their whole profile), with location, pay, and the keywords each matches or misses. Use it for "any new matches?"; tracked roles are in list_pipeline, and search_web finds roles outside the scan. Read-only: it doesn't run a new scan (the user does that on Find jobs). A role the AI hasn't checked yet says "Fit not checked".

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_jobs"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

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

Changed1 schema field changedNov 4, 2026

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 already declare readOnlyHint and idempotentHint, and the description reinforces rather than contradicts them by explaining that it does not trigger a scan (the user does that on Find jobs). It goes further with non-obvious data behavior: results are capped at six, ordered by fit, and an unchecked role surfaces the literal string "Fit not checked." That sentinel value is behavioral detail an agent could not infer from annotations or schema.

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?

It is front-loaded: the main action and its scope come first, then the ranking explanation, then the routing sentence. The parenthetical enumerating the fit criteria is dense but load-bearing; a slightly tighter phrasing would read better, though no sentence is filler.

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 zero parameters, a full output schema, and read-only annotations, the remaining burden is scope, ordering, and edge cases, all of which are covered. The cap of six, the ranking rule, the branch to two siblings, and the "Fit not checked" state leave nothing an agent needs in order to call it correctly.

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?

The tool takes zero parameters, so the baseline is a 4, and the description adds a meaningful implicit limit ("up to six") rather than pretending to accept filters the schema does not offer. There is nothing further to disambiguate.

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 ("List the best roles from the user's last job scan") plus the discriminating constraint "that aren't tracked yet, up to six." It adds the ranking basis (Role fit across level/scope, industry, results, must-haves) and returned fields (location, pay, matched/missed keywords), so an agent can tell exactly what this returns versus list_pipeline or search_web.

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 phrase ("Use it for 'any new matches?'") and names both alternatives with the condition that selects them: tracked roles go to list_pipeline, roles outside the scan go to search_web. It also rules out misuse by noting it does not run a new scan.

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?