JobMojito

Change which interviews can use a document

set_knowledge_base_document_interviews

DestructiveIdempotent

[Knowledge base] Replace the interview limit of an existing knowledge base document. interview_ids is required: a list limits it to those interviews on the same knowledge base, [] to none, and null opens it to every interview on the knowledge base.

Every argument in full, with examples: get_tool_reference.

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": {
      "knowledge_base_id": "<knowledge_base_id>",
      "interview_ids": "<interview_ids>"
    },
    "name": "set_knowledge_base_document_interviews"
  }
}

Input Schema

Name	Required	Description
`llm_model`	No	Your model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
`interview_ids`	Yes	The whole new list, which replaces the old one. A list limits the document to those interviews, an empty list to no interview, and null opens it to every interview on the knowledge base. Required, so that leaving it out can never open a document. Each interview must belong to the same company as the document and use the same knowledge base.
`conversation_id`	No	The conversation_id this server returned earlier in this conversation, unchanged, including after later user messages. Omit it if you have none. Recorded for the server developer's analytics.
`knowledge_base_id`	Yes	The document to change: `knowledge_base_id` from the upload response or from list_knowledge_base_documents.

Output Schema

Name	Required	Description
`interview_ids`	No
`_mcp_instructions`	No	Server-issued metadata for this conversation.
`knowledge_base_id`	Yes
`limit_to_interviews`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

changedInput schema / properties / knowledge_base_id / description

Previous value: -"The document to change: `knowledge_base_id` from the upload response or from knowledge-base-document-list."New value: +"The document to change: `knowledge_base_id` from the upload response or from list_knowledge_base_documents."

Changed6 schema fields changedNov 9, 2026

removedInput schema / properties / interview_ids / example

Removed value: -[
-  "de300000-0000-4000-8001-000000000007"
-]

removedInput schema / properties / knowledge_base_id / example
```
Removed value: -"44444444-4444-4444-8444-444444444444"
```

addedInput schema / properties / llm_model

Added value: +{
+  "description": "Your model id, e.g. \"claude-opus-4-8\"; \"unknown\" if unsure. For analytics.",
+  "type": "string"
+}

removedOutput schema / properties / interview_ids / description

Removed value: -"The interviews this document is limited to. Present only when `limit_to_interviews` is true; an empty list means no interview can use it."

removedOutput schema / properties / knowledge_base_id / description
```
Removed value: -"The document that was changed."
```

removedOutput schema / properties / limit_to_interviews / description

Removed value: -"True when the document is limited to the interviews in `interview_ids`. False when every interview on the knowledge base can use it."

AddedNov 6, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The description discloses the most important non-obvious behavior: this is a whole-list replacement, not an append, and passing null widens the document to every interview on the knowledge base. That adds real context on top of the destructiveHint/idempotentHint annotations. It does not cover permission requirements or what happens to interviews that lose access.

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?

Two tight sentences, with the replacement behavior front-loaded before the interview_ids enumeration. The trailing get_tool_reference pointer is useful but is boilerplate that some agents will not act on and slightly dilutes the definition.

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 mutation tool with rich annotations and a 100%-covered schema and an output schema, the description gives what an agent most needs to call it correctly: the replacement semantics and the null-means-everyone rule. Missing only edge behavior such as permissions and the state of interviews removed from the list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already spells out the list/empty-list/null semantics for interview_ids nearly verbatim, so the description is largely restating structured data. The 3 baseline applies; no format, ordering, or deduplication details are added beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Replace') and a specific resource ('the interview limit of an existing knowledge base document'), which is clearly distinct from the upload/list siblings. It does not explicitly contrast itself with any sibling by name, and the '[Knowledge base]' prefix is the only scoping cue.

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

Usage Guidelines3/5

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

Usage is implied by the word 'Replace' and by the fact that the tool targets an existing document, but there is no explicit when-to-use or when-not guidance, nor any reference to upload_knowledge_base_document or list_knowledge_base_documents as the alternatives. The get_tool_reference pointer sends the agent elsewhere rather than resolving the question inline.

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

All JobMojito 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.