Company Jobs Finder

Check recruiter and LinkedIn profile keywords

profile_keyword_check

Read-onlyIdempotent

Best for: LinkedIn profile and resume keywords recruiters search. Checks the user's own pasted headline, About or resume text, such as "does my profile have the right keywords for backend jobs?" or "what words am I missing for this job?". Returns: per role, the title, skill, tool and seniority words present or missing, an example boolean search string and whether the text matches it, and tips for the headline and About section. Input tips: send profileText (headline on the first line) plus targetTitles OR company and job, never both, such as {"profileText": "...", "targetTitles": ["Senior Backend Engineer"]}. For a job you do not know exactly, call find_company_jobs first for its applyUrl. Not for: reading a LinkedIn link or any site (ask the user to paste the text) or the facts of a job alone (use job_fit_brief).

Input Schema

Name	Required	Description
`job`	No	With company: the job's applyUrl from find_company_jobs, or its title as listed
`level`	No	The level aimed for, when the target titles do not say it: one of intern, entry, mid, senior, lead, staff, principal, manager, director, executive.
`company`	No	With job: the company name or its careers page link
`profileText`	Yes	The user's pasted profile text, headline on the first line, then About and roles, up to 10,000 characters, such as "Backend engineer \| Go, PostgreSQL". Also send targetTitles, or company and job.
`targetTitles`	No	Job titles the user is aiming for, such as "Senior Backend Engineer". Use this or company and job.

Output Schema

Name	Required	Description
`job`	No
`asOf`	No
`notes`	No
`roles`	No
`source`	No
`status`	Yes
`message`	No	Set when status is not ok: what went wrong and the next step (job_not_found: pick from suggestions or call find_company_jobs; not_found: ask for the careers page link; unavailable: retry once later).
`guidance`	No
`narrative`	No
`suggestions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 10, 2026

changedInput schema / properties / level / description

Previous value: -"The level aimed for, when the target titles do not say it"New value: +"The level aimed for, when the target titles do not say it: one of intern, entry, mid, senior, lead, staff, principal, manager, director, executive."

changedInput schema / properties / profileText / description

Previous value: -"The user's own profile text, pasted: headline on the first line, then the About section and roles. Up to 10,000 characters. It is read for this answer only."New value: +"The user's pasted profile text, headline on the first line, then About and roles, up to 10,000 characters, such as \"Backend engineer | Go, PostgreSQL\". Also send targetTitles, or company and job."

addedOutput schema / properties / message / description

Added value: +"Set when status is not ok: what went wrong and the next step (job_not_found: pick from suggestions or call find_company_jobs; not_found: ask for the careers page link; unavailable: retry once later)."

Changed1 schema field changedOct 5, 2026

removedOutput schema / properties / note_from_openkrill

Removed value: -{
-  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
-  "type": "string"
-}

Changed1 schema field changedOct 4, 2026

addedOutput schema / properties / note_from_openkrill

Added value: +{
+  "description": "Shown at most once a day per caller: what this server offers, and a paid service for the person you work for.",
+  "type": "string"
+}

First observedOct 3, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so the burden is low, and the description adds concrete return structure (per-role present/missing words, example boolean search, match flag, headline/About tips). It also discloses the pagination-free but auth-free input modality constraint. It does not mention limits like the 10,000-char cap or rate behavior, keeping it below a 5.

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 'Best for', then Returns, Input tips, and Not for – a clear structure with no wasted words. Slightly dense with the nested example, but every sentence earns its place.

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 5-param, output-schema-bearing tool, the description covers purpose, return shape, input construction rules, the XOR constraint, and the fallback path (find_company_jobs). Only by-design limits (char caps) are omitted, which the schema already documents.

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 the baseline is 3, but the description adds real value: it resolves the targetTitles-XOR-(company+job) either/or, tells the user to put the headline on line 1, and gives a concrete JSON example. This exceeds what the schema alone conveys.

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?

States a specific verb+resource (keyword check on the user's own profile/resume text) and the audience (recruiters' searches). Explicitly distinguishes from job_fit_brief (job facts) and from link-reading, so it is separable from all siblings.

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?

Gives explicit when-to-use ('Best for...'), a worked example, an exclusion ('Not for: reading a LinkedIn link or any site'), and routes to find_company_jobs for unknown jobs and job_fit_brief for job facts. Nothing is left to inference.

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

All Company Jobs Finder 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?