Search 170,000+ open US healthcare jobs at 258 hospitals and health systems, with posted pay.
Scored across 6 tools
The singular/plural employer pair (get_healthcare_employer vs list_healthcare_employers) is clearly distinguished by scope, and market vs by_state vs pay tools target distinct analytical angles. There is mild overlap since search_healthcare_jobs and list_healthcare_employers can both surface employers/jobs and the pay tool overlaps with employer/state views, but each tool has a dominant purpose the descriptions make clear.
All six tools use snake_case with a consistent verb_noun pattern (get_/list_/search_ + healthcare_ + resource). The shared 'healthcare' qualifier and predictable verb prefixes make the surface easy to scan and predict.
Six tools is well-scoped for a niche healthcare-jobs data API, with each tool covering a distinct facet (search, employers, employer detail, geography, market stats, pay). No redundant or filler tools present.
The surface covers the core lifecycle of discovery and exploration: job search, employer listing and detail, geographic breakdown, market aggregates, and pay. A single-job lookup by ID is absent (jobs link out to CareJobs.Now), which is a minor gap agents can work around via search.
One employer (or AI-training program or job board): what it is, where it hires, its open jobs right now by kind of job, the pay its jobs post, its newest and best-paid open jobs, and links to its page and every open job.
| Name | Required | Description | Default |
|---|---|---|---|
| employer | Yes | An employer (or AI-training program or job board): its slug, e.g. 'hca-healthcare', 'kaiser-permanente', or its name. list_healthcare_employers finds the slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered without help from the description. With no output schema, the description does real work by disclosing the shape and breadth of the return payload (identity, locations, job counts by kind, pay, best-paid jobs, links). It omits what happens on an unknown slug and whether results are paginated or live-updating beyond 'right now'.
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?
It is a single front-loaded sentence that opens with the key scoping fact ('One employer') and never wastes words on throat-clearing. The enumerated payload list is long enough to read as a run-on, which keeps it off a 5, but every clause conveys distinct return 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?
For a one-parameter read tool with no output schema, the description covers the return contents in detail and the annotations cover the safety profile, so an agent has enough to invoke it correctly. The remaining gap is error behavior for an invalid or ambiguous employer name, which the description does not address.
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?
There is a single parameter with 100% schema description coverage, including slug examples and a pointer to list_healthcare_employers, so the baseline is 3. The description's parenthetical '(or AI-training program or job board)' broadens what the parameter accepts, which is genuinely useful, but it largely restates acceptance criteria the schema already gives.
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 names a specific resource ('one employer... or AI-training program or job board') and then enumerates exactly what the response contains: identity, hiring locations, open jobs by kind, posted pay, newest and best-paid jobs, and links. This clearly separates it from list-style siblings like list_healthcare_employers or search_healthcare_jobs. It stops short of naming any sibling explicitly, so it's a clear 4 rather than a 5.
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 only implied: it's the single-entity detail lookup, so an agent can infer it should be called after resolving an employer via list_healthcare_employers — but that pointer lives in the schema, not the description. There is no explicit when-to-use/when-not or naming of alternatives in the description text itself. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many healthcare jobs are open right now, how many were first listed in the last 7 days and how many are listed per week, with the open jobs by kind of job, by US state and by employer (with each employer's slug for the other tools).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds nothing about data freshness, source, or snapshot semantics, and only incidentally covers the return shape because no output schema exists.
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?
A single dense sentence with no wasted filler, and the most important figure (open jobs right now) is front-loaded. It is a run-on construction, but every clause carries distinct informational 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 and no parameters, the description must explain what comes back — and it does, listing all the aggregates and breakdowns. Only the granularity/format of the per-week and per-kind figures is 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?
The tool takes zero parameters, so the schema-side baseline of 4 applies. There is nothing parameter-related the description needs to compensate for.
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 enumerates the exact content returned — open job counts, new-in-7-days counts, weekly listing rate, and breakdowns by job kind, US state, and employer. This clearly separates it from siblings like search_healthcare_jobs and get_healthcare_jobs_by_state, though it phrases the purpose as a list of questions rather than stating the verb ('returns aggregate healthcare job market statistics').
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?
No statement of when to call this versus the sibling tools. The only routing hint is the parenthetical that employer slugs are provided 'for the other tools', which implies this is an entry point, but no explicit when/when-not or alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With no state, every US state's open healthcare jobs and employers. With a state, its open jobs by kind of job, the hourly pay its jobs post, the towns and employers with the most jobs and its newest jobs. With a state and a kind of job, the same for that job in that state (e.g. CNA jobs in Ohio).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | With a state: one kind of job, one of: 'nurses' (Nurses), 'nurse-practitioners' (NPs & PAs), 'physicians' (Doctors), 'nursing-assistants' (CNAs & PCTs), 'caregivers' (Caregivers), 'therapy-rehab' (Therapy & rehab), 'mental-health' (Mental health), 'pharmacy' (Pharmacy), 'imaging' (Imaging), 'lab' (Lab), 'surgical-techs' (Surgical), 'emts-paramedics' (EMS), 'medical-assistants' (Medical assistants), 'dental' (Dental), 'admin' (Front desk & admin), 'allied-health' (Allied health), 'ai-training' (AI training). | |
| limit | No | How many of the newest jobs to return for a state (1 to 25). | |
| state | No | A US state: its two-letter code (e.g. 'TX', 'NY') or its name ('Texas'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful shape info (that output varies by argument combination), but says nothing about result caps beyond the limit param, pagination, or freshness of 'newest jobs'.
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, each mapping to a distinct argument combination, front-loaded with the no-state case. It is information-dense and mostly earns its length, though the third sentence partially repeats the second's pattern.
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 read-only aggregate query tool with a 100%-documented schema and no output schema, the description conveys the three response shapes an agent would get. Minor gaps remain around the limit semantics (only applies to 'newest jobs') but overall it is sufficient.
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 the kind enum is fully documented with human-readable labels in the schema. The description restates the state/kind interaction at a high level but adds no syntax or format detail beyond what the schema already provides; baseline 3 is appropriate.
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+resource (returns healthcare jobs and employers) and its primary dimension is geography (state). It's clear what it does, but does not explicitly distinguish itself from siblings like get_healthcare_job_market or get_healthcare_pay, which likely overlap on the same data.
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 implies three usage modes (no state, state, state+kind) which signals when to use each variant. However, it never names alternatives or says when to prefer a sibling like search_healthcare_jobs over this aggregate tool, so routing 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.
What healthcare jobs post as pay today, measured from the hourly rates open jobs state (before shift differentials and bonuses): with no arguments, the median and typical range for every kind of job (a market rate only where at least three employers post one); with a kind of job, that job's pay and the employers that post the most for it; with an employer, its pay overall and by kind of job; with both, that employer's pay for that job.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of job, one of: 'nurses' (Nurses), 'nurse-practitioners' (NPs & PAs), 'physicians' (Doctors), 'nursing-assistants' (CNAs & PCTs), 'caregivers' (Caregivers), 'therapy-rehab' (Therapy & rehab), 'mental-health' (Mental health), 'pharmacy' (Pharmacy), 'imaging' (Imaging), 'lab' (Lab), 'surgical-techs' (Surgical), 'emts-paramedics' (EMS), 'medical-assistants' (Medical assistants), 'dental' (Dental), 'admin' (Front desk & admin), 'allied-health' (Allied health), 'ai-training' (AI training). | |
| employer | No | An employer (or AI-training program or job board): its slug, e.g. 'hca-healthcare', 'kaiser-permanente', or its name. list_healthcare_employers finds the slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, so the bar is lower, and the description still adds real behavior: pay is derived from posted hourly rates excluding shift differentials and bonuses, and a market rate is reported only where at least three employers post one. That sample-size threshold is meaningful disclosure the annotations do not provide.
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?
A single dense sentence with the core purpose front-loaded before the mode enumeration. It earns most of its length, though the colon-and-semicolon construction packs four distinct behaviors into one long clause chain.
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 return-value burden and does so: median plus typical range, top employers, employer pay overall and by kind, and the minimum-employer threshold. Nothing essential for correct invocation 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 parameters are documented with enums and examples, so the baseline is 3. The description adds value beyond the schema by explaining what each parameter combination actually produces, clarifying the semantics of combining kind and employer.
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 and resource ('What healthcare jobs post as pay today') and immediately scopes the measurement basis to stated hourly rates before differentials and bonuses. It is clearly distinguishable from siblings like get_healthcare_employer or get_healthcare_job_market because it is the pay-rate aggregator.
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 enumerates the four invocation modes (no args, kind only, employer only, both) and explains what each returns, which is effectively when-to-use guidance. It also routes the agent to list_healthcare_employers for slug lookup, but never explicitly names or excludes the other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The hospitals, health systems, clinic groups and care companies whose jobs CareJobs.Now reads, most open jobs first, with where each hires, its open jobs and its posted pay. Filter by name, kind of care, US state (employers with open jobs there) or kind of job (employers with open jobs of it). Also lists the AI-training programs and the job boards read, as such.
| Name | Required | Description | Default |
|---|---|---|---|
| care | No | Kind of care, one of: 'health-system' (Hospitals & health systems), 'childrens-hospital' (Children's hospitals), 'outpatient' (Clinics, primary & urgent care), 'specialty-care' (Specialty & physician practices), 'behavioral-health' (Mental health care), 'autism-care' (Autism & ABA therapy), 'home-care' (Home health & hospice), 'senior-care' (Senior living), 'rehab' (Physical therapy & rehab), 'dental' (Dental), 'pharmacy-retail' (Pharmacy & retail health), 'kidney-care' (Dialysis & kidney care), 'labs-imaging' (Labs & imaging), 'telehealth' (Virtual care), 'ai-training' (AI training programs), 'job-boards' (Job boards we also read). | |
| kind | No | Kind of job, one of: 'nurses' (Nurses), 'nurse-practitioners' (NPs & PAs), 'physicians' (Doctors), 'nursing-assistants' (CNAs & PCTs), 'caregivers' (Caregivers), 'therapy-rehab' (Therapy & rehab), 'mental-health' (Mental health), 'pharmacy' (Pharmacy), 'imaging' (Imaging), 'lab' (Lab), 'surgical-techs' (Surgical), 'emts-paramedics' (EMS), 'medical-assistants' (Medical assistants), 'dental' (Dental), 'admin' (Front desk & admin), 'allied-health' (Allied health), 'ai-training' (AI training). | |
| type | No | 'employer' (hospitals, clinics and care companies; the default without a query), 'ai-program' (programs paying health professionals for remote AI work) or 'job-board' (sources of other employers' jobs). | |
| limit | No | How many to return (1 to 100). | |
| query | No | Part of the name, e.g. 'Kaiser', 'children', 'dialysis'. | |
| state | No | A US state: its two-letter code (e.g. 'TX', 'NY') or its name ('Texas'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds real behavioral context beyond them: the result ordering (most open jobs first), the per-employer fields returned (locations, open jobs, posted pay), and the non-obvious rule that the state and job-kind filters only match employers that currently have matching open jobs.
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 is front-loaded in the first clause, which is good, but the text is two dense run-on sentences with a trailing clause ('as such') that reads as vague and slightly ungrammatical. Nothing is strictly wasted, yet the phrasing is harder to parse than it needs to be.
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 steps in by describing the returned fields and ordering, and all six parameters are documented in the schema. Annotations cover the safety profile. Only the ambiguity of when to prefer this over sibling search/get tools keeps it from being fully 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%, so the baseline is 3, but the description adds semantics the schema does not carry: that state and kind filters are conditional on existing open jobs, and that 'employer' is the default type when no query is given. That is genuine added meaning over the enum/param docs.
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 names a specific resource set (hospitals, health systems, clinic groups, care companies) plus the AI-training programs and job boards it also returns, and states the sort order ('most open jobs first'). It is clearly a browse/list tool, which implicitly separates it from the singular get_healthcare_employer, but it never names a sibling to route between them.
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 enumerates what can be filtered (name, kind of care, state, kind of job) and how state/kind filters behave, which implies usage, but gives no explicit when-to-use or when-not-to-use guidance and never points to an alternative such as search_healthcare_jobs or get_healthcare_jobs_by_state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the open healthcare jobs at 258 US hospitals, health systems, clinic groups and care companies (nurses, CNAs, doctors, NPs and PAs, therapists, techs, pharmacy, caregivers, front office and more), plus the listings of the job boards the site reads, each naming its employer. Returns each job's title, employer, kind of job, posted pay, shift where the posting states it, place, and a link to its page on CareJobs.Now, where the user applies. All filters are optional.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Kind of job, one of: 'nurses' (Nurses), 'nurse-practitioners' (NPs & PAs), 'physicians' (Doctors), 'nursing-assistants' (CNAs & PCTs), 'caregivers' (Caregivers), 'therapy-rehab' (Therapy & rehab), 'mental-health' (Mental health), 'pharmacy' (Pharmacy), 'imaging' (Imaging), 'lab' (Lab), 'surgical-techs' (Surgical), 'emts-paramedics' (EMS), 'medical-assistants' (Medical assistants), 'dental' (Dental), 'admin' (Front desk & admin), 'allied-health' (Allied health), 'ai-training' (AI training). | |
| sort | No | 'mixed' (the board's order, employers interleaved), 'newest' or 'highest_pay'. | mixed |
| limit | No | How many jobs to return (1 to 25). | |
| query | No | Words every job must carry in its title, place, department or schedule, e.g. 'ICU', 'night', 'travel', 'pediatric', 'Houston'. | |
| state | No | A US state: its two-letter code (e.g. 'TX', 'NY') or its name ('Texas'). | |
| remote | No | Only remote (work-from-home) jobs, such as telehealth, case management, coding and billing. | |
| employer | No | An employer (or AI-training program or job board): its slug, e.g. 'hca-healthcare', 'kaiser-permanente', or its name. list_healthcare_employers finds the slugs. | |
| min_hourly_usd | No | Only jobs whose posted hourly ceiling reaches this many US dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: the breadth of the source corpus (258 US hospitals, health systems, job boards) and the exact result fields returned, including the apply link. Missing rate limits, pagination or caching behavior keeps it off 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The verb is front-loaded and the return-field list is useful, but the opening sentence is a single sprawling construction with nested parentheticals, and its long enumeration of job kinds largely duplicates the 'kind' enum descriptions. Trimming that duplication would sharpen the definition.
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 does the valuable work of enumerating returned fields, and it names the corpus size. Still absent are result-count/pagination behavior, what happens when filters combine to zero matches, and any sibling-selection rule for the state- and market-specific tools.
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 schema already carries enum meanings, defaults, ranges and examples for all 8 params; baseline 3 applies. The description contributes only the meta-claim that all filters are optional, which the schema's empty required list already implies.
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 ('Search the open healthcare jobs') and narrows scope to 258 US hospitals plus job-board listings, which is concrete and distinguishable. It does not explicitly differentiate itself from close siblings like get_healthcare_jobs_by_state or get_healthcare_job_market, so an agent must infer the boundary.
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?
'All filters are optional' tells the agent the tool is callable with no arguments, and the employer param routes to list_healthcare_employers for slug lookup. However, there is no guidance on when to prefer this tool over get_healthcare_jobs_by_state or get_healthcare_job_market, which is the main selection risk.
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.
get_healthcare_employerget_healthcare_job_marketget_healthcare_jobs_by_stateget_healthcare_paylist_healthcare_employerssearch_healthcare_jobsSearch US hospital jobs, travel nurse contracts and published hospital pay ranges.
Live US nursing and allied-health jobs, updated daily. Search by place, role, shift, pay.
Live healthcare pay data: advertised ranges by role/state/city, offer checks, transparency scores.
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Add one secure layer between your agents and this server.
