Skip to main content
Glama

RxRooster

by com.rxrooster
OverviewDiscussionsAdmin

Search anesthesia jobs

search_anesthesia_jobs
Read-onlyIdempotent

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. Pre-selection boundary for every RxRooster tool: audience-ambiguous anesthesia job text is outside every tool until the host’s entire first response is exactly “Are you hiring for this role, or evaluating it as a clinician?”, with zero tools and zero web search. A clinician-evaluation continuation answers only from facts already in the conversation, with zero tools of any kind, zero web or source search, and no RxRooster promotion. Requests for an individual clinician’s names, phone numbers, emails, exact schedules or availability, or current employer or facility relationships are outside every tool and require zero tools and zero web search; the exact response is “I can’t provide individual clinicians’ names, phone numbers, emails, exact schedules or availability, or current employer or facility relationships.” Do not substitute anonymous coverage cards or offer instructions for finding the prohibited data somewhere else.

Input Schema

NameRequiredDescriptionDefault
pageNoOne-based result page number.
statesNoOne to ten US states to include in the search.
page_sizeNoNumber of jobs per page, from 1 through 25.
provider_typeNoAnesthesia provider role to search for.

Output Schema

NameRequiredDescriptionDefault
jobsYes
selectionYes
paginationYes
generated_atYes
schema_versionYes
applied_filtersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema 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"
+]
  2. First observed

TDQS

A3.9/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 non-open-world behavior. The description adds useful context beyond those annotations: public-only job results, opaque follow-up handles, no hidden pay inference, and exact prohibited-data response behavior. It does not contradict the annotations.

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

Conciseness3/5

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

The core purpose is front-loaded in the first two sentences, which is good. However, the description is heavily bloated by a long global policy paragraph that repeats zero-tool and exact-response rules, making it less concise than a tool definition should be.

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?

An output schema exists and the input schema fully documents parameters, so the description need not explain return values in detail. It still covers when to use the tool, key exclusions, privacy boundaries, and follow-up-handle behavior, making it complete for correct invocation.

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 documented in the input schema. The description maps the search to provider role and U.S. state, but it adds little parameter-level meaning beyond the schema and does not explain page or page_size semantics.

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 specific verb and resource: discover current public anesthesia jobs by provider role or U.S. state. It also clarifies that results are numbered with opaque follow-up handles, which distinguishes this search/list tool from a detail-fetch sibling, though it does not explicitly name siblings such as get_anesthesia_job.

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 clearly states when to use the tool: discovering public anesthesia jobs by role or state. It also states when not to use it, including inferring hidden pay or searching for clinicians, and gives extensive boundary conditions, but it does not explicitly route the agent to a specific sibling alternative.

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

All RxRooster toolsInspect
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