doctoreto-mcp

Overview Schema Source Related Servers Discussions Admin

Search centers

dt_search_centers

Read-onlyIdempotent

Find hospitals, clinics, labs, imaging centers, and pharmacies by city, neighborhood, type, speciality, ownership, 24-hour status, online lab admission, or distance.

Instructions

Find hospitals, clinics, infirmaries, laboratories, imaging centers and pharmacies with filters.

Cards carry the hash id for dt_center. With near_lat and near_lon it searches a square around the point sorted by distance; dense areas return only part of the centers and count the rest in more_in_area. Without them limit cuts the upstream page (on_page items). No insurance filter: see dt_center. Next: dt_center, dt_reviews(of='center').

Input Schema

Name	Required	Description
`city`	No	City slug from dt_cities, e.g. 'tehran'.
`name`	No	Part of the center's name in Persian, e.g. 'قلب'.
`page`	No	1-based page number.
`type`	No	Kind of center, e.g. 'laboratory'.
`limit`	No	Centers per page (the API pages by 20).
`near_lat`	No	Latitude of a point in Iran, e.g. 35.7575.
`near_lon`	No	Longitude of a point in Iran, e.g. 51.4100.
`open_24h`	No	Only centers open around the clock (pharmacies, hospitals).
`ownership`	No	State (public) or private.
`radius_km`	No	With near_lat/near_lon: half-width of the square searched, in km.
`speciality`	No	Department / speciality slug from dt_specialities, e.g. 'ophthalmologist'.
`service_tag`	No	Service tag slug from dt_suggest, e.g. 'mri'.
`neighborhood`	No	Neighborhood slug from dt_neighborhoods, with city only, e.g. 'pasdaran'.
`online_lab_admission`	No	Only laboratories that take online admission bookings.

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv0.3.0Oct 17, 2026
- removedInput schema / properties / city / title
```
Removed value: -"City"
```
- removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
- removedInput schema / properties / name / title
```
Removed value: -"Name"
```
- removedInput schema / properties / near_lat / title
```
Removed value: -"Near Lat"
```
- removedInput schema / properties / near_lon / title
```
Removed value: -"Near Lon"
```
- removedInput schema / properties / neighborhood / title
```
Removed value: -"Neighborhood"
```
- removedInput schema / properties / online_lab_admission / title
```
Removed value: -"Online Lab Admission"
```
- removedInput schema / properties / open_24h / title
```
Removed value: -"Open 24H"
```
- removedInput schema / properties / ownership / title
```
Removed value: -"Ownership"
```
- removedInput schema / properties / page / title
```
Removed value: -"Page"
```
- removedInput schema / properties / radius_km / title
```
Removed value: -"Radius Km"
```
- removedInput schema / properties / service_tag / title
```
Removed value: -"Service Tag"
```
- removedInput schema / properties / speciality / title
```
Removed value: -"Speciality"
```
- removedInput schema / properties / type / title
```
Removed value: -"Type"
```
- removedInput schema / title
```
Removed value: -"dt_search_centersArguments"
```
- changedOutput schema / (root)
```
Previous value: -{
-  "additionalProperties": true,
-  "title": "dt_search_centersDictOutput",
-  "type": "object"
-}New value: +null
```
First observedv0.1.0Oct 6, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes further with non-obvious behavior: proximity search returns a square around the point sorted by distance, dense areas return only a partial set with the remainder counted in `more_in_area`, and without coordinates `limit` truncates the upstream page rather than filtering. It also discloses the output card key (`id`). It stops short of anything about rate limits or error behavior.

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?

Purpose is front-loaded in one sentence, then behavior in a short second block; nothing is decorative. Some phrasing is telegraphic ('Cards carry the hash `id`') and the near/remote pagination distinction takes a second read, but the density is justified for a 14-parameter search tool.

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

Completeness4/5

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

With 14 optional parameters and no output schema, the description does the heavy lifting: it explains what gets returned (cards keyed by `id`), how paging behaves in both search modes, and the truncation signal `more_in_area`. Missing only a sketch of the overall response envelope, but the agent has enough to call and interpret results.

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%, so the baseline is 3, but the description adds cross-parameter semantics the schema cannot express: radius_km is only meaningful together with near_lat/near_lon, it defines a square half-width rather than a circle, and limit interacts with the API's 20-item page size differently depending on whether coordinates were supplied. That materially reduces misuse of these 14 parameters.

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?

Opens with a concrete verb and an explicit enumeration of the resource it covers (hospitals, clinics, infirmaries, laboratories, imaging centers, pharmacies), which cleanly scopes it away from dt_search_doctors and dt_search_offers without needing to name them. An agent knows immediately this is the facility-search 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?

Gives real routing guidance: 'No insurance filter: see dt_center' names the alternative for a filter this tool lacks, and 'Next: dt_center, dt_reviews(of=center)' tells the agent how to drill down after a hit. It also implicitly distinguishes the near_lat/near_lon path from the plain-listing path, though it never states an explicit exclusion or prerequisite condition.

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

Deploy Server

Search centers

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools