RxRooster

Server Details

Six privacy-safe tools for anesthesia discovery, drafts, coverage, and recruiting packets.

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
Last Tested: 2026-10-23 23:41
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-10-23 16:25 across 6 tools

Disambiguation5/5

Each tool targets a distinct object/action/output: job discovery, single-job detail, recruiting packet generation, employer job draft, clinician service draft, and coverage exploration. The employer-vs-clinician draft distinction is explicitly scoped by audience, and detail vs packet retrieval is separated by output type.

Naming Consistency5/5

All names use consistent snake_case verb_noun phrasing, with predictable resource nouns such as anesthesia_job, anesthesia_jobs, and anesthesia_service_draft. The verbs explore, get, prepare, and search are used coherently.

Tool Count5/5

Six tools is well-scoped for a niche anesthesia job/service marketplace. Each tool corresponds to a distinct workflow rather than adding filler or redundant operations.

Completeness4/5

The surface covers core discovery, detail, employer drafting, clinician drafting, recruiting packet, and coverage workflows. Minor gaps remain around direct application/contact or persistent update/publish operations, but the descriptions consistently position drafts as non-persistent handoffs to native review.

Available Tools

6 tools

explore_coverage_areasExplore anesthesia coverage areasA

Read-onlyIdempotent

Inspect

Use this when an employer asks where RxRooster shows anonymous public CRNA service options or approximate U.S. coverage. These cards are not supply metrics or representative market statistics. Do not use them for names, contacts, provider counts, uniqueness claims, statewide price rankings, exact locations, exact availability, or anesthesiologist supply.

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	US state name or two-letter postal code to explore.
`page_size`	No	Maximum anonymous public service cards to return, from 1 through 10.
`area_query`	No	Optional city, metro, or area text used to narrow results.
`provider_type`	No	Provider type for coverage exploration; v1.1 publishes anonymous public service cards for CRNAs only.	crna

Output Schema

ParametersJSON Schema

Name	Required	Description
`areas`	Yes
`query`	Yes
`status`	Yes
`continue_url`	Yes
`generated_at`	Yes
`presentation`	Yes
`provider_type`	Yes
`service_cards`	Yes
`interpretation`	Yes
`schema_version`	Yes
`supported_provider_types`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world, so the description's real contribution is the negative framing: these are not supply metrics, not representative market statistics, and not a source for counts, uniqueness claims, or exact locations. That boundary-setting meaningfully prevents misuse. It stops short of 5 because it says little about result shape or paging behavior beyond what structured fields already convey.

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?

The trigger condition is front-loaded and the whole definition is two sentences. The long exclusion list is dense but each item corresponds to a distinct failure mode the agent could otherwise stumble into, so little is wasted. Slightly list-heavy but appropriately sized.

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?

An output schema exists, so return values need not be explained, and annotations handle safety. The description supplies the missing piece — when this tool is appropriate and what its output must not be interpreted as. Only minor gaps remain, such as how area_query interacts with state or what paging the caller should request.

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% and every parameter is documented inline, including the CRNA-only constraint on provider_type, so the schema carries the burden. The description adds no syntax, defaulting, or narrowing guidance for state, page_size, or area_query, making the baseline 3 correct.

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 states a concrete use case — showing where RxRooster surfaces anonymous public CRNA service options and approximate U.S. coverage — which is a specific resource, not a restatement of the name. It does not name any sibling tool to differentiate itself from, leaving that contrast to inference, so it falls short of a 5.

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?

It opens with an explicit trigger ('Use this when an employer asks where...') and then enumerates a long list of what the cards must not be used for (names, contacts, provider counts, price rankings, exact availability). Usage exclusions are unusually explicit, but no alternative sibling tool is named for the excluded cases, so it stops at 4.

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

get_anesthesia_jobGet an anesthesia jobA

Read-onlyIdempotent

Inspect

Use this when someone asks for details about one job already returned by RxRooster search. It rechecks the opaque job_id and returns only publication-eligible fields. Do not use it with guessed IDs or for private listing data.

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes	Opaque job ID from a search_anesthesia_jobs result.

Output Schema

ParametersJSON Schema

Name	Required	Description
`job`	Yes
`found`	Yes
`generated_at`	Yes
`schema_version`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds genuine context beyond them: the tool rechecks the opaque job_id and returns only publication-eligible fields, which tells the agent output is filtered. It stops short of noting rate limits, auth requirements, or failure behavior on invalid IDs.

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?

