Selenios

Update job position

update_job_description

DestructiveIdempotent

Update an existing job position. Only the fields passed are modified. Arrays such as evaluationCriteria and technicalRequirements replace the existing list entirely: a criterion left out is deleted, and each criterion keeps its isKnockout, extraWeight, visibleInCareerSite and usedForScreening flags only if they are sent again (a criterion sent without them loses its knockout or extra weight and is published on the public career site). Changing the criteria does not re-score candidates: existing scores reflect the previous criteria until a recalculation runs. HTML fields are sanitized server-side. The open/paused/closed/cancelled status is not changed here.

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": {
      "jobDescriptionId": "<jobDescriptionId>"
    },
    "name": "update_job_description"
  }
}

Input Schema

Name	Required	Description
`title`	No
`videoUrl`	No
`locations`	No	Replaces the full list of job locations. Give the place only — the work modality belongs in modalityOfWork. A country on its own is accepted and published at that country's main city.
`department`	No
`companyName`	No
`salaryRange`	No
`targetHires`	No
`jobDescription`	No
`modalityOfWork`	No
`jobDescriptionId`	Yes	The job position ID
`timeToFillTarget`	No
`companyDescription`	No
`evaluationCriteria`	No	Replaces the full list of evaluation criteria: a criterion you omit is DELETED. Send every criterion the position should keep, each with its isKnockout, extraWeight, visibleInCareerSite and usedForScreening flags exactly as you read them — a criterion re-sent without them loses its knockout or extra weight and gets published on the public career site. Changing this list does not re-score anyone: every existing score keeps reflecting the old criteria until a recalculation runs.
`technicalRequirements`	No	Replaces the full list of legacy technical requirements. Same shape, flags and delete-by-omission rule as evaluationCriteria, except extraWeight, which is not kept here: put a requirement that weighs extra in evaluationCriteria.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, but the description adds the operationally critical behavior annotations cannot express: array replacement deletes omitted items, omitted flags silently lose knockout/extraWeight status and get published publicly, scores are not recalculated, and HTML is sanitized server-side. That is exactly the data-loss context an agent needs before calling a destructive patch.

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 contract, then the destructive details, then the caveat about scoring; no filler sentences. It partially restates the evaluationCriteria/technicalRequirements schema descriptions, which is mild redundancy, but justified given how costly getting those arrays wrong is.

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 14-parameter destructive nested-object mutation with no output schema, the description covers the main failure modes: silent deletions, flag loss, stale scores, sanitization, and status exclusion. It omits permission/scope requirements and whether updating salaryRange replaces the whole object, which is the remaining meaningful gap.

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 only 29% across 14 parameters, so the description carries real weight here, and it does explain the two highest-risk arrays (evaluationCriteria, technicalRequirements) including the replace-by-omission rule and flag retention. The other ten-plus parameters (salaryRange nesting, targetHires, timeToFillTarget, videoUrl, locations, modalityOfWork) get no meaning from the description at all, leaving the coverage gap only partly compensated.

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+resource ('Update an existing job position') plus patch semantics ('Only the fields passed are modified'). It also carves out what it does NOT do ('The open/paused/closed/cancelled status is not changed here'), which separates it from change_job_status and create_job_description without opening either schema.

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 description establishes clear when-to-use context: partial update, with an explicit exclusion for status changes and a warning that criteria edits don't re-score candidates (pointing at recalculate_job_scores implicitly). It stops short of naming those sibling tools explicitly, so the agent must infer the redirect.

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

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

Resources

Need Help?