runwayMCP

Overview Schema Source Related Servers Discussions Admin

delete_job

Permanently remove a wrongly entered, duplicate, or test job record by ID or URL. Unlinks resume versions instead of deleting them, then returns a receipt confirming exactly what was removed.

Instructions

Permanently delete a stored job record, by id or url.

For a record that should never have existed: a mistyped entry, a posting that turned out to be a duplicate, test data. This is NOT the same thing as the withdrawn status, which says "I pulled out of this process" — a real event worth keeping. Conflating the two poisons every later query, because a withdrawn job still counts as a job you looked at.

Lookup is by id or url ONLY — deliberately not custom_title, which get_job does accept. custom_title is not unique (save_job_analysis never matches on it), and deleting by an ambiguous key is precisely how the wrong record gets destroyed. Ambiguity is survivable on a read; here it is not.

What happens to everything pointing at the job:

job_descriptions row: deleted. The captured posting belongs to the job and has no meaning without it.
resume_versions: NOT deleted — job_id is set to NULL. The tree is append-only and stays that way: a tailored resume is a document you really sent, and it survives the posting it was aimed at. Only the pointer dies, which is why the append-only UPDATE trigger guards every column EXCEPT job_id.

There is no confirmation flag and no undo. The returned receipt names the job and every resume version that was unlinked, so the caller can report exactly what disappeared — with no delete_job there is no way back, the receipt is the safety mechanism.

This tool NEVER raises.

Args: id: Job id (preferred — always resolvable, unlike url). url: Alternate lookup key when id is not known.

Returns: DeleteJobResult with success=True and the receipt on success; success=False with error="invalid_input" (neither key given), "not_found", "corrupt", or "write_error".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`url`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`url`	No
`error`	No
`title`	No
`company`	No
`message`	No
`success`	Yes
`deleted_description`	No
`unlinked_resume_versions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.0Sep 19, 2026

TDQS

A5/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses permanence (no undo, no confirmation flag), cascading effects (job_descriptions deleted, resume_versions unlinked with job_id set to NULL), the append-only trigger nuance, that it never raises, and the exact return structure with error codes. This is exceptionally transparent.

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?

The description is long but every sentence serves a purpose. It is front-loaded with the core action, then usage, then behavioral details, then parameters and return. Bulleted lists and clear section breaks make it scannable. The length is justified by the complexity of the delete operation and its cascading effects.

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?

Given the tool's destructive nature, the description covers everything an agent needs: purpose, when to use, what gets deleted vs. unlinked, no-undo warning, the receipt as a safety mechanism, and all possible error returns. It also distinguishes from siblings and the `withdrawn` status, making it complete for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains both parameters: id is 'preferred — always resolvable, unlike url' and url is 'Alternate lookup key when id is not known.' It also explains why custom_title is not a valid parameter, adding crucial semantic context beyond the bare 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 states a specific verb and resource ('Permanently delete a stored job record, by id or url') and explicitly differentiates itself from the `withdrawn` status and from get_job, which accepts custom_title. This makes the purpose unambiguous and distinguishes it from siblings.

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

Usage Guidelines5/5

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

It clearly defines when to use the tool ('For a record that should never have existed: a mistyped entry, a posting that turned out to be a duplicate, test data'), explicitly contrasts with the `withdrawn` status, and explains why custom_title is deliberately excluded. It also notes that it is not the same as get_job, giving the agent clear routing guidance.

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

Deploy Server