ScrubShifts Healthcare Jobs

Name: ScrubShifts Healthcare Jobs
Author: stableotto

Server Details

Live US nursing and allied-health jobs, updated daily. Search by place, role, shift, pay.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over the last 24 hours
Last Tested: 2026-11-09 07:16
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: stableotto/nurseboard
GitHub Stars: 0
ChatGPT: –
Claude: –

TDQS

A4.1/5.0

Scored 2026-11-05 19:45 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct step: search_jobs finds listings, get_job expands one listing, list_filters enumerates valid search parameters, and get_pay_benchmarks provides market pay context. There is no realistic way to confuse these purposes, and the descriptions explicitly cross-reference one another (get_job requires a job from search_jobs, list_filters feeds search_jobs).

Naming Consistency5/5

All four names follow a consistent snake_case verb_noun pattern: search_jobs, get_job, list_filters, get_pay_benchmarks. The verbs are used semantically correctly (search for discovery, get for single-resource retrieval, list for enumeration).

Tool Count5/5

Four tools is a tight, well-scoped surface for a job-discovery server, and each tool covers a necessary stage of the workflow (filter discovery, search, detail, pay context). Nothing appears redundant or missing at the count level.

Completeness4/5

The discovery lifecycle is well covered: find jobs, inspect a job, learn valid filters, and benchmark pay, with apply_url handing off to the employer. Minor gaps exist around saved searches/alerts or employer/company-level lookup, but agents can work around them via the provided apply links.

Available Tools

4 tools

get_jobGet job detailsA

Read-only

Inspect

Full details for one job from search_jobs: description text, requirements, pay, apply link and similar jobs.

Name	Required	Description	Default
`id`	Yes	Job id from search_jobs results.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's main added value is disclosing the returned payload fields. That is genuinely useful given there is no output schema, though it says nothing about missing/expired jobs or how 'similar jobs' are populated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the core action and then the payload contents; no filler or redundancy.

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 single-parameter read tool with annotations and no output schema, the description covers the essential contract by naming the fields returned. It is close to complete, though it omits error behavior for unknown ids.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Single parameter with 100% schema description coverage, so the schema already documents that 'id' is a job id from search_jobs results. The description's 'from search_jobs' merely echoes the schema, adding no format or validation detail. Baseline 3 applies.

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 ('full details for one job') and enumerates the returned payload (description, requirements, pay, apply link, similar jobs). It also anchors the tool against its sibling by naming search_jobs as the source of the job id.

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?

'from search_jobs' communicates the prerequisite workflow — get an id from search_jobs, then call this for the detail view — which effectively distinguishes it from the sibling. No explicit when-not guidance or mention of the other siblings, but the context is clear.

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

get_pay_benchmarksGet pay benchmarksA

Read-only

Inspect

Typical posted hourly pay (25th percentile, median, 75th percentile) for a healthcare role nationally and, optionally, in a state, metro or specialty. Use it to tell someone whether an offer is competitive.

Name	Required	Description
`role`	Yes	Role slug or common name, comma-separated for several: rn, lpn, cna, nurse_practitioner, crna, physical_therapist, respiratory_therapist, medical_assistant, … (see list_filters).
`metro`	No	Metro slug, e.g. denver, dallas-fort-worth, los-angeles.
`state`	No	Two-letter US state code, e.g. CO. Use instead of near for a statewide search.
`specialty`	No	Unit or specialty, comma-separated: icu, emergency, labor_delivery, nicu, med_surg, telemetry, operating_room, oncology, psych, pediatrics, home_health, hospice, dialysis, … Common words like ER, L&D, tele, peds work.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=false). The description adds real context the annotations don't: that figures are 'typical posted' pay (not actual earnings) and broken into percentiles, plus the national-vs-optional-geographic scoping. It does not discuss caching, rate limits, or sample-size caveats, keeping it out of 5 territory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The data shape and output percentiles are front-loaded, with the actionable use case second. Nothing redundant with the schema.

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?

With no output schema, the description usefully characterizes the return (three percentile values) and the data source ('posted pay'). Combined with full schema coverage, an agent has enough to call the tool correctly; minor gaps like unit/currency assumptions remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents role, metro, state, and specialty with examples and formats. The description only adds high-level meaning (national default, optional geography/specialty), which is useful framing but not detail beyond the structured fields. Baseline 3 is appropriate.

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?

Specific verb+resource: returns quartile hourly pay (25th/median/75th) for a healthcare role with geographic scoping. It distinguishes itself from siblings like get_job, search_jobs, and list_filters by clearly framing the tool as a compensation benchmark.

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 states the use case ('Use it to tell someone whether an offer is competitive'), which gives clear context for invocation. It stops short of naming alternatives or when-not-to-use conditions (e.g., vs. get_job for a specific posting), so it does not reach the top tier.

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

