Selenios

Create job position

create_job_description

Create a new job position. Automatically generates a default interview plan if none is provided, schedules embedding generation for AI matching, and optionally seeds a screening template. The job description and company description fields accept basic HTML (bold, italic, lists) and are sanitized server-side.

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": {
      "title": "<title>",
      "jobDescription": "<jobDescription>",
      "companyName": "<companyName>",
      "companyDescription": "<companyDescription>",
      "locations": "<locations>",
      "evaluationCriteria": "<evaluationCriteria>"
    },
    "name": "create_job_description"
  }
}

Input Schema

Name	Required	Description
`title`	Yes	Job title
`locale`	No	Locale for the default interview plan (default: "es")
`locations`	Yes	Job locations (at least one, required). 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. A place the organization's location catalog does not have yet is added to it, so it can be picked for the next job position.
`department`	No	Department
`companyName`	Yes	Hiring company name
`salaryRange`	No	Salary range
`jobDescription`	Yes	Job description (supports basic HTML: <p>, <strong>, <em>, <ul>, <ol>, <li>)
`modalityOfWork`	No	Work modality
`companyDescription`	Yes	Company description (supports basic HTML)
`evaluationCriteria`	Yes	Evaluation criteria used to assess candidates (at least one required). Every criterion is evaluated in the score; each can be shown to candidates (visibleInCareerSite), and a mustHave one can be a knockout (isKnockout) and can weigh extra (extraWeight, on at most half of the mustHave ones, knockouts included).
`technicalRequirements`	No	Legacy technical requirements, same shape and visibility flags 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

A3.5/5.0

Behavior4/5

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

Annotations only give the generic safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely new behavior: auto-generated default interview plan, scheduled embedding generation for AI matching, optional screening template seeding, and server-side HTML sanitization. It stops short of saying what is returned on failure or whether any of these side effects are deferrable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all substantive and front-loaded: purpose first, side effects second, input-format caveat last. No filler and no repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, nested-object creation tool with no output schema, the description covers the important hidden behaviors but omits what the call returns (job ID?) and any preconditions or validation-failure behavior. Given the tool's complexity, an agent still has meaningful unknowns after reading it.

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%, so the baseline is 3; the description adds HTML-format meaning for jobDescription/companyDescription beyond the terse schema notes. However it never mentions the required evaluationCriteria array or the six required fields, leaving the richest semantic constraints (knockout/extraWeight rules) entirely to 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?

States a specific verb and resource ("Create a new job position") with clear scope, and the side-effect sentences confirm this is the creation entry point. It does not explicitly distinguish itself from siblings like update_job_description or generate_job_draft, so an agent must infer the boundary from names alone.

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

Usage Guidelines2/5

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

There is no explicit when-to-use / when-not-to-use guidance and no routing to alternatives such as generate_job_draft (for drafting) or update_job_description (for edits). The only conditional hint is "if none is provided" regarding the interview plan, which is incidental rather than instructional.

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?