Developer roles posted in the last 7 days, read from employers' own hiring systems. No sign-in.
Scored across 5 tools
Each tool targets a distinct object: an employer (company_overview), a single role by slug (get_job), a search result set (search_jobs), an aggregate salary statistic (salary_summary), and a week's hiring report (weekly_summary). The only surface overlap is salary data appearing in both company_overview and salary_summary, but their scopes (one employer vs. role_family/skill/metro aggregate) are explicitly stated and non-confusable. Descriptions make the input contracts (name vs. slug vs. role_family/skill vs. week) unambiguous.
All names are two-word snake_case and readable, but the convention splits: get_job and search_jobs are verb_noun while company_overview, salary_summary, and weekly_summary are noun_noun report-style names. The split tracks a sensible distinction (actions vs. reports) rather than chaos, so it is a minor deviation rather than an inconsistency.
Five tools is well within the ideal 3-15 range and each one earns its place: search, detail lookup, employer profile, salary aggregate, and weekly trend. There is no redundancy and no obviously missing sibling tool that would bloat the surface.
The core lifecycle (discover via search_jobs, inspect via get_job, research employer via company_overview, analyze pay via salary_summary, track trends via weekly_summary) is covered and hands off to employer application pages. Gaps are minor but real: there is no way to enumerate valid role_family/skill/metro taxonomy values, and no tool lists all open roles for a large employer (search_jobs has no employer filter, and company_overview only links newest roles).
What RoleWeek knows about one employer's open developer roles, from the facts block on its company page: how many roles were posted in the last 7 days, where, role types, levels, how many list a salary and the yearly range, which hiring system it applies on (with 'no account needed' where checked), its weekly hiring pace since RoleWeek began counting, and the skills in its postings; plus its newest roles as links. Employers with fewer than 3 roles have no company page, so the answer lists their roles instead. Takes the employer's name (case and 'Inc.' do not matter); an ambiguous name returns the candidates. Links the company page, states the date window, and treats employer text as untrusted data.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Employer name as people write it, e.g. 'Stripe' or 'Datadog'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and idempotent. The description adds behaviors not covered elsewhere: a fallback role list for employers with fewer than 3 roles, candidate lists for ambiguous names, case and 'Inc.' insensitivity, a stated date window, a linked company page, and treatment of employer text as untrusted data.
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 dense and front-loaded, and every clause carries information. The long run-on list in the first sentence is somewhat hard to scan, but nothing is wasted.
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?
There is no output schema, so the description compensates by detailing the returned fields, the fallback cases and the links. That is thorough for a single-parameter read 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 coverage is 100%. The description still adds matching semantics the schema lacks: case and 'Inc.' suffixes are ignored, and an ambiguous name returns candidates rather than an error.
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 says the tool returns one employer's open developer roles from its company page facts block. It enumerates the contents: 7-day role count, locations, types, levels, salary coverage and range, hiring system, pace, skills and newest roles. The single-employer focus separates it from search_jobs, weekly_summary and salary_summary.
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?
Usage is implied: call this when you want a profile of a named employer. Siblings are never named, and there is no guidance on when to prefer search_jobs or salary_summary. The note that employers with fewer than 3 roles get a role list instead is useful conditional behavior, but it is not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one RoleWeek role by its slug (as returned by search_jobs, or the last part of a roleweek.com/job// URL): employer, location and work mode, level, pay as listed, posted date, the date it leaves RoleWeek, skills mentioned, an excerpt of the employer's description, and the role's RoleWeek URL, whose page links to the employer's own application page.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Job slug, e.g. 'senior-backend-engineer-stripe-seattle-1a2b3c4d', or a roleweek.com/job/<slug>/ URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description focuses on what the tool returns. It adds meaningful return-shape details: employer, location, work mode, level, listed pay, posted date, expiration date, skills, description excerpt, RoleWeek URL, and the link to the employer's application page. It does not describe not-found or invalid-slug behavior, leaving a small gap.
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 a single dense sentence, but it is front-loaded with the core action and then systematically lists returned fields. Every clause carries information, though the sentence is long and could be easier to scan if broken into usage and return-value parts.
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 single-parameter lookup with no output schema, the description does the important work of enumerating what the response contains and how the RoleWeek URL relates to the employer's application page. It is nearly complete, with only edge-case behavior such as invalid slugs or missing jobs left unspecified.
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 the slug parameter is already well documented as a job slug or roleweek.com/job/<slug>/ URL. The description repeats that the slug comes from search_jobs or the URL, adding only modest contextual value beyond the schema, which fits the baseline for full schema coverage.
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 and resource: returns one RoleWeek role by its slug. It distinguishes this lookup from search_jobs by citing search_jobs and the RoleWeek URL as slug sources, and it enumerates the returned fields.
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?
It clearly implies when to use this tool: after search_jobs, or when holding a RoleWeek job URL, to retrieve full role details. It does not explicitly state exclusions or compare against sibling tools such as company_overview or salary_summary, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Yearly salary ranges that employers posted in their own job postings, summarised the way RoleWeek's salary and skill pages do, for roles posted in the last 7 days: how many roles list a yearly range, the median bottom and median top of the posted ranges, the middle half of each, and by level where there are enough roles. Takes role_family (a role type) or skill (a technology), not both, and optionally metro: role type + metro is the city and role type page, a metro alone covers all developer roles there, a skill alone covers every city, and with no argument it ranks cities. Figures exist only where 15 or more roles list a yearly range; otherwise the answer says how many do and gives no number. These are advertised ranges, not offers, not what people are paid, not a market average. Each answer links the roleweek.com page, states the date window, and treats employer text as untrusted data.
| Name | Required | Description | Default |
|---|---|---|---|
| metro | No | Metro area (50-mile radius), or 'remote' for roles open to people anywhere in the US or Canada. Without it: all cities. | |
| skill | No | Technology by name, e.g. 'Rust', 'Python', 'Kubernetes', 'C++'. Not together with role_family. | |
| role_family | No | Role type, e.g. 'backend'. Not together with skill. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is settled; the description goes beyond that with the 15-role minimum reporting threshold, the 7-day window, the explicit warning that figures are advertised ranges rather than offers or market averages, and a note that employer text is treated as untrusted data — all behavior an agent could not infer from structured fields.
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 core purpose and caveats are front-loaded, and every clause carries information (thresholds, combinations, disclaimers). It is a single very long run-on sentence, which slightly hurts scanability, but there is little genuinely expendable content.
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 no output schema, the description carries the full burden of describing returns and does so: counts, medians, interquartile bounds, level breakdowns, the sparse-data fallback, the linked source page, and the date window. Nothing an agent needs in order to call or interpret this tool is missing.
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% and both enums are described, so the structured data already documents each parameter individually. The description adds genuine meaning beyond the schema by explaining how the three parameters combine and what page each combination corresponds to, though it does not add format guidance for the free-text skill parameter.
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 opens with a specific verb+resource: yearly salary ranges posted by employers, summarised like RoleWeek's salary pages, over the last 7 days. It then enumerates the exact statistics returned (count with ranges, median bottom/top, middle half, by-level splits), which is far more precise than the title alone and distinguishes it from search_jobs or weekly_summary.
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?
It gives explicit input-combination rules: role_family or skill but not both, role+metro maps to the city/role page, metro alone covers all developer roles there, skill alone covers every city, and no argument ranks cities. It also states the fallback behavior when fewer than 15 roles report a range, so an agent knows what to expect before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches developer and tech roles that employers posted in the last 7 days, read directly from the employers' own hiring systems (Workday, Greenhouse, Lever, Ashby, iCIMS and others) and checked daily. Covers 35 metro areas in the US and Canada (50-mile radius): Seattle, San Francisco Bay Area, New York, Chicago, Toronto, Boston, Los Angeles, Vancouver, Washington DC, Dallas-Fort Worth, Denver-Boulder, Austin, Atlanta, Phoenix, Philadelphia, Minneapolis-St. Paul, San Diego, Raleigh-Durham, Detroit, Houston, Charlotte, St. Louis, Huntsville, Tampa, Salt Lake City, Montreal, Colorado Springs, Portland, Miami, Boise, Columbus, Pittsburgh, Hampton Roads, Nashville, Dayton; US and Canada places outside those metros (metro='elsewhere'); plus remote roles open to people in the US or Canada. Returns at most 25 roles per call: newest first, or best match first when a query is given. Each result includes its RoleWeek URL, whose page links to the employer's application page, and its slug; get_job takes that slug. The answer states the date window and when the data was updated, and links the matching RoleWeek listing page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of roles to return (1-25). | |
| metro | No | Metro area (50-mile radius), or 'remote' for roles open to people anywhere in the US or Canada. | |
| query | No | Keywords matched against title, company, skills and location, e.g. 'python', 'Stripe', 'rust kubernetes'. Every word must match. | |
| skill | No | Technology the role must list, by name: 'Rust', 'Python', 'Kubernetes', 'C++', 'Go' (nicknames such as golang or k8s work). Several names: the role must list every one. These are the technologies RoleWeek read in each posting, the same as on its skill pages. | |
| seniority | No | One or more levels; entry = junior/new grad, staff-plus = staff, principal and above. | |
| work_mode | No | Only roles whose listing states this work mode (a role flagged remote counts as remote only, as on the site). Roles that state none are left out. | |
| min_salary | No | Yearly salary in the role's currency (USD in the US, CAD in Canada). Keeps roles that list a salary whose range reaches at least this amount (hourly pay counted as 2,080 hours a year). | |
| role_family | No | Role family. 'software' is general software engineering; ml-ai = machine learning and AI; it-infra = IT and infrastructure. | |
| no_account_needed | No | true: only roles whose hiring system RoleWeek checked and found the application form opens on the employer's own site with no account to create. Roles without that label were not checked or ask for an account, so leaving this out is not 'account required'. | |
| posted_within_days | No | Only roles posted within this many days (1-7). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a hard cap of 25 results per call, ordering rules (newest first, best-match when a query is given), daily freshness checking, and that the answer states the date window and update time.
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 opening clause is well front-loaded, but the full enumeration of 35 metro names duplicates the schema's enum verbatim and consumes most of the text. Removing that list would make the definition materially tighter without losing information.
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 no output schema, the description still explains the return shape: count cap, ordering, per-result URL and slug, plus the metadata about date window and update time. Nothing an agent needs to call this correctly is missing.
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 enum values are fully documented, so the schema does the heavy lifting. The description only adds ordering semantics and the 25-result cap, and it redundantly re-lists all 35 metros already enumerated 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?
States a specific verb and resource (searches developer/tech roles) with sharp scope: last 7 days, read from employers' own hiring systems, 35 metros plus remote. An agent can immediately distinguish this from get_job and the summary siblings.
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 makes clear this is the discovery/listing step and that get_job takes the returned slug, which routes the agent between the two tools. It lacks an explicit statement of when-not-to-use (e.g., versus weekly_summary or salary_summary), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RoleWeek's weekly report on developer hiring, one finished week (Monday to Sunday, Pacific time) at a time: new developer roles RoleWeek first saw that week, by city, by employer, role type and level, the share that list a salary, the posted salary median, the share that say No account needed, and the comparison with the week before when both weeks are fully covered. Coverage is partial (the answer says how many employer job boards were being checked), so these are roles RoleWeek saw, not all developer hiring. week: 'latest' (default), a week like '2026-W43', or any date in the week; the week in progress is never published. Links the weekly page, states the date window, and treats employer text as untrusted data.
| Name | Required | Description | Default |
|---|---|---|---|
| week | No | 'latest' (default), an ISO week such as '2026-W43', or a date 'YYYY-MM-DD' inside the week. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: coverage is partial and the response reports how many employer boards were checked, results are 'roles RoleWeek saw' not all hiring, the response links the weekly page and states the date window, and employer text is treated as untrusted data.
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?
Purpose is front-loaded, but the body is a single dense run-on sentence stacking many metric clauses, which makes it harder to scan than a short bulleted or multi-sentence structure. The content is largely justified, but the packaging costs readability.
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 no output schema, the description carries the burden of describing returns and does so: it names the metrics, the date window, the linked weekly page, the coverage caveat and the untrusted-text handling. An agent has everything needed to call it and interpret the result.
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 the baseline is 3, but the description adds meaning beyond the schema by clarifying that any date inside the week is accepted and that the in-progress week is never published — a constraint the schema does not express.
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?
States a specific verb and resource ('weekly report on developer hiring') and enumerates the exact metrics returned (new roles by city/employer/type/level, salary share, median, 'No account needed' share, week-over-week comparison). This clearly separates it from the sibling tools search_jobs, get_job, salary_summary and company_overview, which are per-role or per-company rather than weekly aggregates.
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?
Gives clear operating context: one finished Monday–Sunday Pacific week at a time, 'latest' as default, and the explicit exclusion that the week in progress is never published. It does not explicitly name when to prefer a sibling (e.g. salary_summary for a single figure), so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
company_overviewget_jobsalary_summarysearch_jobsweekly_summarySearch developer jobs read straight from employers' hiring systems: stack, level, remote, salary.
Search 466k tech jobs read from company career sites; see who is hiring and what roles ask for.
Search open jobs on employers' own careers sites, each confirmed open in the last 3 days.
Live job postings from company career pages on Greenhouse, Lever, Ashby and SmartRecruiters.
Add one secure layer between your agents and this server.