Compass OS: Career

audit linkedin

audit_linkedin

Read-onlyIdempotent

Score the user's saved LinkedIn headline and About out of 100 against their target keywords, with the same deterministic checks the LinkedIn page in Compass OS shows, and list the top fixes, most important first, each with what's wrong. It also returns the saved headline and About. Use it before update_linkedin, which saves the fixed text; for gaps in the Compass OS profile use get_profile. Read-only: it reads Compass OS's saved copy, not LinkedIn itself.

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": "audit_linkedin"
  }
}

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.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds real context beyond them: it reads Compass OS's saved copy rather than LinkedIn itself, the checks are deterministic and match what the LinkedIn page shows, and fixes are returned most-important-first with reasons for each. Only minor gaps remain, such as behavior when no target keywords or no saved text exists.

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 scoring purpose and output come first, then usage routing, then the read-scope clarification, so it is well front-loaded. It is fairly dense and could be trimmed slightly, but essentially every clause carries routing or behavior information.

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 zero-parameter, read-only tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what is scored, what is returned, ordering of the fix list, and which sibling to pick instead. Return-value detail is already carried by the output schema.

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?

With zero parameters the baseline is 4, and the description confirms the tool needs no input because it operates on the already-saved headline, About, and target keywords. It adds no misleading parameter-like expectations.

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 (score) applied to a specific resource (the user's saved LinkedIn headline and About) with the output shape (a score out of 100 plus an ordered fix list). It is clearly distinguishable from update_linkedin and get_profile, which it names explicitly.

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 explicit routing: use this before update_linkedin, which saves the fixed text, and use get_profile for gaps in the Compass OS profile. The when-to-use and which-alternative conditions are both stated rather than inferred.

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?