Skip to main content
Glama
Sign In

JobMojito

by com.jobmojito
OverviewDiscussionsAdmin

Create, change or archive a reason

save_reason
Destructive

[Reasons] Without reason_id: a new reason (decision: kind and label; position_status: label and applies_to). With reason_id: change it; fields left out keep their value; status archived stops offering it, active offers it again (an archived position status reason cannot be restored). Company-wide: a renamed reason is renamed on every past decision too. Owners only.

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": {
      "type": "<type>"
    },
    "name": "save_reason"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoDecision reasons: reject or withdraw. Required for a new one; it cannot change later.
typeYesdecision (why a candidate was rejected or withdrew) or position_status (why a position went on hold, was cancelled, closed or filled).
labelNoThe reason, 1 to 120 characters. Required for a new one; left out on a change, it stays.
statusNoarchived: no longer offered; past decisions and lifecycle changes keep it. active: offered again (decision reasons only: an archived position status reason cannot be restored).
llm_modelNoYour model id, e.g. "claude-opus-4-8"; "unknown" if unsure. For analytics.
reason_idNoThe reason to change (from list_reasons). Left out: a new reason is created.
applies_toNoPosition status reasons: the lifecycles it can be given for (on_hold, cancelled, closed, filled). Required for a new one; left out on a change, it stays.
sort_orderNoPosition in the list (lower first). Left out: the end of the list for a new reason, unchanged otherwise.
merchant_idNoOptional company to act on. Admins and sub-merchant operators only; other callers always use their token's company.
translationsNoDecision reasons: the label per two-letter language code, e.g. {"de": "Zu wenig Erfahrung"}. Replaces the stored translations; left out on a change, they stay.
conversation_idNoThe 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.

Output Schema

NameRequiredDescriptionDefault
resultYes
_mcp_instructionsNoServer-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations it discloses the two side effects that matter most for a destructive write: omitted fields retain their value on a change, and a renamed reason is renamed on every past decision company-wide. It also warns that archiving hides the reason from future selection while historical decisions keep it, and flags the irreversible archived-position-status case, which is consistent with destructiveHint=true and idempotentHint=false. A little more on what the response returns or whether partial failures roll back would round it out.

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?

It is a single dense paragraph that front-loads the create/change/archive split before the edge cases, and closes with a pointer to get_tool_reference for full arguments. The shorthand ('decision: kind and label; position_status: label and applies_to') is efficient, though it reads slightly telegraphic on a first pass.

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 an 11-parameter destructive mutation with an output schema, the description covers the missing pieces the structured data cannot: mode semantics, partial-update behavior, company-wide propagation to historical decisions, irreversibility, and the owner-only restriction. Nothing an agent needs in order to call it safely is absent.

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 still adds value by grouping conditional requirements by type – decision needs kind and label, position_status needs label and applies_to – in one place rather than requiring the agent to stitch that together from per-property text. It does not explain merchant_id scoping or the analytics-only llm_model/conversation_id fields, but those are already documented in 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?

The description names the resource [Reasons] and splits the operation into two explicit modes keyed on reason_id: create when absent, modify when present, plus status-driven archiving. That distinguishes it cleanly from read-only siblings such as get_reason and list_reasons, and the 'decision' vs 'position_status' split is stated up front.

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?

Mode selection is spelled out precisely: no reason_id creates, reason_id changes, status=archived retires the reason and status=active reactivates it. It also states the one-way case (an archived position status reason cannot be restored) and the 'Owners only' prerequisite, which routes callers away if they lack permission. It does not explicitly say to call list_reasons or get_reason first to obtain an id, leaving that inference to the schema.

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

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