Three short sentences, zero filler, with the use case front-loaded and the prohibitions trailing. Every clause carries actionable information.

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

Completeness5/5

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

With an output schema present, return-value detail is not required, and the description still flags that only publication-eligible fields come back. For a single-parameter read tool with full annotation coverage, nothing needed to invoke it correctly 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?

Schema coverage is 100% and the single parameter is already documented as an opaque ID from a search result, so the baseline is 3. The description goes further by clarifying that the ID is revalidated and that guessed IDs will not work, adding meaning the pattern constraint alone does not convey.

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 names a specific verb and resource — fetching details for one job previously returned by an RxRooster search — and implicitly separates it from search_anesthesia_jobs, prepare_* drafts, and the packet tool. An agent can route to it without opening any schema.

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

Usage Guidelines5/5

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

It states the trigger condition (someone asks for details about one job already returned by search), the required provenance of the input (an ID from a prior search), and explicit exclusions (no guessed IDs, no private listing data). Both when-to-use and when-not-to-use are covered.

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

get_anesthesia_recruiting_packetGet an anesthesia recruiting packetA

Read-onlyIdempotent

Inspect

Use this when a recruiter wants branded flyer downloads or factual Facebook-group copy for a currently live public RxRooster anesthesia opening. Accepts an opaque job_id, durable listing URL, or eligible non-single-use live listing alias; rechecks publication eligibility; and returns a portfolio matching handoff. Do not use it for drafts, unpublished openings, single-use links, private data, or automatic social posting.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already establish readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds behavior beyond that: it rechecks publication eligibility at call time and returns a 'portfolio matching handoff', which tells the agent the input's liveness is validated server-side rather than trusted.

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?

Two dense sentences with the trigger condition front-loaded and the negative constraints trailing, so the agent reads the use case first. It is efficient, though the identifier enumeration slightly duplicates 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?

An output schema exists, so return values need not be spelled out, and the description still gestures at the return shape ('portfolio matching handoff'). Combined with full schema coverage and rich annotations, the definition is complete enough to call correctly, with only minor room for detail on eligibility-failure behavior.

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%, so both the opaque job_id and the durable /s/<token> URL or alias are already documented in the schema. The description restates the accepted identifier forms without adding format, precedence, or error-handling detail beyond the schema, which matches the baseline 3 when structured fields do the work.

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 names a concrete verb and artifact ('branded flyer downloads or factual Facebook-group copy') for a specific resource ('currently live public RxRooster anesthesia opening'). It is clearly separable from siblings like get_anesthesia_job (raw job data) and prepare_anesthesia_job_draft (draft creation) without opening any schema.

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

Usage Guidelines5/5

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

It gives an explicit trigger condition ('when a recruiter wants branded flyer downloads or factual Facebook-group copy for a currently live public... opening') and an explicit exclusion list ('drafts, unpublished openings, single-use links, private data, or automatic social posting'). The exclusions implicitly route the agent to the draft-preparation siblings.

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

prepare_anesthesia_job_draftPrepare an anesthesia requisition draftA

Read-only

Inspect

Use this when an employer or recruiter wants to parse an anesthesia job description or structure answers into a privacy-safe, non-persistent requisition draft for native RxRooster review. Before pasted-text use, disclose that recognizable contact blocks are locally minimized and only the minimized text is sent to RxRooster's configured AI parsing provider; advise removal of sensitive information. Structured draft-only collection is the no-parser alternative. The tool removes contact fields and raw text from results, identifies publication blockers and quality details, and returns a native sign-in/review handoff only when core facts are ready. Pasted-text use may call an external parsing model and consume quota. Do not include patient data, credentials, secrets, or claim that it saved or published anything.

ParametersJSON Schema

Name	Required	Description	Default
`draft`	No	Previously returned privacy-safe draft fields plus explicit corrections or follow-up answers.
`job_description`	No	Pasted anesthesia requisition text. RxRooster locally removes recognizable contact blocks, does not store or return the pasted text, and sends only the minimized text to RxRooster's configured AI parsing provider. Do not include personal, credential, patient, or confidential information.

Output Schema

ParametersJSON Schema

