Skip to main content
Glama

Invite someone to a Compass interview

compass_interviews_create

Mints a stakeholder-interview invite: a no-account guest link where the person talks to an interviewer agent briefed by your focusPrompt, and the transcript flows back into Compass as reviewable draft pages. THE KNOWLEDGE-GAP MOVE: when caliper_flow_performance shows failures clustered on missing company facts (the judge says the flow invented a policy, missed a rule, didn't know who owns something), the fix is usually not a prompt edit — it's asking the human who actually knows. Write a focusPrompt that names the SPECIFIC gaps (cite the eval run id), pick the owner of the relevant workflow as interviewee when the map knows one. When you have their email, send the link with compass_interview_invite next rather than asking the user to forward it; otherwise hand the user the link. May return needs_confirmation — tell the user who you want to interview and why, then wait.

Input Schema

NameRequiredDescriptionDefault
anonymousNoThe guest is told it's anonymous and never asked who they are; no name or email is kept, so leave intervieweeName and intervieweeEmail out, and the link isn't emailed from here. Use when the user asks for anonymous interviews.
workspaceNoWorkspace slug. Personal tokens with no default workspace MUST pass this; tokens with a default can override per call. Ignored for workspace API keys.
approvalIdNoApproval id from a prior needs_confirmation response, after the user has approved. Omit on the first call.
focusPromptYesThe interviewer's aim (≤2000 chars), never shown to the guest: why the team is asking, in one sentence; 2–3 things to come away knowing, each describable from experience (who does a step, what happens when it goes wrong, how long it waits, why a check exists), aimed at what the map doesn't know; and what the answers feed. No opinion or preference questions.
contextPageIdsNoCompass page ids the interviewer gets as briefing context (e.g. the workflow page whose flow underperformed).
intervieweeNameNoWho this invite is for, when known.
intervieweeEmailNoTheir email, when known — enables compass_interview_invite to send the link directly (with approval).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / focusPrompt / description
      Previous value: -"What the interviewer should dig into — specific, grounded in the gap you found (≤2000 chars). Never shown verbatim to the guest."New value: +"The interviewer's aim (≤2000 chars), never shown to the guest: why the team is asking, in one sentence; 2–3 things to come away knowing, each describable from experience (who does a step, what happens when it goes wrong, how long it waits, why a check exists), aimed at what the map doesn't know; and what the answers feed. No opinion or preference questions."
  2. Changed1 schema field changed
    • addedInput schema / properties / anonymous
      Added value: +{
      +  "description": "The guest is told it's anonymous and never asked who they are; no name or email is kept, so leave intervieweeName and intervieweeEmail out, and the link isn't emailed from here. Use when the user asks for anonymous interviews.",
      +  "type": "boolean"
      +}
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations it discloses real side effects: creates a guest-facing link, drafts pages flow back into Compass, and the call may return `needs_confirmation` requiring the agent to explain and wait. That two-phase approval loop is the kind of thing annotations cannot convey. It stops short of invite lifecycle behavior (expiry, whether repeated calls create multiple invites, revocability via compass_interviews_revoke).

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 core definition in sentence one, then usage, then mechanics, then the approval caveat — a sensible descending-priority order. Dense rather than padded, though the all-caps 'THE KNOWLEDGE-GAP MOVE' framing and stacked parentheticals add a little rhetorical weight.

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 7-parameter creation tool with no output schema, the description covers purpose, creation conditions, sequencing to the invite sender, and the confirmation round-trip. The main gap is the success payload — it implies a link is returned ('hand the user the link') but never states what the response contains or what the agent should do with draft-page ids.

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 baseline is 3, but the description adds real selection guidance: focusPrompt should name the SPECIFIC gaps and cite the eval run id, and interviewee should be the owner of the relevant workflow when the map knows one. It doesn't add much for workspace or contextPageIds, which the schema already explains.

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?

Specific verb and resource — 'Mints a stakeholder-interview invite' — immediately qualified by what the artifact actually is: a no-account guest link to an interviewer agent briefed by focusPrompt, with the transcript returning as draft pages. That distinguishes it cleanly from the sibling compass_interview_invite (which sends the link) and from compass_interviews_list/get/revoke.

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 when-to-use trigger wired to another tool: 'when caliper_flow_performance shows failures clustered on missing company facts … the fix is usually not a prompt edit.' It also tells the agent when NOT to stop here — if an email exists use compass_interview_invite next, otherwise hand the user the link — so the routing decision is fully resolved.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources