Skip to main content
Glama
gzchenhao

OpenHire — Real Job Postings, Ghost Jobs Scored

by gzchenhao
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Authorize application

authorize_application

Record explicit authorization to apply for a job without sharing a résumé or personal data; returns the employer's own application URL to submit directly.

Instructions

Record an authorized, employer-direct application. REFUSES résumés.

(Formerly apply — renamed to make explicit that this only records the user's authorization to apply as themselves; it never submits anything on their behalf.)

This tool never accepts a résumé, file, cover letter, name, email or phone — a résumé never transits the server. It only takes a job_id, an anonymous fingerprint, and an explicit per-job authorization. On success it returns the apply_channel (the employer's own application URL) for the user to submit as themselves, plus resume_transmitted=false. Do NOT paste résumé content into any argument.

REFUSES means refuses: any argument this tool does not declare (a resume key, a cv, a file, anything) is answered with ERR_PII_NOT_ACCEPTED and nothing is recorded. It is not silently dropped, so a client that sends one finds out.

Args: job_id: the job to apply to (from search_jobs / check_watches). fingerprint: the user's anonymous fingerprint. authorized: must be true — explicit per-job consent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
authorizedYes
fingerprintYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.6/5.0
Behavior5/5

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

The description goes far beyond annotations: it discloses that undeclared arguments are refused with ERR_PII_NOT_ACCEPTED, nothing is recorded on refusal, a résumé never transits the server, and success returns resume_transmitted=false. These are critical behavioral details for an AI agent and are not visible from annotations or schema.

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 core behavior and refusal rule are front-loaded, and the structure uses bold and line breaks effectively. Some redundancy exists around the résumé refusal and the rename history, but the emphasis is justified for a privacy-sensitive tool.

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?

For a side-effectful tool with no output schema, the description covers success returns, refusal behavior, parameter sources, and PII constraints. An agent has enough information to invoke it correctly and avoid dangerous misuse.

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 0%, but the description compensates by explaining job_id as coming from search_jobs/check_watches, fingerprint as anonymous, and authorized as a mandatory true consent flag. It could add more detail on how to obtain or format the fingerprint, but it covers the essential meaning.

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 and resource: it records an authorized, employer-direct application and explicitly says it never submits anything on the user's behalf. This clearly distinguishes it from submission-like actions and from siblings such as watch_intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear behavioral boundaries: use it only to record authorization, never to attach files, and direct the user to submit via the returned apply_channel. It does not explicitly name sibling tools or state when not to use it, but the context is strong enough to guide selection.

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