list_filtersList search filtersA

Read-only

Inspect

Valid roles, specialties, settings, employment types and shifts (with aliases and job counts) for search_jobs.

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that values come with aliases and job counts, a useful content disclosure in the absence of an output schema, but it says nothing about ordering, cardinality, or how the values relate to search_jobs inputs.

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?

A single compact sentence with no filler, and the search_jobs linkage is placed at the end as the key routing cue. It is efficient, though the noun-phrase form is slightly terse for a tool description.

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 zero-parameter lookup tool with annotations covering safety and no output schema, the description covers the resource domain and the relationship to search_jobs. It stops short of explaining how the returned aliases/counts are meant to be used downstream, but nothing essential for invoking it is missing.

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?

The tool takes zero parameters, which sets the baseline at 4 per the scoring rules. The description adds that returned values include aliases and job counts, which is return-content rather than parameter meaning, but no parameter semantics are needed here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource (valid roles, specialties, settings, employment types, shifts) and explicitly ties it to search_jobs, so an agent can tell it apart from get_job and get_pay_benchmarks. It lacks an explicit verb ('Lists'/'Returns'), but the intent is unambiguous.

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

Usage Guidelines3/5

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

The phrase 'for search_jobs' implies this is a lookup to obtain valid filter values before calling search_jobs, but the description never states when to use it, that it takes no input, or that it complements search_jobs rather than replacing it. Usage is inferable rather than stated.

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

search_jobsSearch healthcare jobsA

Read-only

Inspect

Search live US nursing and allied-health job openings by location, role, specialty, shift, pay and requirements. Data is refreshed daily from employer career sites. Each result has a one-line summary, structured pay, a listing_url to show the person, and an apply_url that goes straight to the employer.

Name	Required	Description
`q`	No	Free-text words that must appear in the title, employer or location, e.g. an employer name.
`near`	No	Where the person wants to work: "City, ST", a 5-digit ZIP, or "lat,lng". Results are sorted by distance.
`role`	No	Role slug or common name, comma-separated for several: rn, lpn, cna, nurse_practitioner, crna, physical_therapist, respiratory_therapist, medical_assistant, … (see list_filters).
`sort`	No	best (default): +2 if pay is listed, -1 per week since posting, -1 per 10 miles. Or newest, pay, distance (default when near is set). Sponsored listings (sponsored: true) may appear first.
`limit`	No	Results per page, default 10, max 50.
`shift`	No	days, nights, evenings, rotating, weekends.
`state`	No	Two-letter US state code, e.g. CO. Use instead of near for a statewide search.
`offset`	No	Pagination offset; use next_offset from the previous response.
`remote`	No	Only remote / telehealth jobs.
`has_pay`	No	Only jobs that list pay.
`setting`	No	Care setting: hospital, clinic, skilled_nursing, home_health, hospice, dialysis_center, telehealth, urgent_care, school, correctional, ambulatory_surgery.
`new_grad`	No	Only jobs open to new graduates (residencies, 'new grads welcome', no experience required).
`specialty`	No	Unit or specialty, comma-separated: icu, emergency, labor_delivery, nicu, med_surg, telemetry, operating_room, oncology, psych, pediatrics, home_health, hospice, dialysis, … Common words like ER, L&D, tele, peds work.
`min_annual`	No	Minimum annual pay in USD.
`min_hourly`	No	Minimum hourly pay in USD; matches jobs whose listed range reaches it. Implies has_pay.
`posted_after`	No	Only jobs the employer posted on or after this ISO date/time.
`radius_miles`	No	Search radius around near, default 30, max 200.
`compact_license`	No	Only jobs that mention accepting a compact (multistate) nursing license.
`employment_type`	No	full_time, part_time, prn (per diem), contract, travel, temporary, internship.
`first_seen_after`	No	Only jobs that first appeared on ScrubShifts on or after this ISO time. For recurring checks, pass the previous response's data_as_of to get just the new jobs.
`posted_within_days`	No	Only jobs posted in the last N days.
`max_years_experience`	No	The person's years of experience; excludes jobs that state a higher minimum.

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's added value is the provenance and freshness ('refreshed daily from employer career sites') plus the return shape. Distinguishing listing_url (to show the person) from apply_url (straight to the employer) is genuinely useful behavioral context absent from annotations and the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first front-loads what is searched and over what facets, the second delivers freshness and result structure. Every clause earns its place, and nothing is restated from the schema.

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 22-parameter tool with no output schema, the description does the important extra work of describing the return fields and data freshness. It leaves pagination behavior and sort-default interaction to the schema, which is a minor gap given the 100% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with detailed per-parameter docs including the sort scoring formula, defaults, and enum values, so the schema carries the semantic load. The description only gestures at the facets generally and adds no parameter-level detail beyond what the schema already states, making the baseline 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Search live US nursing and allied-health job openings') and enumerates the searchable facets (location, role, specialty, shift, pay, requirements). Because it describes plural results ('Each result has...'), it is clearly distinguishable from the sibling get_job, which returns a single posting.

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

