Save a job
save_jobBookmark a vacancy for the user. Idempotent.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The vacancy's public_slug. |
save_jobBookmark a vacancy for the user. Idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The vacancy's public_slug. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral claim, 'Idempotent', merely restates idempotentHint=true from the annotations and earns no credit. With readOnlyHint=false declared, mutation behavior is in scope, yet the description says nothing about what gets created, what happens when the job is already saved, or permission requirements. The annotations cover the safety profile, so this is not a contradiction, but the description adds essentially nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clipped sentences with zero filler and the primary action front-loaded. It is efficient, though the brevity edges toward under-specification rather than crisp completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, non-destructive bookmark tool with rich annotations and no output schema, the description is borderline sufficient. It omits the relationship to unsave_job and track_job and gives no indication of what the response confirms, leaving small but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the sole slug parameter is documented as the vacancy's public_slug, so the schema already carries the semantics. The description adds no extra detail about slug format, where to obtain it, or error behavior for unknown slugs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Bookmark') and resource ('a vacancy'), so the agent knows this creates a saved-job association. It doesn't explicitly name the inverse sibling unsave_job, but the purpose is unambiguous without reading the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given: it does not mention how this differs from track_job, apply_job, or unsave_job, nor any preconditions such as whether the job must exist or the user must be authenticated. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.