Skip to main content
Glama
Sign In
freehire

freehire

by strelov1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

market_fit

Read-only

Score a skill list against live open-vacancy market data for a target role to measure headline coverage, must-have skills held, and missing skills that unlock the most jobs.

Instructions

Score a skill list against the live open-vacancy market for a filtered role: headline coverage (% of vacancies listing ≥1 skill), must-have skills held, and the missing skills that unlock the most vacancies. Here skills is the MEASURED set, not a filter — use facet params to define the role. One skill probes that skill's demand. A result wrapped as {data, ignored, ignored_values} measured something other than what was asked: fix the named param or value and retry before quoting it.

Input Schema

NameRequiredDescriptionDefault
cityNoCity slugs. ORs with region and country.
roleNoRole facet values, e.g. senior_backend.
visaNoOnly jobs offering visa sponsorship.
facetsNoAny other facet param as key→value(s), e.g. {"source": "greenhouse"}. Discover valid keys and values with the `facets` tool.
regionNoRegion codes: global|ru|cis|central_asia|eu|us. WIDENS with country/city — region+country means 'in the region OR the country', not 'the country inside the region'. To search one country, pass country and OMIT region.
remoteNoOnly remote jobs (sets work_mode=remote).
skillsYesThe candidate's skills to measure (canonical slugs). One value probes a single skill.
companyNoCompany slugs.
countryNoISO-3166 country codes, e.g. BR, US. Omit `region` when narrowing to a country — the two OR together, so region+country returns everything the region alone would.
categoryNoRole categories: backend|frontend|fullstack|devops|ml_ai|qa|...
seniorityNoSeniority: intern|junior|middle|senior|staff|principal|lead|c_level.
salary_minNoMinimum salary (enrichment.salary_min).
english_levelNoEnglish level, e.g. a2, b1, b2, c1.
exclude_skillNoSkills to filter OUT, e.g. python — drops jobs TAGGED with any of them. Tags come from a curated dictionary read off the description, so this is a discovery filter, not a fit test: a mention the dictionary does not recognise leaves the job untagged and in the results, and a job whose real core is a stack the candidate lacks is not removed by excluding a different one. Any other facet excludes the same way through `facets`, e.g. {"company_type_exclude": "outstaff"}.
employment_typeNoEmployment type, e.g. full_time, contract.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.8.0
    • changedInput schema / properties / city / description
      Previous value: -"City slugs."New value: +"City slugs. ORs with region and country."
    • changedInput schema / properties / country / description
      Previous value: -"ISO-3166 country codes, e.g. BR, US."New value: +"ISO-3166 country codes, e.g. BR, US. Omit `region` when narrowing to a country — the two OR together, so region+country returns everything the region alone would."
    • addedInput schema / properties / exclude_skill
      Added value: +{
+  "description": "Skills to filter OUT, e.g. python — drops jobs TAGGED with any of them. Tags come from a curated dictionary read off the description, so this is a discovery filter, not a fit test: a mention the dictionary does not recognise leaves the job untagged and in the results, and a job whose real core is a stack the candidate lacks is not removed by excluding a different one. Any other facet excludes the same way through `facets`, e.g. {\"company_type_exclude\": \"outstaff\"}.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / region / description
      Previous value: -"Region codes (OR within): global|ru|cis|central_asia|eu|us."New value: +"Region codes: global|ru|cis|central_asia|eu|us. WIDENS with country/city — region+country means 'in the region OR the country', not 'the country inside the region'. To search one country, pass country and OMIT region."
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With readOnlyHint already covering the safety profile, the description adds genuinely non-obvious behavior: the {data, ignored, ignored_values} wrapper signals a mismatch between what was asked and what was measured, and the agent is told to fix the param and retry before quoting results. That is exactly the kind of silent-failure disclosure annotations cannot provide.

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 the purpose and outputs, then the measurement-vs-filter rule, then the result-wrapper caveat — every sentence earns its place. The final sentence is terse and slightly cryptic ('measured something other than what was asked'), which costs a point on structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter tool with a nested facets object and no output schema, the description compensates well by naming the three return components and the measurement semantics. It stops short of covering result limits, skill-list size expectations, or how coverage is computed, leaving minor gaps.

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; the description still adds real meaning by clarifying that `skills` is measured rather than filtered and that a single skill value probes that skill's demand, plus a one-skill probe use case. It doesn't add anything for the 14 facet params beyond what the schema says, so it doesn't reach 5.

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 and resource ('Score a skill list against the live open-vacancy market') plus the exact outputs produced (headline coverage, must-have skills held, missing skills unlocked). It also draws the crucial line between measuring and filtering, which is what separates it from search-style siblings.

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?

Explicitly tells the agent that `skills` is the MEASURED set and that facet params define the role, and routes to the `facets` tool for discovering valid keys. It lacks an explicit 'use X instead when' against adjacent siblings like job_market_stats or salary_stats, so it gets a 4 rather than a 5.

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