Compass OS: Career

start mock interview

start_mock_interview

Read-onlyIdempotent

Start one of the practice path's ready-made mock interviews in an interactive card (the product ones walk a real case from list_cases). In the card the user picks a reply each turn and gets coached; their score (1 to 5) saves to Compass OS when they finish, counting as a case walked through. Use list_cases to choose one, and get_practice for STAR answer scores. Never give the answers in the chat. Starting it saves nothing; without a card, the reply links to the mock interview page. A name with no ready-made interview returns the ones that exist.

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

Input Schema

Name	Required	Description	Default
`interview`	No	A ready-made interview's id, or a case's company or product, as list_cases shows it. Leave empty for the next one on the user's track.

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.5/5.0

Behavior4/5

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

Adds real behavior beyond the readOnly/idempotent annotations: the call starts an interactive card, persists nothing itself ("Starting it saves nothing"), and degrades to a link to the mock interview page when no card can be shown. It also discloses the score flow (1-5, saved to Compass OS, counted as a case walked through) and the unknown-name fallback. The only soft spot is that the finish step is described as "when they finish" without naming the finish_mock sibling, leaving the write path slightly implicit.

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?

Front-loaded with the action and card mechanics, then routing rules, then failure behavior - a sensible order. Every sentence carries information, though the parenthetical "(the product ones walk a real case from list_cases)" and the run-on semicolon clause make it denser than it needs to be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-param tool with an output schema and full schema coverage, this covers the action, the interaction model, persistence semantics, sibling routing, and the unknown-name fallback. The remaining gap is small: it never says what the reply contains when a card is produced versus when only a link is returned, though the output schema likely handles detail.

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 clarifying that unknown names are not errors but return the list of existing interviews, and by explaining that product entries correspond to real cases surfaced via list_cases. It does not restate the schema's "empty returns the next one on the user's track" behavior, so it complements rather than duplicates the parameter docs.

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?

Opens with a specific verb+resource ("Start ... ready-made mock interviews") and immediately scopes it ("practice path's", "in an interactive card"). It explicitly carves out the space from siblings: product mocks walk a case from list_cases, while STAR scoring belongs to get_practice. An agent can distinguish this from get_practice and list_cases without opening either schema.

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?

Names both relevant alternatives with the condition that selects them: "Use list_cases to choose one, and get_practice for STAR answer scores." It also gives a behavioral rule for the chat surface ("Never give the answers in the chat"), which is exactly the kind of when/when-not instruction an agent needs mid-conversation.

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?