JobMojito

Add a note to a candidate

add_candidate_note

Destructive

[Candidates] Add a note to a candidate (candidate_id) or to one result (result_id), visible to the team or private to you, optionally mentioning colleagues (each mention gets one e-mail). Notes cannot be changed or deleted through this tool.

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": {
      "text": "<text>"
    },
    "name": "add_candidate_note"
  }
}

Input Schema

Name	Required	Description	Default
`text`	Yes	The note, 1 to 10000 characters.
`llm_model`	No	Your model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
`result_id`	No	Interview result id (a result id from list_interview_results): a note on that result.
`visibility`	No	team (default): the company sees it; private: only you (the private_notes feature).	team
`candidate_id`	No	Candidate id (the `id` of a list_candidates row): a note on the candidate.
`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.
`mention_profile_ids`	No	Colleagues to mention (`profile_id` (list_users)), at most 20; each gets an e-mail with the note (the mentions feature).

Output Schema

Name	Required	Description	Default
`data`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 9, 2026

changedInput schema / properties / candidate_id / description

Previous value: -"Candidate id (profile_interview.id): a note on the candidate."New value: +"Candidate id (the `id` of a list_candidates row): a note on the candidate."

changedInput schema / properties / mention_profile_ids / description

Previous value: -"Colleagues to mention (profile.id), at most 20; each gets an e-mail with the note (switch mentions)."New value: +"Colleagues to mention (`profile_id` (list_users)), at most 20; each gets an e-mail with the note (the mentions feature)."

changedInput schema / properties / result_id / description

Previous value: -"Interview result id (interview_result.id): a note on that result."New value: +"Interview result id (a result id from list_interview_results): a note on that result."

changedInput schema / properties / visibility / description

Previous value: -"team (default): the company sees it; private: only you (switch private_notes)."New value: +"team (default): the company sees it; private: only you (the private_notes feature)."

Changed16 schema fields changedNov 9, 2026

changedInput schema / properties / candidate_id / description

Previous value: -"Candidate id (profile_interview.id): a note on the candidate. Give this or result_id."New value: +"Candidate id (profile_interview.id): a note on the candidate."

addedInput schema / properties / llm_model

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

changedInput schema / properties / mention_profile_ids / description

Previous value: -"Colleagues to mention (profile.id), at most 20; each gets an e-mail with the note (switch mentions). Not on a private note."New value: +"Colleagues to mention (profile.id), at most 20; each gets an e-mail with the note (switch mentions)."

changedInput schema / properties / result_id / description

Previous value: -"Interview result id (interview_result.id): a note on that result. Give this or candidate_id."New value: +"Interview result id (interview_result.id): a note on that result."

removedOutput schema / properties / data / properties / candidate_id / description

Removed value: -"Candidate id (profile_interview.id), for a note on the candidate."

removedOutput schema / properties / data / properties / created_at / description
```
Removed value: -"Written (ISO 8601)."
```
removedOutput schema / properties / data / properties / id / description
```
Removed value: -"Note id (interview_result_comments.id)."
```
removedOutput schema / properties / data / properties / mentioned / description
```
Removed value: -"Colleagues mentioned; each was e-mailed once."
```
removedOutput schema / properties / data / properties / mentioned / items / properties / name / description
```
Removed value: -"Their name."
```
removedOutput schema / properties / data / properties / mentioned / items / properties / profile_id / description
```
Removed value: -"Colleague (profile.id)."
```

removedOutput schema / properties / data / properties / result_id / description

Removed value: -"Interview result id (interview_result.id), for a note on a result."

removedOutput schema / properties / data / properties / skipped / description
```
Removed value: -"Mentions left out."
```
removedOutput schema / properties / data / properties / skipped / items / properties / profile_id / description
```
Removed value: -"Colleague (profile.id)."
```
removedOutput schema / properties / data / properties / skipped / items / properties / reason / description
```
Removed value: -"Why: no_access (cannot open this candidate, or not active staff), self, private_note."
```
removedOutput schema / properties / data / properties / target / description
```
Removed value: -"What the note is on."
```
removedOutput schema / properties / data / properties / visibility / description
```
Removed value: -"team or private."
```

AddedNov 8, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare the write/destructive/non-idempotent profile, and the description adds real behavior on top: permanent immutability of the created note and the outbound e-mail side effect per mention. It does not describe permissions or the response payload, but with an output schema present that is acceptable.

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 front-loaded sentences covering target, visibility, mentions, side effect, and immutability, with no padding. The trailing pointer to get_tool_reference is slightly redundant given full schema coverage but is short and clearly secondary.

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 7-parameter write tool with full schema descriptions, annotations, and an output schema, the description covers the decision-relevant facts: target object, visibility default, mention consequences, and irreversibility. Nothing an agent needs in order to call it correctly is missing.

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 meaning the schema lacks — the candidate_id/result_id targeting choice and the fact that each mention_profile_ids entry triggers exactly one e-mail. Analytics-only parameters (llm_model, conversation_id) are correctly left to the schema.

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 concrete verb and resource ("Add a note") plus the two possible attachment points (candidate_id or result_id), and the bracketed [Candidates] domain tag orients it among 70+ siblings. An agent knows immediately what it creates and where the note lands.

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

Usage Guidelines4/5

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

Gives clear context: notes are team-visible by default or private, mentions notify colleagues by e-mail, and notes are immutable through this tool (so the agent knows there is no follow-up edit path). It stops short of explicitly stating when to prefer candidate-level vs result-level notes, leaving the schema to sort that out.

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.