Skip to main content
Glama
satovarb16

runwayMCP

by satovarb16
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_job

Retrieve a specific job record by id, URL, or custom title, with optional full description and linked resume summaries. Handles ambiguous matches by returning all matching IDs.

Instructions

Retrieve a single job record by id, url, or custom_title (D6, the REQUIRED read path for jd_text — without this tool, jd_text is write-only).

custom_title exists as a lookup key because it exists as a SAVE affordance: a job saved without a url is findable ONLY by the custom_title the user agreed to (analyze.py's _NO_URL_NOTICE promises exactly this). Without this parameter, that promise had no retrieval path at all — a caller could only dump every job via list_jobs and eyeball it.

custom_title is NOT unique (save_job_analysis deliberately never matches an existing record by it — R3/SC-08), so a lookup CAN match more than one job. Silently returning the first match would hide that ambiguity from the caller and could resolve to the wrong job. Instead: 0 matches -> not_found; exactly 1 -> that job; more than 1 -> error="ambiguous", naming every matching id so the caller can retry with a specific id.

has_description is ALWAYS present in the response, regardless of include_description — it is the affordance that makes the jd_text opt-in discoverable without dragging JD text into context by default. Also returns the linked resume version SUMMARIES (no content) — the headline query is "did I apply to X?" -> "yes, and with this resume." (SC-22). The full text still comes from get_resume_version.

This tool NEVER raises.

Args: id: Job id. Exactly one of id/url/custom_title must be given. url: Alternate lookup key (url is UNIQUE). custom_title: Alternate lookup key for a URL-less job. NOT unique — see above for the multi-match rule. include_description: When True and a description was captured, populates description with the full pasted JD text. Defaults to False so a routine status check does not drag JD text into context.

Returns: GetJobResult with success=True, job, description, has_description, resume_versions on success; success=False with error="not_found" | "invalid_input" | "corrupt" | "ambiguous" on failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNo
urlNo
custom_titleNo
include_descriptionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobNo
errorNo
messageNo
successYes
descriptionNo
has_descriptionNo
resume_versionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • addedOutput schema / $defs / StoredJob / properties / status_notes
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Status Notes"
+}
  2. Addedv0.3.1

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral burden. It discloses that the tool NEVER raises, specifies exact outcomes for 0/1/many matches, explains the ambiguous error behavior, and notes that has_description is always present. This is exemplary transparency.

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 front-loaded with the core purpose, and each subsequent paragraph earns its place by explaining non-obvious behavior or hazards. There is no filler or redundant restatement of the schema.

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 moderate complexity and the absence of annotations, the description is complete: it covers lookup keys, matching semantics, error values, default behavior, return contents, and integration with sibling tools. The output schema can supply the remaining structural field details.

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%, but the description compensates thoroughly. It explains the meaning and uniqueness of each lookup key, the 'exactly one' constraint, the multi-match risk of custom_title, and the default behavior of include_description. This goes far 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 first sentence states a specific verb, resource, and scope: 'Retrieve a single job record by id, url, or custom_title.' This clearly distinguishes it from list_jobs and other siblings and immediately establishes the tool's lookup keys.

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?

The description explicitly positions the tool as the 'REQUIRED read path for jd_text,' explains when id versus custom_title is appropriate, and contrasts with list_jobs for dumping records. It also names get_resume_version as the source for full resume text, giving alternatives and conditions.

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

Deploy Server

Other Tools