keywordise

Apply to my matching jobs

start_apply_run

Destructive

Use when the person says 'apply for me', 'apply to the best matches' or 'apply to this job' (pass job_id). Show them the jobs first. Start an application run: Keywordise takes up to limit of the matching jobs (same filters as list_matching_jobs, best fit first, never one already applied to), tailors the CV and cover letter for each, answers the employer's screening questions from the saved answers, and SUBMITS inside the employer's own system. Real applications leave in the person's name; needs a confirmed email and an active plan; counts against the plan. dry_run=true does everything except submit. Poll get_apply_run_status.

Input Schema

TableJSON Schema

Name	Required	Description
`fresh`	No	Freshness window; defaults to the account's saved filter.
`limit`	No
`match`	No	Match tier to draw from; defaults to the account's saved filter.
`job_id`	No	Apply to exactly this ONE job (an id from list_matching_jobs) instead of a filtered batch — the same run, scoped to it. limit/match/fresh are ignored when set.
`dry_run`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

addedInput schema / properties / job_id

Added value: +{
+  "description": "Apply to exactly this ONE job (an id from list_matching_jobs) instead of a filtered batch — the same run, scoped to it. limit/match/fresh are ignored when set.",
+  "type": "string"
+}

First observedSep 1, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark destructiveHint=true, but the description adds critical behavioral details: real applications leave in the person's name, require a confirmed email and active plan, consume plan quota, and actually submit inside the employer's system. It also discloses the dry_run safety valve and the 'never one already applied to' guard.

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?

Though long, every sentence earns its place. It front-loads usage triggers, then flows through prerequisites, process, side effects, and follow-up. No fluff or redundancy; the density is justified by the action's complexity.

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?

Without an output schema, the description fully explains the action's scope, prerequisites, side effects, and next step (poll get_apply_run_status). It also covers edge cases like single-job scoping and dry-run. An agent has everything needed to invoke correctly.

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 only 60%, so the description compensates heavily. It explains job_id semantics (ignores other filters), dry_run (everything except submit), and limit (up to N matching jobs, best fit first). It also ties fresh/match to the account's saved filters.

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 action (start an application run), the resource (matching jobs), and the outcome (tailored CVs, cover letters, screening answers, submissions). It clearly distinguishes itself from siblings like list_matching_jobs (listing) and get_apply_run_status (polling), and explains the job_id scoping for single-job applications.

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 lists trigger phrases ('apply for me', 'apply to the best matches', 'apply to this job'), mandates showing jobs first, and instructs to poll get_apply_run_status afterwards. It contrasts with list_matching_jobs by referencing the same filters and clarifies when to use job_id vs. batch mode.

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

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

Resources

Need Help?