Search US hospital jobs, travel nurse contracts and published hospital pay ranges.
Scored across 3 tools
get_hospital_wages is clearly distinct as a pay-benchmark lookup, but search_jobs and search_travel_contracts both search healthcare openings and could be confused at a glance. The descriptions do distinguish them (staff/permanent roles vs. travel contracts with weekly pay and agency links), so the boundary is recoverable.
All three tools follow a clean verb_noun pattern (get_hospital_wages, search_jobs, search_travel_contracts) with consistent snake_case. No deviations or mixed conventions.
Three tools is on the thin side, but each maps to a genuinely different data source (wage benchmarks, permanent jobs, travel contracts) and earns its place. It's slightly under-scoped for a jobs platform rather than padded or bloated.
The surface covers the three core lookup intents and returns external links for follow-through, so agents can complete the main workflows. Minor gaps remain, such as no job/contract detail-by-id lookup or location/employer filtering helper beyond free-text system name.
Hourly pay ranges (nursing, allied health, imaging, NP/PA) for a US hospital system covering 392 US hospital systems (3,799 hospitals), last updated October 2026. Search by system name.
| Name | Required | Description | Default |
|---|---|---|---|
| system | Yes | Hospital system name (fuzzy), e.g. "CHRISTUS", "Cleveland Clinic", "Banner" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds genuinely useful context beyond them: dataset scale (392 systems / 3,799 hospitals) and a freshness date (October 2026), which tells the agent the data vintage. It does not disclose return shape or whether a fuzzy match yields multiple systems.
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?
Two tight sentences with the data content front-loaded and no filler. The parenthetical counts are slightly dense but each clause carries information about scope or currency.
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 some burden for describing what comes back, yet it never states the response shape (single system vs. list of matches, pay bands per role). It compensates with scope and update-date metadata, but a caller still cannot predict the result structure.
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 single 'system' parameter is already fully documented with fuzzy-match examples. The description's 'Search by system name' only restates the schema and adds no format or matching semantics beyond it, making the baseline 3 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?
The description clearly states the resource (hourly pay ranges for nursing, allied health, imaging, NP/PA) and the retrieval action (search by system name) for a US hospital system. It is easily distinguished from siblings search_jobs and search_travel_contracts by domain, though it never names or contrasts them explicitly.
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 when-to-use or when-not-to-use guidance is offered. 'Search by system name' describes how to invoke the tool, not the conditions under which an agent should pick it over search_jobs or search_travel_contracts, leaving routing entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ~350,000 active US hospital/healthcare jobs (staff and permanent roles). Returns up to 20 matches with title, employer, location, the pay when the posting lists it, and a link to the job page. Jobs with verified-working apply links rank first.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| limit | No | Max results, 1-20 (default 10) | |
| query | No | Keywords: role, title, employer, or city (e.g. "ICU nurse", "pharmacist", "CHRISTUS") | |
| state | No | Two-letter US state code, e.g. TX | |
| specialty | No | Specialty, e.g. "ICU", "pharmacy", "radiology", "nurse practitioner" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: corpus size, the 20-result cap, and the ranking rule that jobs with verified-working apply links sort first.
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?
Two tight sentences: the first front-loads scope and result shape, the second adds the ranking rule. Nothing is redundant and no sentence is padding.
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 work of describing returns (title, employer, location, pay when listed, job link) and the result cap, which is enough to call the tool confidently. A missing note on whether the 20-result cap means truncated results versus a truly limited corpus is a minor gap.
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 all five parameters (city, state, query, specialty, limit) are already documented with examples. The description only corroborates the 20-result limit and adds no new syntax or constraint detail, so the baseline 3 applies.
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 (search hospital jobs) with concrete scope: ~350,000 active US hospital/healthcare staff and permanent roles. The 'staff and permanent roles' framing also implicitly separates it from the travel-contract sibling.
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 scope wording implies this is for permanent/staff roles rather than travel contracts, which is useful routing context. However, it never explicitly says when to prefer this over search_travel_contracts or get_hospital_wages, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ~93,000 active US travel nursing / allied health contracts with weekly pay. Highest-paying first. Links go to the contract page on Waypoint, which names the staffing agency and links to its posting.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-20 (default 10) | |
| state | No | Two-letter US state code | |
| specialty | No | e.g. "ICU / Critical Care", "Med / Surg", "Radiology / Imaging" | |
| min_weekly_pay | No | Minimum gross weekly pay in USD, e.g. 2500 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful context the annotations cannot convey: result volume (~93,000), default ordering (highest-paying first), and the nature of the returned links (contract page naming the staffing agency). No rate limits or caching behavior disclosed, but the return shape is well described given there is no output schema.
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 short sentences, zero filler, scope and ordering front-loaded before the link-return explanation. Every sentence contributes distinct 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?
For a four-parameter read-only search with no output schema, the description covers domain scope, ordering, and the return payload adequately. It could say more about combining filters or result pagination beyond the limit parameter, which is the only notable gap.
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 four parameters (limit, state, specialty, min_weekly_pay) are fully documented in the schema. The description adds no syntax, format, or interaction detail beyond that, so the baseline 3 applies.
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?
Specific verb+resource ('Search ... travel nursing / allied health contracts') with concrete scope (~93,000 active US contracts) and a stated sort criterion. It does not explicitly distinguish itself from the sibling search_jobs, so an agent must infer that the distinction is contract-type coverage.
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 by the domain (travel/allied contracts with weekly pay) but there is no explicit when-to-use or when-not-to-use guidance, and no routing to or away from search_jobs or get_hospital_wages. Only moderately helpful for selecting among siblings.
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_hospital_wagessearch_jobssearch_travel_contractsSearch 170,000+ open US healthcare jobs at 258 hospitals and health systems, with posted pay.
Live US nursing and allied-health jobs, updated daily. Search by place, role, shift, pay.
Search US hospital prices, compare costs, and find insurance-negotiated rates.
Live healthcare pay data: advertised ranges by role/state/city, offer checks, transparency scores.
Add one secure layer between your agents and this server.