Name	Required	Description
`draft`	Yes
`status`	Yes
`next_step`	Yes
`redactions`	Yes
`generated_at`	Yes
`parse_status`	Yes
`filled_fields`	Yes
`employer_value`	Yes
`missing_fields`	Yes
`schema_version`	Yes
`draft_fingerprint`	Yes

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations, the description discloses substantial behavior: contact fields and raw text are stripped from results, the draft is non-persistent, pasted text is sent (minimized) to an external AI parsing provider, quota may be consumed, and the review handoff only fires when core facts are ready. It also states safety constraints (no patient data, credentials, or secrets) and never contradicts the readOnly/destructive hints.

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?

It is front-loaded with the 'use this when' trigger and nearly every sentence carries distinct information (trigger, pre-use disclosure, alternative mode, result behavior, quota, constraints). It is dense and clause-heavy though, with several multi-clause sentences that could be split, keeping it just short of ideal.

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?

Given two top-level params, a nested draft object, and an existing output schema, the description covers the modes, privacy handling, external-call/quota caveat, handoff condition, and hard exclusions. Return values need not be explained because an output schema exists; only minor details (e.g., quota specifics) are absent, so it is essentially complete.

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 description coverage is already 100%, so the baseline is 3, but the description adds real meaning: it clarifies that 'job_description' is the pasted-text path that may invoke an external parser and consume quota, while the 'draft' object is the no-parser alternative. This mapping of the two inputs to two distinct modes exceeds the schema's per-field text.

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 first sentence gives a concrete verb pair (parse a job description / structure answers) and a specific output artifact (a privacy-safe, non-persistent anesthesia requisition draft for RxRooster review). The domain ('anesthesia job' vs. the sibling 'anesthesia service' draft) is implied by the resource wording but no sibling is named explicitly, so it falls short of full sibling differentiation.

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?

It states the trigger clearly ('Use this when an employer or recruiter wants to...') and names an alternative path ('Structured draft-only collection is the no-parser alternative'), plus a precondition for the pasted-text mode. It lacks explicit when-not guidance and does not route to any sibling tool, so it stops short of a 5.

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

prepare_anesthesia_service_draftPrepare an anesthesia service draftA

Read-onlyIdempotent

Inspect

Use this when a CRNA, SRNA, or anesthesiologist wants to structure their own stated work terms, including an explicit call or no-call preference, for native RxRooster review. The draft is private and non-persistent here. Ask rate visibility neutrally. Do not include identity/contact fields or claim that the tool saved or published a service.

ParametersJSON Schema

Name	Required	Description
`state`	No	US state name or two-letter postal code.
`area_query`	No	City, metro, or public service-area label, without an address.
`work_types`	No
`days_of_week`	No
`radius_miles`	No	Approximate service radius; 3000 represents nationwide travel.
`provider_type`	Yes	The provider credential or training path stated by the user.
`contract_types`	No
`call_preference`	No	Explicit call preference: any means no restriction, no_call excludes call work, and call_ok means call is acceptable but not necessarily preferred.
`rate_visibility`	No
`availability_end`	No	Calendar date in YYYY-MM-DD format.
`shift_preferences`	No
`availability_start`	No	Calendar date in YYYY-MM-DD format.
`minimum_hourly_rate`	No
`shift_lengths_hours`	No
`minimum_annual_salary`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`draft`	Yes
`status`	Yes
`privacy`	Yes
`benefits`	Yes
`next_step`	Yes
`generated_at`	Yes
`provider_path`	Yes
`missing_fields`	Yes
`schema_version`	Yes
`draft_fingerprint`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds non-obvious behavior: the draft is private and non-persistent, and the agent must not report it as saved or published. 'Ask rate visibility neutrally' is a valuable presentation constraint that no structured field encodes. It does not explain validation failure behavior for the 15 constrained fields.

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?

Three tight sentences: the usage trigger first, the privacy/non-persistence contract second, guardrails last. Nothing is repeated from the title or schema, and every sentence changes agent behavior.

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

Completeness3/5

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

Output schema and annotations cover return shape and safety, and the description covers privacy and guardrails. But for a 15-parameter tool, it says nothing about how the draft fields relate to each other (e.g., rate vs. salary, availability windows) or what the review step does after the draft, leaving it only adequately specified.

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?

