JobMojito

Create or change a task

save_task

Destructive

[Tasks] Without task_id: create a task (title, notes, due date, assignee, about a candidate, application or position: a new task needs one of candidate_id, application_id or position_id). With task_id: change the fields you send, or the status (done, cancelled; a cancelled task stays cancelled). Assigning a task to someone else e-mails them (assignee_notified); assignee_profile_id comes from list_users. due_at is a date and time with the offset of the user's time zone. Hiring managers are read only.

Every argument in full, with examples: get_tool_reference.

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

Input Schema

Name	Required	Description
`notes`	No	Notes, at most 4000 characters. An empty string (or null) removes them; left out keeps them.
`title`	No	Title, 1 to 200 characters. Required to create.
`due_at`	No	Due date and time (ISO 8601 with offset). An empty string (or null) removes it; left out keeps it.
`status`	No	open, done or cancelled. Cancelled is final: a cancelled task cannot be changed or reopened.
`task_id`	No	The task to change (a task `id`, from list_tasks).
`llm_model`	No	Your model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
`merchant_id`	No	Optional company to act on. Admins and sub-merchant operators only; other callers always use their token's company.
`position_id`	No	Create only: the position (a position `id` from list_interviews) or interview (an interview `id` from list_interviews) the task is about.
`candidate_id`	No	Create only: the candidate the task is about (the `id` of a list_candidates row).
`application_id`	No	Create only: one application of the candidate (an application `id` from get_candidate); the candidate is taken from it.
`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.
`assignee_profile_id`	No	Who does it (`profile_id` (list_users) of an active user of the company who can see the candidate or position). Required to create.

Output Schema

Name	Required	Description
`status`	Yes
`created`	Yes
`task_id`	Yes
`_mcp_instructions`	No	Server-issued metadata for this conversation.
`assignee_notified`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 9, 2026

changedInput schema / properties / application_id / description

Previous value: -"Create only: one application of the candidate (position_result.id); the candidate is taken from it."New value: +"Create only: one application of the candidate (an application `id` from get_candidate); the candidate is taken from it."

changedInput schema / properties / assignee_profile_id / description

Previous value: -"Who does it (profile.id of an active user of the company who can see the candidate or position). Required to create."New value: +"Who does it (`profile_id` (list_users) of an active user of the company who can see the candidate or position). Required to create."

changedInput schema / properties / candidate_id / description

Previous value: -"Create only: the candidate the task is about (profile_interview.id)."New value: +"Create only: the candidate the task is about (the `id` of a list_candidates row)."

changedInput schema / properties / position_id / description

Previous value: -"Create only: the position (position_def_set.id) or interview (interview_def_set.id) the task is about."New value: +"Create only: the position (a position `id` from list_interviews) or interview (an interview `id` from list_interviews) the task is about."

changedInput schema / properties / task_id / description

Previous value: -"The task to change (merchant_task.id, from list_tasks)."New value: +"The task to change (a task `id`, from list_tasks)."

Changed7 schema fields changedNov 9, 2026

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 / status / description

Previous value: -"open, done or cancelled. Cancelled is final: a cancelled task cannot be changed or reopened. Applied after the other changes."New value: +"open, done or cancelled. Cancelled is final: a cancelled task cannot be changed or reopened."

changedInput schema / properties / task_id / description

Previous value: -"The task to change (merchant_task.id, from list_tasks). Leave out to create a task."New value: +"The task to change (merchant_task.id, from list_tasks)."

removedOutput schema / properties / assignee_notified / description

Removed value: -"true when the assignee was e-mailed \"task assigned\": a new task, or a new assignee, given to someone other than you."

removedOutput schema / properties / created / description

Removed value: -"true when this call created the task."

removedOutput schema / properties / status / description
```
Removed value: -"The task status after the call."
```
removedOutput schema / properties / task_id / description
```
Removed value: -"The task (merchant_task.id)."
```

AddedNov 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, non-idempotent and open-world, so the bar is lower, yet the description still adds real behavior: assigning to someone else triggers an e-mail (assignee_notified), cancellation is final and cannot be reopened, and due_at must carry the user's time-zone offset. What it doesn't add is any note on partial-update semantics beyond 'change the fields you send', though the schema covers field-level clearing.

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 most decision-relevant split (no task_id vs with task_id) is front-loaded in the first sentence, and the trailing pointer to get_tool_reference keeps the body short instead of enumerating every argument. The parenthetical stacking makes it dense, but essentially every clause carries a rule an agent needs.

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 12-parameter, 0-required create/update tool with an output schema available, the description covers the branches, creation preconditions, status semantics and permission limit. The analytics-only fields (llm_model, conversation_id) and merchant_id scoping are left to the schema, which is reasonable since the schema documents them fully.

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 a baseline of 3 is warranted, but the description genuinely adds meaning: the create-time requirement of exactly one of candidate_id/application_id/position_id, the origin of assignee_profile_id (list_users), and the timezone-offset rule for due_at. Those points go beyond the per-field schema text rather than restating it.

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?

The description states a specific verb and resource and immediately splits the tool into its two modes: no task_id means create, task_id means change. The required shape of a new task (one of candidate_id, application_id or position_id) is spelled out, so an agent knows exactly what this does relative to list_tasks and the other write tools.

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?

The create-vs-update branch is explicit, and the description routes ID sourcing to the right siblings (assignee_profile_id from list_users, application_id from get_candidate). It also states a real constraint agents would otherwise hit: hiring managers are read only, and a cancelled task stays cancelled. It stops short of naming an explicit alternative tool or a when-not-to-use case, so it lands just below the top.

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.