Openings

Optimize a resume for one job

optimize_resume

Read-onlyIdempotent

Propose a revision of a resume for one specific job, as suggestions, a unified diff or revised markdown. It rewrites emphasis and wording only: the original is never overwritten and no claim the resume does not already support is added. Use it after analyze_job_fit has shown which gaps are real. The resume is parsed in memory for this call and never stored.

Input Schema

TableJSON Schema

Name	Required	Description
`jobId`	Yes	Stable job id from search_jobs or recommend_jobs
`output`	Yes	suggestions lists changes to consider; unified_diff shows them as a patch; revised_markdown returns the rewritten resume
`resume`	Yes	The resume itself, passed inline. It is parsed in memory for this call and never written to disk, logged, or sent anywhere else.

Output Schema

TableJSON Schema

Name	Required	Description
`job`	No	The job the revision targets
`gaps`	No	What the resume cannot honestly claim, and so was left alone
`output`	Yes	Which form was produced
`content`	No	The diff or rewritten resume, when that form was asked for
`profile`	No
`suggestions`	Yes	Each proposed change with the evidence behind it
`originalOverwritten`	Yes	Always false: the candidate's resume is never modified in place

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 22, 2026

addedInput schema / properties / jobId / description

Added value: +"Stable job id from search_jobs or recommend_jobs"

addedInput schema / properties / output / description

Added value: +"suggestions lists changes to consider; unified_diff shows them as a patch; revised_markdown returns the rewritten resume"

addedInput schema / properties / resume / description

Added value: +"The resume itself, passed inline. It is parsed in memory for this call and never written to disk, logged, or sent anywhere else."

addedInput schema / properties / resume / properties / format / description

Added value: +"How content is encoded: plain text, markdown, or base64 of a PDF or DOCX file"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "content": {
+      "description": "The diff or rewritten resume, when that form was asked for",
+      "type": "string"
+    },
+    "gaps": {
+      "description": "What the resume cannot honestly claim, and so was left alone",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "job": {
+      "additionalProperties": true,
+      "description": "The job the revision targets",
+      "properties": {
+        "age": {
+          "description": "Bucketed posting age; undated means the board gave no date, not that the role is fresh",
+          "enum": [
+            "new",
+            "older",
+            "stale",
+            "undated"
+          ],
+          "type": "string"
+        },
+        "company": {
+          "type": "string"
+        },
+        "eligibleCountries": {
+          "description": "Two-letter codes the role is open to",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "experience": {
+          "additionalProperties": true,
+          "description": "Years the posting itself states as { min, max }; null when it states none, absent when the description was not read",
+          "type": [
+            "object",
+            "null"
+          ]
+        },
+        "id": {
+          "description": "Stable id to pass to get_job, analyze_job_fit or optimize_resume",
+          "type": "string"
+        },
+        "location": {
+          "type": "string"
+        },
+        "postedDaysAgo": {
+          "type": "number"
+        },
+        "remote": {
+          "type": "boolean"
+        },
+        "title": {
+          "type": "string"
+        },
+        "updatedAt": {
+          "description": "When the board says the role was posted or last updated; absent when the board states none",
+          "type": "string"
+        },
+        "url": {
+          "description": "The employer's own posting, which is where an application is made",
+          "type": "string"
+        },
+        "workMode": {
+          "enum": [
+            "remote",
+            "hybrid",
+            "onsite",
+            "unknown"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "originalOverwritten": {
+      "description": "Always false: the candidate's resume is never modified in place",
+      "type": "boolean"
+    },
+    "output": {
+      "description": "Which form was produced",
+      "enum": [
+        "suggestions",
+        "unified_diff",
+        "revised_markdown"
+      ],
+      "type": "string"
+    },
+    "profile": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "suggestions": {
+      "description": "Each proposed change with the evidence behind it",
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "output",
+    "suggestions",
+    "originalOverwritten"
+  ],
+  "type": "object"
+}

First observedSep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate read-only, idempotent, non-destructive. The description reinforces this by stating the original is never overwritten and adds crucial context: the resume is parsed in memory, never stored, and no new claims are added, which is important for trust and privacy.

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?

Concise, two sentences, front-loads the main action and alternative outputs, then clarifies scope and privacy. Every sentence provides valuable information without fluff.

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 output schema exists, the description doesn't need to explain return values, but it describes the input format, security, and usage context. It is complete for an agent to call correctly: what, when, and constraints are all clear.

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?

The schema covers all parameters with clear descriptions (e.g., jobId, output enum, resume structure). The description adds some context by explaining that output formats are for consideration vs. patch vs. revised markdown, but this is beyond schema. Since coverage is 100%, baseline is 3; the description adds marginal value but not fully necessary.

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 clearly states it proposes a revision of a resume for a specific job, and specifies three output formats. It distinguishes itself from siblings like analyze_job_fit by focusing on revision rather than analysis, and from search_jobs/recommend_jobs by being a post-analysis action.

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?

Explicitly states to use after analyze_job_fit has shown real gaps, giving clear sequencing. It also mentions that it only rewrites emphasis and wording, not adding unsupported claims, which guides when to use it.

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

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