With 15 parameters and only 47% schema description coverage, the description would need to carry weight, yet it only reinforces two fields: call_preference and rate_visibility (the latter adding a 'neutral' framing not in the schema). Fields like work_types, contract_types, shift_lengths_hours, radius_miles, and the rate bounds get no help beyond their enums, so it partially compensates but leaves real gaps.

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 states the resource precisely: the user's own stated work terms, including call/no-call preference, packaged as a private non-persistent draft for RxRooster review. It is clear what is produced, but it never distinguishes this 'service draft' from the sibling prepare_anesthesia_job_draft, leaving the agent to infer the split from the names alone.

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?

It gives an explicit trigger ('use this when a CRNA, SRNA, or anesthesiologist wants to structure their own stated work terms') plus exclusions ('do not include identity/contact fields', 'do not claim the tool saved or published'). It stops short of naming an alternative tool or saying when *not* to use this in favor of prepare_anesthesia_job_draft.

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

search_anesthesia_jobsSearch anesthesia jobsA

Read-onlyIdempotent

Inspect

Use this when someone wants to discover current public anesthesia jobs by provider role or U.S. state. Returns numbered results with opaque follow-up handles. Do not use it to infer hidden pay or search for clinicians.

ParametersJSON Schema

Name	Required	Description
`page`	No	One-based result page number.
`states`	No	One to ten US states to include in the search.
`page_size`	No	Number of jobs per page, from 1 through 25.
`provider_type`	No	Anesthesia provider role to search for.

Output Schema

ParametersJSON Schema

Name	Required	Description
`jobs`	Yes
`selection`	Yes
`pagination`	Yes
`generated_at`	Yes
`schema_version`	Yes
`applied_filters`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: results are 'numbered' with 'opaque follow-up handles,' and the scope is limited to 'current public' jobs. It does not discuss auth, rate limits, or pagination behavior, but those are largely covered by schema or annotations.

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?

Three sentences, front-loaded with the primary use case, then return behavior, then exclusions. Each sentence contributes distinct information with no repetition or filler.

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?

Given the rich schema, output schema, and annotations, the description covers the main use case and exclusions adequately. A minor gap is that it mentions opaque follow-up handles but does not explicitly route the agent to get_anesthesia_job or explain how to use them.

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%, so all four parameters are already well documented in the schema. The description loosely maps to provider role and U.S. state, but adds no syntax, format, or constraint details beyond what the schema already provides.

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 states a specific verb and resource: 'discover current public anesthesia jobs by provider role or U.S. state.' This clearly distinguishes a search/discovery operation from retrieval siblings like get_anesthesia_job, but it does not explicitly name or compare against any sibling tool.

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?

It gives explicit when-to-use guidance ('Use this when someone wants to discover...') and explicit exclusions ('Do not use it to infer hidden pay or search for clinicians'). However, it does not name alternative tools for related tasks, so it falls short of the full when/when-not/alternatives rubric.

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 updateOct 21, 2026

Changedprepare_anesthesia_service_draft3 fields changed

addedInput schema / properties / call_preference

