Skip to main content
Glama

Resume Booster Job Board

Request an application

request_application
DestructiveIdempotent

Ask the board's apply agent to submit an application to this job on behalf of the key's owner. Needs an account key (mint one at https://resumebooster.work/agents), an active Agent plan OR a live Agent Pass on the account, and a mandate set in Account — call key_status first: it says which of the three is missing, and on a pass how many applications and how much time are left. On a pass, only a job the agent can submit itself (agentReady true, which check_apply_support reports) uses an application; any other job is refused and nothing is spent. On the Agent plan nothing is counted, and such a job is prepared for the person to send. Every application passes the same gates as the signed-in flow, including the honesty classifier: answers are drawn from the owner's own profile and never invented. Ask the person for a yes on this specific job id before calling. Needs a key or a sign-in.

Input Schema

NameRequiredDescriptionDefault
noteNoOptional note stored with the request (not sent to the employer).
jobIdYesThe job id from search_jobs.

Output Schema

NameRequiredDescriptionDefault
fixNoRefused only: what would change the answer.
noteNo
errorNoRefused only: what the gate said.
jobIdNo
titleNo
fitPctNoKeyword fit of the résumé on file to this posting, 0-100; null when the posting has no text to score.
companyNo
warningNoAccepted but flagged: below the release floor, or a system the agent prepares for rather than submits to.
acceptedYesFalse when a gate refused; true when the request is in the agent's queue (or already was).
refusedByNoRefused only: the gate — key, jobId, mandate, resume, plan (no Agent plan and no live pass), pass (the pass has no applications left or its clock ended), posting, scope-country, scope-category, scope-age, scope-salary.
queueStatusNoWith alreadyQueued: the existing row's status.
alreadyQueuedNoAccepted only: this job was already in the queue — nothing duplicated, and on a pass nothing spent.
whatHappensNextNo
passApplicationsLeftNoAccepted on a pass: applications left on it after this one. Null when a subscription funded the request.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag this as destructive, non-read-only, idempotent, and open-world; the description adds crucial context: on a pass, only agentReady jobs consume an application, otherwise refused with nothing spent; on Agent plan, nothing is counted and the job is prepared for manual sending; all applications pass the same gates including an honesty classifier and answers are drawn from the owner's own profile. This exceeds annotation disclosure and clarifies side effects and billing behavior.

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?

The description is dense but well-structured: it front-loads the action, then preconditions, then behavioral details. It contains necessary details but is somewhat lengthy; every sentence has purpose, though some could be tightened without losing clarity.

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?

With an output schema present, return values needn't be explained. The description covers prerequisites, sibling dependencies (key_status, check_apply_support), consent requirement, billing/refusal behavior, and honesty constraints – everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so both parameters are documented. The description adds that the job must be one the agent can submit itself (agentReady true, which check_apply_support reports) and reinforces that consent must be for this specific job id, which adds meaning beyond the schema's 'job id from search_jobs.' The note parameter is not elaborated in the description, but the schema covers it adequately.

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 ('submit an application to this job') and actor ('on behalf of the key's owner'), clearly differentiating from siblings like check_apply_support (readiness check) and application_status (tracking). An agent knows exactly what this tool does.

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 provides explicit preconditions (account key, active plan or pass, mandate) and directs to key_status first and check_apply_support for agentReady. It also states a consent requirement: 'Ask the person for a yes on this specific job id before calling.' The when-to-use and prerequisites are fully spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.