HireJack's MCP server provides tech job market intelligence, enabling you to search jobs, analyze companies, benchmark salaries, and gain career insights. Tools are tiered by access level:
Public Tools (no authentication required)
Search Jobs: Search live tech job postings by keyword, role, seniority, skill, location, salary, remote policy, or visa sponsorship.
Get Job: Fetch full details of a specific job posting (salary, skills, AI summary) by URL or ID.
Get Company Profile: View a company's hiring profile — tech stack, role distribution, seniority breakdown, salary medians, and hiring trends.
Search Companies: List and filter tracked companies by name, domain, or industry with hiring volume stats.
Get Market Pulse: Get a market-wide snapshot — total open jobs, top/trending skills, top hiring companies, and remote share.
Pro Tier Tools
Match Job: Score your fit against a specific job with a multi-dimension breakdown and ATS resume tips.
Company Fit: Score your fit for a company based on tech stack, roles, seniority, and hiring momentum.
Recommendations: Get personalized job recommendations ranked by composite match score.
Salary Benchmark: Compare your salary to market P10–P90 percentiles for a given role and seniority.
Skill Gap: Identify missing skills ranked by frequency in your target roles.
Market Position: Get a 0–100 market position score based on skill demand, seniority fit, and remote availability.
Skill Impact: Simulate learning new skills to see how many jobs and companies they unlock.
Watchlist Intelligence: Aggregate hiring signals (trends, top skills, salary) across all companies you're watching.
Premium Tier Tools
Resume Rewrite: Generate bullet-by-bullet resume rewrites tailored to a specific job posting.
Interview Prep: Get targeted prep materials — key topics, likely questions, and company research items.
Analyst Tier Tools
Get Company History: Monthly time-series of a company's hiring snapshots (job counts, salary, skills, seniority).
Get Skill History: Monthly adoption time-series for a skill, including company mentions and MoM deltas.
Get Market History: Daily or monthly market-wide hiring stats, remote share, and compensation trends.
Compare Companies: Side-by-side hiring comparison of up to 5 companies with monthly trajectory.
Find Companies: Multi-axis segmentation by industry, role family, skills, hiring trend, and job-count range.
Find Breakout Companies: Identify companies with extreme hiring growth exceeding a configurable threshold.
Find Emerging Skills: Discover skills with consistently growing but still low adoption — early market signals.
Find Emerging Roles: Identify roles gaining company adoption or genuinely new titles appearing in the market.
Account & Profile Tools (any authenticated account)
Save/unsave jobs, follow/unfollow companies, track job applications with pipeline status and notes.
List saved jobs, applications, and your watchlist.
View and update your profile preferences (skills, desired roles, salary, remote, seniority) to re-filter recommendations instantly.
Model Context Protocol server that exposes HireJack's tech job market intelligence to MCP-compatible clients (Claude Desktop, Claude Code, Cursor, Cline, etc.) — tech jobs, companies, skills, salaries, hiring trends.
Claude Code:
claude mcp add hirejack -- npx -y @hirejack/mcpClaude Desktop — edit ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"hirejack": {
"command": "npx",
"args": ["-y", "@hirejack/mcp"]
}
}
}Restart Claude Desktop and ask away (see Example prompts).
The npm package uses stdio transport — no auth, runs locally as a subprocess, and the five public tools work out of the box.
claude.ai / Claude Desktop connector (all 31 tools): add
https://hirejack.com/api/mcp as a custom connector (Settings → Connectors →
Add custom connector), sign in with your HireJack account when prompted, and
the full Pro/Premium/Analyst intelligence surface lights up — tier-gated
server-side to your subscription.
Related MCP server: @career-now/mcp
Job search (public, no account):
"Find remote senior backend roles paying $200K+ that sponsor visas"
"What is Stripe currently hiring? Break it down by team."
"Show me staff-level ML jobs in New York with published salary ranges"
"Which companies are hiring Rust engineers right now?"
Market research (public, no account):
"Which fintech companies are scaling hiring fastest this month?"
"What skills are trending in tech right now?"
"Compare the tech stacks of Datadog and Grafana Labs"
"What's the median advertised salary for senior data engineers?"
Career intelligence (Pro/Premium, via the hosted connector):
"Score my fit for this posting and tell me what's missing: hirejack.com/jobs/…"
"Which skill should I learn next to unlock the most jobs?"
"Where does my salary sit vs the market for staff platform engineers?"
"Rewrite my resume bullets for this Anthropic role"
Analyst (historical/segmentation, via the hosted connector):
"Which companies' hiring grew >50% in the last quarter from a real base?"
"Show Nvidia's hiring trajectory over the last 12 months"
"What skills are climbing consistently from a low base — early signals only"
Clients that support MCP prompts (Claude Desktop, Cursor) surface these as slash commands. All four are built only on the tools that work without an account, so they never dead-end on an auth error:
Prompt | Arguments | What it does |
|
| Maps a free-form ask ("remote, $200K+, Rust") onto |
|
| Resolves a name to a domain, pulls the hiring profile, then shows what is open right now. |
|
| Aggregate market picture, optionally narrowed to a role, skill or city. |
|
| What a role actually pays, using only postings that disclose a range. |
The hosted endpoint serves a different, personalized set (career check-ins, interview prep, match-scored role hunts) because those need an authenticated profile.
The server exposes HireJack's controlled vocabulary as MCP resources:
URI | Contents |
| Every skill HireJack extracts, with canonical name, id and category |
| The role taxonomy: titleId, title, family, IC/management track, typical skills |
Read these before filtering. search_jobs.skill substring-matches the
canonical names, so Kubernetes returns jobs while K8s returns none — and
update_preferences.desired_roles expects titleId values from the roles
resource.
Transport | Where | Tools available |
stdio (this package) |
| 5 public tools ( |
HTTP + OAuth 2.1 (HireJack-hosted) |
| All 31 tools, including Pro+/Analyst intelligence and account actions tied to a HireJack subscription. Implementation lives in HireJack's private Lambda; this OSS package is the stdio half. |
Public (no auth required):
Tool | Purpose |
| Search live tech job postings: role family, seniority, skill, location, salary, remote, visa, education, experience |
| Fetch one job posting by domain + jobId or HireJack URL: full details, salary, skills, AI summary |
| Full hiring profile for one company (tech stack, trends, salary, AI brief) |
| List tracked companies, filter by industry |
| Market-wide stats: totals, top skills, trending skills, top companies |
Pro tier (requires authenticated HireJack user with pro or higher):
Tool | Purpose |
| Score how well the user matches a specific job (matchPct + 5-dim breakdown + ATS tips) |
| Score the user's fit for a company (fitScore + tech-stack/role/seniority breakdown) |
| Top jobs ranked by composite match against the user's profile |
| Percentile + career-ladder benchmark vs the live market for a role/seniority |
| Compare user skills to desired-roles' market requirements; ranked missing skills |
| 0–100 market-position score (skill demand, seniority fit, remote, breadth) + matching jobs, salary median, top-aligned companies |
| Simulate learning each missing skill: jobs unlocked, boosted matches, companies needing it — ranked by impact |
| Aggregate hiring signals across every watched company: open jobs, week-over-week trend %, top skills, median salary, sparkline |
Premium tier (requires premium):
Tool | Purpose |
| Bullet-by-bullet resume rewrites tailored to a specific job |
| Targeted prep: key topics, likely questions by type, company research items |
Analyst (dedicated Analyst tier — $49/mo founding pricing; free for working journalists in exchange for a linked citation):
Tool | Purpose |
| Per-company time-series: monthly hiring snapshots + wider job-count history |
| Per-skill time-series: companyCount + jobMentions per month with MoM deltas |
| Market-wide time-series: 90 days daily or 24 months monthly |
| Up to 5 companies side-by-side: current state + monthly trajectory |
| Multi-axis segmentation: industry × family × skill × trend × job-count band |
| Companies with extreme hiring growth (% threshold + min size) |
| Skills climbing consistently across the last 3 monthly snapshots from a low base, with a real absolute company-count gain — early signal, not small-base noise (the "what should I learn before everyone else" tool) |
| Roles gaining company adoption over a tunable window (default 21 days, daily rollup) plus genuinely new titles the classifier just started seeing — the role-level companion to |
Account & profile (any authenticated HireJack account — reads and writes on the user's own data):
Tool | Purpose |
| Save a job to (or remove it from) the user's saved-jobs list |
| Follow (or unfollow) a company — powers watchlist intelligence, alerts, and the weekly digest |
| Track an application through the pipeline: applied → phone_screen → interview → offer / rejected / withdrawn, with notes |
| List the user's saved jobs (read companion to |
| List tracked applications with their pipeline stage (read companion to |
| List watched companies (read companion to |
| Read the user's profile: skills, desired roles, tier, and the matching preferences (seniority, city, remote, US-only, minimum salary) that hard-filter recommendations and alerts |
| Update matching preferences from the conversation — minimum salary, require-listed-salary, remote / US-only, seniority, city — persists to the profile and re-filters everything immediately |
Unlike the website's toggle endpoints, these use explicit, idempotent
actions (state is checked first), so an agent retrying a "save" can never
silently unsave. The write tools (save_job, watch_company,
track_application, update_preferences) are annotated readOnlyHint: false so MCP clients ask for approval appropriately.
Pro+ tools are thin wrappers over the website's existing intelligence Lambdas. Tier gating happens server-side in those Lambdas — the MCP server just forwards the user's identity. If the user lacks the required tier, the API returns 403 and the tool surfaces a clear upgrade hint.
git clone https://github.com/TVLSS/hirejack-mcp
cd hirejack-mcp
npm install
npm run build # tsc → dist/
node dist/index.js # waits on stdin/stdout for JSON-RPCPublishing is automated by GitHub Actions (.github/workflows/release.yml).
Pushing a version tag builds, publishes to npm, and updates the MCP Registry:
npm version patch # bumps package.json + creates the vX.Y.Z tag
git push && git push --tagsThe workflow verifies the tag matches package.json, then runs npm publish
(using the NPM_TOKEN repo secret) and a best-effort MCP Registry update via
GitHub OIDC. Keep server.json's version in step with package.json.
Env var | Default | Purpose |
|
| Override if you're self-hosting a fork against a different backend |
|
| Used in |
The npm package ships the stdio transport only. The hosted HTTP+OAuth
endpoint at https://hirejack.com/api/mcp is run separately by HireJack
and not implemented in this repo.
src/
├── index.ts # stdio entry point
├── registry.ts # transport-agnostic tool registry
├── prompts.ts # slash commands (public-tool-only by design)
├── resources.ts # controlled vocabulary (skills, roles)
├── lib/
│ ├── api.ts # HireJack REST client
│ ├── format.ts # tool result helpers
│ └── proAuth.ts # Pro+ auth check (returns "use hosted endpoint" in stdio)
└── tools/ # 29 files, 31 registered toolsMIT — see LICENSE.
Issues / feature requests: https://github.com/TVLSS/hirejack-mcp/issues
General feedback: https://hirejack.com/feedback.html
Site / product: https://hirejack.com
Time-series of a company's hiring profile. Analyst tier. Returns monthly snapshots (totalJobs, engineeringJobs, medianSalary, hiringTrend, trendPct, top skills, seniority + family distribution) plus the wider monthlyPostings job-count series and current-state summary. Use for 'how has Anthropic's hiring changed since January?' or 'is Stripe growing or shrinking?'. Not for a current-state snapshot (get_company_profile) or side-by-side comparison (compare_companies).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain (e.g. 'stripe.com') | |
| months | No | Months of history to return (default 12, max 24). Note: detailed monthly snapshots only began March 2026, so depth is currently capped by available history. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Monthly hiring history plus current state for one company |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds context about being 'Analyst tier' and notes that detailed snapshots began March 2026, capping available history. No contradictions. Description adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first packs the return values, second gives usage and exclusions. No unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (time-series with many fields), the description covers key return elements and the main limitation. Output schema exists but not shown; description compensates. Missing edge case handling or error scenarios, but still very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds context about months default and max, and the historical depth limitation starting March 2026. This extra information helps the agent understand parameter constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Time-series of a company's hiring profile.' It lists the specific data returned (monthly snapshots with metrics like totalJobs, engineeringJobs, etc.) and explicitly differentiates from siblings get_company_profile and compare_companies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage examples: 'Use for "how has Anthropic's hiring changed since January?" or "is Stripe growing or shrinking?"' and clearly states when not to use: 'Not for a current-state snapshot (get_company_profile) or side-by-side comparison (compare_companies).'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch HireJack's full hiring profile for a single company by domain. Returns: tech stack (top skills with counts), role distribution, seniority breakdown, location breakdown, hiring trend (% MoM), salary medians where disclosed, and an AI-generated hiring brief. Use this for queries like 'what is Stripe hiring?', 'what tech does Anthropic use?', or before comparing companies. Not for historical trends (get_company_history, Analyst) or the user's personal fit (company_fit).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain (e.g. 'stripe.com', 'anthropic.com'). Use the apex domain, not subdomains. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Full hiring profile for one company; additional aggregate fields may be present |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only behavior is clear. The description adds behavioral context by enumerating the return fields and stating that it returns a comprehensive hiring profile. No contradictions with annotations. Could be higher if it mentioned any potential rate limits or additional side effects, but for a read-only tool the transparency is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the purpose, and contains no filler. Every sentence adds value: purpose, return values, usage examples, and exclusions. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 1 parameter, high schema coverage, and an output schema (which presumably details return structure), the description is sufficiently complete. It specifies what is returned and provides context on when to use the tool. No missing critical information for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'domain' already has a detailed description in the schema (e.g., format example, apex domain note). The tool description does not add additional parameter information; it only mentions 'by domain'. Therefore, baseline 3 is appropriate as the schema covers parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'full hiring profile for a single company by domain'. It lists specific return fields (tech stack, role distribution, etc.) and distinguishes from siblings by referencing alternatives like get_company_history and company_fit. This provides high specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides example queries ('what is Stripe hiring?', 'what tech does Anthropic use?') and states what the tool is NOT for ('Not for historical trends... or the user's personal fit'), naming specific sibling tools. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one job posting by domain + jobId, or by HireJack detail URL. Returns title, company, location, salary, skills, seniority, posted date, visa/remote/education metadata, and (when available) the AI summary. Use after search_jobs when the user picks a specific role to discuss, or when the user pastes a HireJack job URL. Not for browsing or filtering postings (search_jobs) or personal fit scoring (match_job).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full HireJack job detail URL, e.g. 'https://hirejack.com/jobs/stripe.com/sw-eng-12345/'. Convenience alternative to passing `domain` + `jobId` separately. | |
| jobId | No | Job canonical id — pass the `id` field from a `search_jobs` result VERBATIM (it may contain '#' separators, e.g. 'greenhouse#stripe#4921361'; keep them). The dashed URL form also works. Required unless `url` is provided. | |
| domain | No | Company domain (e.g. 'stripe.com'). Required unless `url` is provided. |
| Name | Required | Description |
|---|---|---|
| data | Yes | The job posting (metadata only — description HTML is intentionally omitted; meta.gated marks postings the website would paywall) |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with fetch. Description adds return field details beyond annotations, but no behavioral quirks beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage, exclusions. No redundancy, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with output schema, description covers input modes and return fields adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds limited new meaning. It clarifies the relationship between url, jobId, and domain, and warns about verbatim jobId usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one job posting by domain+jobId or URL, and lists return fields. It distinguishes from siblings like search_jobs and match_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (after search_jobs or when user pastes a URL) and when not to (browsing, personal fit scoring), with sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time-series of market-wide hiring stats: total jobs, remote share, compensation, seniority + family distribution, top skills. Analyst tier. Daily resolution back to early March 2026; monthly resolution from March 2026. Use for 'how has the market shifted in 2026?' or 'is remote hiring trending up?'. Not for the current snapshot — use get_market_pulse for that.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of daily history (1-90, default 30). Only used when range='daily'; ignored for range='monthly'. | |
| range | No | Granularity. 'daily' returns up to 90 days back (rich, recent). 'monthly' returns up to 24 months back (coarser, longer view). Defaults to daily. | |
| detail | No | 'compact' (default) returns a slim per-snapshot series (date, jobs, companies, remote share, median comp) plus full distributions for only the first and latest snapshots — enough for trend analysis at ~10x less output. 'full' returns every snapshot's complete distributions (seniority, family, top skills); only use when you need per-date distribution detail. | |
| months | No | Months of monthly history (1-24, default 12). Only used when range='monthly'; ignored for range='daily'. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Market-wide hiring time-series; shape depends on `detail` (compact: series+endpoints, full: snapshots) |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, confirming safe read operation. Description adds behavioral details like data resolution (daily back to early March 2026, monthly from March 2026) and explains the difference between compact and full detail modes. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose and key outputs. Every sentence adds essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, two granularities, two detail modes), the description covers resolution, parameter interactions, and distinguishes from sibling tools. Output schema exists, so return values need not be detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides 100% coverage with detailed parameter descriptions. The description adds value by explaining when parameters are used or ignored based on other parameters (e.g., days ignored when range=monthly), which aids correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns time-series of market-wide hiring stats with specific metrics (total jobs, remote share, compensation, etc.). It distinguishes from siblings like get_market_pulse by explicitly noting it is not for current snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage scenarios: 'how has the market shifted in 2026?' or 'is remote hiring trending up?'. Also clearly states when not to use: for current snapshot, use get_market_pulse instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Time-series of a skill's market adoption. Analyst tier. Returns monthly companyCount + jobMentions for the skill, top companies hiring for it each month, and computed MoM deltas. Use for 'how fast is Rust adoption growing?' or 'is React still dominant?'. Not for discovering early-stage skills you can't yet name — use find_emerging_skills for that.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | Skill name or id (e.g. 'Rust', 'kubernetes', 'Machine Learning'). Aliases resolve via codex/skills.json. | |
| months | No | Months of history to return (1-24, default 12). Monthly snapshots began March 2026, so depth is capped by available history. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Monthly market-adoption history for one skill |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds context about the data granularity (monthly) and computed deltas, and mentions 'Analyst tier' implying access level. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: two sentences plus a use-case statement and a negative instruction. Information is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations, the description covers core purpose, use cases, alternatives, and data details. Minor omission: data start date (March 2026) is in schema but not description. Still largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions. The description adds example values but does not significantly enhance understanding beyond schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides time-series data on a skill's market adoption, listing specific metrics (companyCount, jobMentions, top companies, MoM deltas). It gives concrete example queries and distinguishes from 'find_emerging_skills'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (tracking adoption growth/dominance of known skills) and when not to (for unknown early-stage skills), directing to an alternative tool. Provides example use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate targeted interview prep for a specific job: 5 key topics (deep vs surface depth based on job seniority), 5 likely questions by type (technical, behavioral, system design) with answer tips, and 3 company-specific research items. Premium tier. Uses job description + company tech stack + user skills as context. Use for 'help me prep for my Anthropic interview' or 'what should I expect in this loop?'. Not for resume tailoring — use resume_rewrite for that.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full HireJack job detail URL. Convenience alternative to passing `domain` + `jobId` separately. | |
| jobId | No | Pass the `id` field from a `search_jobs` result VERBATIM — do not reformat (ids may contain '#' separators; keep them). Required unless `url` is provided. | |
| domain | No | Company domain (e.g. 'anthropic.com'). Required unless `url` is provided. |
| Name | Required | Description |
|---|---|---|
| data | Yes | AI interview preparation for one job posting |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description reveals premium tier status, depth variation based on seniority, and context sources (job description, tech stack, user skills), providing rich behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that are front-loaded with purpose. Every sentence adds value: first sentence specifies outputs, second provides usage guidance and sibling distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, output schema existence, and 100% parameter coverage, the description sufficiently covers inputs, outputs, usage, and constraints, leaving no major gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions (url, jobId, domain). The instruction to pass jobId verbatim is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates targeted interview prep with specific outputs (5 key topics, 5 questions, 3 research items) and explicitly distinguishes from the sibling tool `resume_rewrite` by stating it is not for resume tailoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('help me prep for my Anthropic interview') and directly states when not to use the tool ('Not for resume tailoring — use `resume_rewrite` for that'), offering clear guidance and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the authenticated user's market position score (0-100). Pro tier. Weighted: 50% skill demand against current market, 20% seniority fit, 15% remote availability for the user's preference, 15% skill breadth. Returns score, matchingJobs count, salaryMedian for matching roles, per-skill demand breakdown, and the top companies whose tech stacks align best with the user's skills. Use for queries like 'how do I stack up against the market?' or 'what's my market position right now?'. Not for job-specific (match_job) or company-specific (company_fit) scores.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | The authenticated user's overall market position |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true; description adds detailed computation weighting (50% skill demand, etc.) and expected output fields. Does not disclose rate limits or authentication beyond 'Pro tier', but is largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with purpose and weighting, though the weight breakdown could be slightly more succinct. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description fully covers tool functionality, including inputs (none), computation logic, and return fields. Appropriate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Description explains the computation context, which is sufficient for a param-less tool. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it computes a market position score (0-100) with weighted breakdown. Distinguishes from job-specific and company-specific tools, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists example queries and what the tool is not for (job-specific or company-specific scores), providing clear guidance on when to use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate targeted resume bullet rewrites for a specific job, using the user's uploaded resume + the job description as context. Premium tier. Returns before/after bullet rewrites, missing keywords from the JD, and ATS-format tips. The user must have a resume uploaded to HireJack (via Settings or Onboarding). Use for 'rewrite my resume for this Stripe role' or 'tailor my bullets for this JD'. Not for interview preparation — use interview_prep for that.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Full HireJack job detail URL. Convenience alternative to passing `domain` + `jobId` separately. | |
| jobId | No | Pass the `id` field from a `search_jobs` result VERBATIM — do not reformat (the id contains '#' separators; keep them). Always fetch a real id via search_jobs first. Required unless `url` is provided. | |
| domain | No | Company domain (e.g. 'stripe.com'). Required unless `url` is provided. |
| Name | Required | Description |
|---|---|---|
| data | Yes | AI resume rewrite suggestions targeted at one job posting |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it specifies the returns (before/after rewrites, missing keywords, ATS tips), notes it's a premium tier feature, and indicates the resume upload requirement. No contradiction with readOnlyHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, well-structured, and front-loaded. Every sentence adds critical information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and an output schema, the description fully covers input preconditions, output summary, and usage context. It also mentions premium tier and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds extra value by explaining that 'url' is a convenience alternative to 'domain'+'jobId', and that 'jobId' must be passed verbatim from search_jobs with '#' separators.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool generates targeted resume bullet rewrites for a specific job using the user's resume and job description. It clearly distinguishes from sibling tools like interview_prep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage examples ('rewrite my resume for this Stripe role') and explicitly states when not to use it ('Not for interview preparation') with a named alternative (interview_prep). It also mentions the prerequisite of having a resume uploaded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare a salary against the live HireJack market for a role family + seniority slice. Pro tier. Returns precomputed P10/P25/P50/P75/P90 percentiles, the user's percentile ranking (when salary is supplied), and a career-ladder progression of medians by seniority. Use for 'am I paid well as a senior backend engineer?' or 'what should I ask for?'. Not for a specific job's posted range (get_job) or market-wide comp stats (get_market_pulse).
| Name | Required | Description | Default |
|---|---|---|---|
| family | No | Role family to benchmark against. Omit to benchmark against the whole market. | |
| salary | No | User's current annual USD salary. When provided, the response includes the user's percentile ranking within the slice. | |
| seniority | No | Seniority level to benchmark against. Omit to include all seniority levels in the slice. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Salary percentile benchmark for a role family + seniority slice |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds valuable behavioral context: it's Pro tier, returns percentiles, percentile ranking, and career-ladder progression. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the action first, followed by key features and exclusions. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and 3 parameters, the description covers the purpose, output contents, usage guidance, and exclusions comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaning beyond individual parameter docs by explaining how omitting parameters affects the slice (whole market, all seniorities) and that salary enables percentile ranking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares a salary against live market data for a role family and seniority slice. It uses specific verbs and resources, and distinguishes from sibling tools like get_job and get_market_pulse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides use cases ('am I paid well?', 'what should I ask for?') and tells what not to use it for, naming specific alternatives (get_job, get_market_pulse).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search HireJack's database of live tech job postings. Filter by keyword, role family, seniority, skill, location, salary, remote policy, or visa sponsorship. Returns a slim list of jobs with title, company, location, salary range, posted date, and key skills. Use this for queries like 'remote senior backend roles paying $200K+', 'data engineer jobs at fintech companies', 'who is hiring Rust developers in NYC'. Not for a single known posting (get_job), company-level questions (get_company_profile), personalized ranking (recommendations), or aggregate market stats (get_market_pulse).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text keyword search (case-insensitive substring) across raw and standardized title, company name, company domain, and location. Tip: use the `skill` parameter for skill matches — `q` does NOT search job descriptions or the skill list. | |
| visa | No | Visa sponsorship (AI-extracted): 'yes' returns jobs whose posting indicates sponsorship, 'no' those that rule it out. Omit to include jobs where the posting doesn't say. | |
| limit | No | Max results to return (default 25, max 100) | |
| skill | No | Single skill name to require (case-insensitive substring match), e.g. 'Rust' or 'Kubernetes' | |
| cursor | No | Opaque pagination cursor from a previous search_jobs call's `meta.next_cursor`. Pass it back (with the SAME filters) to fetch the next page of results. | |
| family | No | Role family (software_engineering, machine_learning, etc.). Omit to search all families. | |
| remote | No | Remote policy filter; 'remote+hybrid' matches either mode. Omit to include onsite jobs too. | |
| company | No | Company domain to filter by, e.g. 'stripe.com' | |
| location | No | Location substring filter, e.g. 'San Francisco' or 'New York' | |
| education | No | Minimum degree the job requires (AI-extracted). E.g. 'bachelor' returns jobs whose stated requirement is exactly a bachelor's. | |
| seniority | No | Seniority level on the intern → vp ladder. Omit to include all levels. | |
| experience | No | Years-of-experience bucket the job asks for (AI-extracted yearsMin). E.g. '0-2' for entry-level-friendly roles, '10+' for very senior ones. | |
| has_salary | No | Set true to only include jobs with a disclosed salary range; omit to include jobs without pay data. | |
| salary_max | No | Maximum salary ceiling (annual USD). Matches jobs whose floor is at or below this (i.e. salaryMin <= X). | |
| salary_min | No | Minimum salary floor (annual USD). Matches jobs whose disclosed salary range *could pay at least* this much (i.e. salaryMax >= X). A job with range $150K–$250K matches salary_min=200000. | |
| posted_since | No | Only include jobs posted on or after this date (YYYY-MM-DD). E.g. for 'jobs posted this week', pass the date 7 days ago. |
| Name | Required | Description |
|---|---|---|
| data | Yes | Search results page; meta.next_cursor is present when more pages exist |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation (true), the description discloses important behavioral traits: q does not search job descriptions or skill list, pagination via cursor, salary_min/salary_max matching logic, and that results are a slim list with specific fields. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the primary action. It efficiently covers purpose, output, examples, and exclusions. Slightly verbose with comma-separated lists but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and the existence of an output schema, the description adequately covers filtering behavior, return fields, pagination, and edge cases (e.g., salary range matching, q not searching descriptions). It leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant meaning: explains q's scope limitations, clarifies salary_min and salary_max semantics with examples, describes cursor usage, and provides usage tips for skill and posted_since parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches HireJack's database of live tech job postings, lists filterable attributes, and describes the returned data format. It also explicitly distinguishes from sibling tools like get_job, get_company_profile, recommendations, and get_market_pulse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (for searching tech jobs with various filters) and when not to use it (for single job, company profile, recommendations, market stats). Also gives example queries to illustrate appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze the gap between the authenticated user's current skills and what their desired roles require in the live market. Pro tier. Returns matchPct (0-100), the list of skills the user already has that map to their target roles, and the list of missing skills ranked by impact (how often the skill appears in target-role postings). Use for 'what should I learn next?' or 'how close am I to senior PM roles?'. Not for simulating the payoff of skills the user might LEARN — use skill_impact for that.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | Gap between the user's skills and their desired roles' requirements |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: explains return values (matchPct, map of skills, missing skills ranked by impact). Annotations already indicate readOnlyHint, and description does not contradict it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff: first sentence states purpose, second details outputs, third gives usage guidelines. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters and output schema present, the description fully explains what the tool returns and when to use it. Sibling tools provide context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined, so schema coverage is 100% vacuously. Baseline for 0 params is 4; description has no need to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes the gap between the authenticated user's current skills and desired role requirements in the live market. It uses a specific verb ('Analyze') and resource ('gap'), and distinguishes from sibling tool 'skill_impact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides use cases ('what should I learn next?', 'how close am I to senior PM roles?') and tells when NOT to use it ('Not for simulating...'), directing to alternative 'skill_impact'. Also mentions 'Pro tier' as context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For each skill the authenticated user does NOT have, simulate adding it and compute the market impact. Pro tier. Returns a ranked list of skills with: newJobsUnlocked (jobs that previously didn't match but would after learning the skill), boostedJobs (existing matches that would score higher), companiesNeedingIt, relevantRoles, and a composite impactScore. Also returns profileCompleteness so the caller can suggest filling missing profile fields. Use for queries like 'what should I learn next?' or 'which skill would unlock the most jobs for me?'. Not for auditing the user's CURRENT skills against their target roles — use skill_gap for that.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | Simulated market impact of skills the user could learn |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false; the description adds that it is a simulation (no actual skill addition) and lists output fields. No contradictions, and adds meaningful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, output details, usage guidance. Front-loaded and every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, an output schema exists, and sibling tools are listed, the description covers purpose, usage, output structure, and distinguishes from related tools. Complete for an agent to decide when and how to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0 params), so baseline is 4. The description does not need to add parameter information and appropriately focuses on behavior and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates adding each missing skill and computes market impact, returning a ranked list. It explicitly distinguishes from sibling 'skill_gap' by noting it's not for auditing current skills.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('what should I learn next?', 'which skill would unlock the most jobs?') and a clear when-not-to-use ('not for auditing... use skill_gap'), naming the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate hiring intelligence on every company the authenticated user is watching. Pro tier. For each watched company returns: totalJobs currently open, hiringTrend (up/down/stable), trendPct (week-over-week %), topSkills the company is hiring for, medianSalary, sparkline data (last ~12 weeks of job counts), and jobDelta since the previous snapshot. Use for queries like 'what's happening at the companies I'm watching?' or 'which of my watched companies are scaling up right now?'. Not for a plain list of watched companies — use list_watchlist for that.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| data | Yes | Hiring intelligence for every company on the user's watchlist |
| meta | No | Request/response metadata (pagination cursors, snapshot timestamps, applied filters) |
| citation_url | No | hirejack.com URL to cite when surfacing this result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true; the description adds valuable context about Pro tier requirement and details the returned fields (hiringTrend, trendPct, etc.) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (few sentences), front-loaded with purpose, then return fields, then usage guidelines. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description fully covers purpose, usage, return values, and constraints (Pro tier), making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, so the description correctly focuses on the output and usage. The 0-param baseline is 4, and the description adds no unnecessary param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('aggregate') and resource ('hiring intelligence on watched companies'), clearly distinguishing from sibling 'list_watchlist' which returns a plain list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides example queries for when to use the tool and specifically states when not to use it, naming the alternative tool (list_watchlist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose, with explicit 'Not for' clauses in descriptions to prevent confusion. For example, get_company_history and get_company_profile are cleanly separated by time-series vs. snapshot, and skill_gap vs. skill_impact are precisely differentiated.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_company_history, search_jobs, skill_impact). The naming convention is uniform and predictable across the entire set of 13 tools.
With 13 tools, the server covers a comprehensive hiring intelligence domain without being excessive. Each tool serves a distinct function, and the count falls well within the ideal 3-15 range for a well-scoped server.
The tool set covers most major use cases for a hiring intelligence platform, including job search, company profiles, market history, skill analysis, interview prep, resume rewriting, and salary benchmarking. Minor gaps exist, such as the missing get_market_pulse and list_watchlist tools referenced in descriptions, but the overall coverage is strong.
Job platform for AI agents. Track tech jobs from companies that match your stack.
Search job postings, companies, and technology stacks across 10M+ companies.
AI job search for Claude, ChatGPT, Cursor. 170K+ jobs, 3,800+ companies. OAuth or stdio.
Search a live index of millions of open jobs from employer career sites and 100+ ATS platforms.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TVLSS/hirejack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