Added value: +{
+  "description": "Explicit call preference: any means no restriction, no_call excludes call work, and call_ok means call is acceptable but not necessarily preferred.",
+  "enum": [
+    "any",
+    "no_call",
+    "call_ok"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / draft / properties / call_preference

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "any",
+        "no_call",
+        "call_ok"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

changedOutput schema / properties / draft / required

Previous value: -[
-  "provider_type",
-  "area_query",
-  "state",
-  "radius_miles",
-  "availability_start",
-  "availability_end",
-  "days_of_week",
-  "shift_preferences",
-  "shift_lengths_hours",
-  "work_types",
-  "contract_types",
-  "minimum_hourly_rate",
-  "minimum_annual_salary",
-  "rate_visibility"
-]New value: +[
+  "provider_type",
+  "area_query",
+  "state",
+  "radius_miles",
+  "availability_start",
+  "availability_end",
+  "days_of_week",
+  "shift_preferences",
+  "call_preference",
+  "shift_lengths_hours",
+  "work_types",
+  "contract_types",
+  "minimum_hourly_rate",
+  "minimum_annual_salary",
+  "rate_visibility"
+]

3 tool updatesOct 21, 2026
- Addedget_anesthesia_recruiting_packet
- Addedprepare_anesthesia_job_draft
- Addedprepare_anesthesia_service_draft

3 tool updatesOct 21, 2026

Changedexplore_coverage_areas16 fields changed

addedInput schema / properties / page_size

Added value: +{
+  "default": 5,
+  "description": "Maximum anonymous public service cards to return, from 1 through 10.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / provider_type / description

Previous value: -"Provider type for coverage-area exploration; v1 publishes aggregate areas for CRNAs only."New value: +"Provider type for coverage exploration; v1.1 publishes anonymous public service cards for CRNAs only."

addedOutput schema / properties / interpretation / properties / count_inference_allowed
```
Added value: +{
+  "const": false,
+  "type": "boolean"
+}
```

addedOutput schema / properties / interpretation / properties / do_not_infer

Added value: +{
+  "items": false,
+  "maxItems": 3,
+  "minItems": 3,
+  "prefixItems": [
+    {
+      "const": "provider_count",
+      "type": "string"
+    },
+    {
+      "const": "clinician_presence",
+      "type": "string"
+    },
+    {
+      "const": "exact_availability",
+      "type": "string"
+    }
+  ],
+  "type": "array"
+}

addedOutput schema / properties / interpretation / properties / empty_result_semantics

Added value: +{
+  "const": "not_evidence_of_zero_count_or_unavailability",
+  "type": "string"
+}

changedOutput schema / properties / interpretation / properties / kind / const

Previous value: -"privacy_thresholded_published_service_base_areas"New value: +"public_anonymous_service_options"

removedOutput schema / properties / interpretation / properties / nationwide_traveler_reach_included / const
```
Removed value: -false
```
addedOutput schema / properties / interpretation / properties / provider_counts_available
```
Added value: +{
+  "const": false,
+  "type": "boolean"
+}
```
addedOutput schema / properties / interpretation / properties / underlying_supply
```
Added value: +{
+  "const": "unknown",
+  "type": "string"
+}
```

changedOutput schema / properties / interpretation / required

Previous value: -[
-  "kind",
-  "counts_available",
-  "nationwide_traveler_reach_included",
-  "exact_availability_confirmed",
-  "note"
-]New value: +[
+  "kind",
+  "counts_available",
+  "provider_counts_available",
+  "count_inference_allowed",
+  "underlying_supply",
+  "nationwide_traveler_reach_included",
+  "exact_availability_confirmed",
+  "empty_result_semantics",
+  "do_not_infer",
+  "note"
+]

addedOutput schema / properties / presentation

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "card_order": {
+      "const": "as_returned",
+      "type": "string"
+    },
+    "layout": {
+      "const": "service_cards",
+      "type": "string"
+    },
+    "primary_action_label": {
+      "const": "Explore on RxRooster",
+      "type": "string"
+    },
+    "title": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "layout",
+    "title",
+    "card_order",
+    "primary_action_label"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / query

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "area_query": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "resolved_location": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "state": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "state",
+    "area_query",
+    "resolved_location"
+  ],
+  "type": "object"
+}

changedOutput schema / properties / schema_version / const
```
Previous value: -"1.0"New value: +"1.1"
```

addedOutput schema / properties / service_cards

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "action": {
+        "additionalProperties": false,
+        "properties": {
+          "label": {
+            "const": "Explore on RxRooster",
+            "type": "string"
+          },
+          "url": {
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "label",
+          "url"
+        ],
+        "type": "object"
+      },
+      "availability": {
+        "additionalProperties": false,
+        "properties": {
+          "exact_shift_confirmation": {
+            "const": false,
+            "type": "boolean"
+          },
+          "label": {
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "available_now",
+              "upcoming",
+              "to_confirm"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "status",
+          "label",
+          "exact_shift_confirmation"
+        ],
+        "type": "object"
+      },
+      "compensation": {
+        "additionalProperties": false,
+        "properties": {
+          "annual_minimum": {
+            "anyOf": [
+              {
+                "exclusiveMinimum": 0,
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "currency": {
+            "const": "USD",
+            "type": "string"
+          },
+          "disclosure": {
+            "enum": [
+              "published",
+              "private",
+              "not_available"
+            ],
+            "type": "string"
+          },
+          "display": {
+            "type": "string"
+          },
+          "hourly_minimum": {
+            "anyOf": [
+              {
+                "exclusiveMinimum": 0,
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "qualifier": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "disclosure",
+          "currency",
+          "hourly_minimum",
+          "annual_minimum",
+          "display",
+          "qualifier"
+        ],
+        "type": "object"
+      },
+      "coverage": {
+        "additionalProperties": false,
+        "properties": {
+          "approximate": {
+            "const": true,
+            "type": "boolean"
+          },
+          "kind": {
+            "enum": [
+              "local",
+              "travel",
+              "regional"
+            ],
+            "type": "string"
+          },
+          "location_label": {
+            "type": "string"
+          },
+          "radius_miles": {
+            "exclusiveMinimum": 0,
+            "type": "number"
+          }
+        },
+        "required": [
+          "kind",
+          "location_label",
+          "radius_miles",
+          "approximate"
+        ],
+        "type": "object"
+      },
+      "headline": {
+        "type": "string"
+      },
+      "provider_type": {
+        "const": "crna",
+        "type": "string"
+      },
+      "rank": {
+        "maximum": 9007199254740991,
+        "minimum": 1,
+        "type": "integer"
+      },
+      "service_id": {
+        "description": "Opaque, rotating public RxRooster service-card ID.",
+        "pattern": "^pc_[A-Za-z0-9_-]{28}$",
+        "type": "string"
+      },
+      "terms": {
+        "additionalProperties": false,
+        "properties": {
+          "cadence": {
+            "anyOf": [
+              {
+                "enum": [
+                  "Every week",
+                  "Every other week",
+                  "1st and 3rd weeks",
+                  "2nd and 4th weeks",
+                  "Every third week"
+                ],
+                "type": "string"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "days_of_week": {
+            "items": {
+              "enum": [
+                "Monday",
+                "Tuesday",
+                "Wednesday",
+                "Thursday",
+                "Friday",
+                "Saturday",
+                "Sunday"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "engagement_types": {
+            "items": {
+              "enum": [
+                "1099",
+                "W-2"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "minimum_contract_weeks": {
+            "anyOf": [
+              {
+                "exclusiveMinimum": 0,
+                "maximum": 9007199254740991,
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "preferred_contract_weeks": {
+            "anyOf": [
+              {
+                "exclusiveMinimum": 0,
+                "maximum": 9007199254740991,
+                "type": "integer"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "schedule_preferences": {
+            "items": {
+              "enum": [
+                "Flexible",
+                "Weekdays",
+                "Weekends",
+                "Call"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "shift_lengths_hours": {
+            "items": {
+              "exclusiveMinimum": 0,
+              "maximum": 24,
+              "type": "number"
+            },
+            "type": "array"
+          },
+          "shift_preferences": {
+            "items": {
+              "enum": [
+                "Day shifts",
+                "Night shifts",
+                "On-call",
+                "Weekends",
+                "Evening shifts"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "work_types": {
+            "items": {
+              "enum": [
+                "Temporary",
+                "Permanent",
+                "Part-time",
+                "PRN",
+                "Locums"
+              ],
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "engagement_types",
+          "work_types",
+          "schedule_preferences",
+          "days_of_week",
+          "cadence",
+          "shift_preferences",
+          "shift_lengths_hours",
+          "preferred_contract_weeks",
+          "minimum_contract_weeks"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "rank",
+      "service_id",
+      "provider_type",
+      "headline",
+      "coverage",
+      "availability",
+      "compensation",
+      "terms",
+      "action"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / status / enum

Previous value: -[
-  "available",
-  "unsupported_provider_type"
-]New value: +[
+  "available",
+  "no_public_service_options",
+  "unsupported_provider_type"
+]

changedOutput schema / required

Previous value: -[
-  "schema_version",
-  "generated_at",
-  "status",
-  "provider_type",
-  "supported_provider_types",
-  "areas",
-  "interpretation",
-  "continue_url"
-]New value: +[
+  "schema_version",
+  "generated_at",
+  "status",
+  "provider_type",
+  "supported_provider_types",
+  "query",
+  "presentation",
+  "service_cards",
+  "areas",
+  "interpretation",
+  "continue_url"
+]

Changedget_anesthesia_job1 field changed
- changedOutput schema / properties / schema_version / const
```
Previous value: -"1.0"New value: +"1.1"
```

Changedsearch_anesthesia_jobs6 fields changed

addedOutput schema / properties / jobs / items / properties / detail_arguments

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "job_id": {
+      "description": "Opaque RxRooster job ID returned by search_anesthesia_jobs.",
+      "pattern": "^rj_[A-Za-z0-9_-]{56}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "job_id"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / jobs / items / properties / result_position

Added value: +{
+  "description": "One-based position in this returned search page.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

changedOutput schema / properties / jobs / items / required

Previous value: -[
-  "job_id",
-  "title",
-  "provider_type",
-  "organization",
-  "location",
-  "compensation",
-  "schedule",
-  "assignment",
-  "case_types",
-  "summary",
-  "date_posted",
-  "first_seen_at",
-  "last_checked_at",
-  "links"
-]New value: +[
+  "job_id",
+  "title",
+  "provider_type",
+  "organization",
+  "location",
+  "compensation",
+  "schedule",
+  "assignment",
+  "case_types",
+  "summary",
+  "date_posted",
+  "first_seen_at",
+  "last_checked_at",
+  "links",
+  "result_position",
+  "detail_arguments"
+]

changedOutput schema / properties / schema_version / const
```
Previous value: -"1.0"New value: +"1.1"
```

addedOutput schema / properties / selection

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "first_job_id": {
+      "anyOf": [
+        {
+          "description": "Opaque RxRooster job ID returned by search_anesthesia_jobs.",
+          "pattern": "^rj_[A-Za-z0-9_-]{56}$",
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "ordering": {
+      "const": "jobs_array_order_1_based",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ordering",
+    "first_job_id"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "schema_version",
-  "generated_at",
-  "applied_filters",
-  "jobs",
-  "pagination"
-]New value: +[
+  "schema_version",
+  "generated_at",
+  "applied_filters",
+  "jobs",
+  "selection",
+  "pagination"
+]

3 tool updatesOct 21, 2026
- First observedexplore_coverage_areas
- First observedget_anesthesia_job
- First observedsearch_anesthesia_jobs

Related MCP Connectors

PackValue Tools A
io.github.umagestaointeligente
Six deterministic value tools for shopping and procurement agents.
E-commerce & Retail Finance ERP Systems
61
Waypoint Agent Observatory
site.chatgpt.youssefelshaarawy.agent-net-observatory
Useful public tools, sourced notes and opt-in research into discovery and agent cooperation.
Agent Orchestration Autonomous Agents Research & Data
1
GovCon API AOAuth
io.github.govconapi
Six tools over US federal procurement: SAM.gov, FPDS awards, entities, subawards, exclusions.
Government Data Open Data
61
Medical Terminologies MCP A
io.github.SidneyBissoli
Diagnoses, drugs & lab codes: ICD-11, LOINC, RxNorm, MeSH, ATC, CID-10. 33 tools, MIT.
Biology & Medicine Bioinformatics
33115

Related MCP Servers

Clinical Handover MCP Server
Biology & Medicine Health & Wellness
ApentengJoseph
F
license
Not graded
quality
D
maintenance
Provides structured tools for risk classification, SBAR generation, completeness validation, follow-up task extraction, and ward preference management for clinical handover coordination agents.
Updated 6 months ago (2026-05-07 00:47 UTC)
-
his-tools
Biology & Medicine
markl-a
A
license
Not graded
quality
C
maintenance
Enables LLM agents to query de-identified FHIR-shaped hospital data through audited, read-only tools for patients, encounters, conditions, observations, medications, and interaction checks, while any medication write stays a draft that a clinician must confirm out-of-band.
Updated a month ago (2026-09-28 08:29 UTC)
MIT
MedBridge
Biology & Medicine Open Data
MYASHWANTHREDDY
A
license
A
quality
C
maintenance
An MCP server that gives LLMs live access to clinical trials, FDA drug recalls, adverse-event reports, drug labels, and drug-name normalization via six validated tools.
Updated 2 months ago (2026-08-16 18:50 UTC)
6
MIT
NIH Research MCP Demo
Biology & Medicine Research & Data
vdeeplearning
F
license
A
quality
D
maintenance
Enables interaction with synthetic NIH-style clinical research data through tools for searching publications, querying patient metadata, analyzing AAA measurements, and retrieving protocol guidance.
Updated 4 months ago (2026-06-29 01:39 UTC)
5
-

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.

Resources

Need Help?