Job Application Agent MCP Server

request_approval

Requests user approval in the UI for draft cover letter actions like mark_ready or export, ensuring human consent before finalizing or sharing.

Instructions

Ask the user to approve an action on a draft. You cannot approve it yourself.

    Args:
        action: "mark_ready" (the letter is final; drafts are already queued for
            this) or "export" (give the user the text; only after mark_ready was
            approved). Sending, emailing or applying is never possible and will
            be refused.
        draft_id: The `draft_id` returned by draft_cover_letter.

    The request waits for the user's decision in the UI. Do not ask again
    and do not wait for it: finish your answer and tell the user.

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": {
      "action": "<action>",
      "draft_id": "<draft_id>"
    },
    "name": "request_approval"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes
`draft_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden and does so well: it discloses that the request waits for the user's decision in the UI, that the agent must not block on it, and that out-of-scope actions are refused. It stops short of describing failure modes (invalid draft_id, already-approved states) or any permission/lifecycle constraints.

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

Conciseness4/5

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

Front-loaded with the purpose before the args breakdown, and every clause (refusal semantics, don't-wait instruction) earns its place. The indented 'Args:' block is slightly verbose for a two-parameter tool but remains scannable.

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

Completeness4/5

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

For an asynchronous approval-flow tool with no annotations, the description covers the critical unknowns: what each action does, ordering constraints, and agent behavior while awaiting a decision. An output schema exists so return values need not be explained; only error/edge-case behavior is left unstated.

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 coverage is 0% (only titles 'Action' and 'Draft Id'), yet the description fully compensates: it enumerates the two valid `action` values and their ordering conditions, and names the source of `draft_id` (returned by draft_cover_letter). This adds substantial meaning the schema does not carry.

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+resource: 'Ask the user to approve an action on a draft.' The follow-up 'You cannot approve it yourself' clarifies boundaries and the draft_id reference to draft_cover_letter anchors it in the workflow, though it does not explicitly contrast with the other siblings (search_jobs, read_cv, score_match).

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 documents both allowed actions with their preconditions ('mark_ready' – drafts already queued for this; 'export' – only after mark_ready was approved), plus hard exclusions ('Sending, emailing or applying is never possible and will be refused'). It also gives procedural guidance to not re-ask and not wait, leaving nothing to inference.

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

Deploy Server