Usage Guidelines3/5

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

Usage is only implied: the domain (US nursing/allied health) and the mention of daily refresh suggest when this tool applies, but there is no explicit when-to-use versus get_job, list_filters, or get_pay_benchmarks guidance, and no stated exclusions. An agent must infer routing from the sibling names.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateNov 5, 2026

Changedsearch_jobs1 field changed

changedInput schema / properties / sort / description

Previous value: -"best (default): +2 if pay is listed, -1 per week since posting, -1 per 10 miles. Or newest, pay, distance (default when near is set). No paid placement affects ordering."New value: +"best (default): +2 if pay is listed, -1 per week since posting, -1 per 10 miles. Or newest, pay, distance (default when near is set). Sponsored listings (sponsored: true) may appear first."

1 tool updateOct 11, 2026

Changedsearch_jobs4 fields changed

addedInput schema / properties / first_seen_after

Added value: +{
+  "description": "Only jobs that first appeared on ScrubShifts on or after this ISO time. For recurring checks, pass the previous response's data_as_of to get just the new jobs.",
+  "type": "string"
+}

addedInput schema / properties / posted_after

Added value: +{
+  "description": "Only jobs the employer posted on or after this ISO date/time.",
+  "type": "string"
+}

changedInput schema / properties / sort / description

Previous value: -"newest (default), pay, or distance (default when near is set)."New value: +"best (default): +2 if pay is listed, -1 per week since posting, -1 per 10 miles. Or newest, pay, distance (default when near is set). No paid placement affects ordering."

changedInput schema / properties / sort / enum

Previous value: -[
-  "newest",
-  "pay",
-  "distance"
-]New value: +[
+  "best",
+  "newest",
+  "pay",
+  "distance"
+]

4 tool updatesOct 10, 2026
- First observedget_job
- First observedget_pay_benchmarks
- First observedlist_filters
- First observedsearch_jobs

Related MCP Connectors

Waypoint healthcare jobsA
com.waypointrecruit.jobs
Search US hospital jobs, travel nurse contracts and published hospital pay ranges.
Search Biology & Medicine
31
https://jobs.waypointrecruit.com/api/mcp
CareJobs.NowA
now.carejobs
Search 170,000+ open US healthcare jobs at 258 hospitals and health systems, with posted pay.
Search
613
https://carejobs.now/api/mcp
VeritaHire live jobsA
com.veritahire
Live US jobs from employers' own career sites, still-open checks, competitive hiring reports.
Search Research & Data
81
https://veritahire.com/mcp
Off the Floor Nurse JobsA
com.offthefloornurse
Remote, hybrid and non-bedside RN, LPN and NP jobs from employers' own career sites.
41
https://offthefloornurse.com/mcp

Related MCP Servers

Magnificent job search
Search Open Data
AdanRott
A
license
Not graded
quality
D
maintenance
AI Job search over 3.5M+ live US jobs
Updated 3 months ago (2026-08-21 12:10 UTC)
2
MIT
JobsPipe MCP Serverofficial
Search
jobspipe
A
license
Not graded
quality
C
maintenance
Search live job postings from 30+ job boards, ATS feeds and public employment services, and watch for new matches.
Updated a month ago (2026-09-29 03:53 UTC)
MIT
remote-jobs-api
Open Data Research & Data Data Platforms
earnnova-dev
A
license
Not graded
quality
C
maintenance
Live normalized remote-job data across 5 boards — one keyless endpoint, one schema, skill fit-score. No API key required. Tools: search jobs by skills + salary floor, live market stats, and computed salary bands.
Updated a month ago (2026-10-07 10:39 UTC)
MIT
HireJack
Research & Data Search
TVLSS
A
license
A
quality
C
maintenance
Live tech-hiring intelligence for AI agents. Search 130K+ open jobs collected daily from ~500 tech companies' own career sites â plus company hiring profiles, tech stacks, salary benchmarks, and skill trends. Five tools work with no account.
Updated 3 months ago (2026-07-31 14:24 UTC)
31
207 npm
MIT

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

JobsPipe MCP Serverofficial

Glama MCP Gateway

Resources