doctoreto-mcp

Overview Schema Source Related Servers Discussions Admin

Search doctors

dt_search_doctors

Read-onlyIdempotent

Search Iranian doctors by city, speciality, neighborhood, insurance, gender, or visit type to find matching results and doctor IDs for checking free appointment slots.

Instructions

Search doctors by city, speciality, neighborhood, service tag, name, gender, insurance and visit type.

Cards carry the hash id for dt_doctor; online prices are not in cards (use dt_doctor). Next: dt_doctor -> dt_free_slots.

Input Schema

Name	Required	Description	Default
`city`	No	City slug from dt_cities, e.g. 'tehran'. Omit for the whole country.
`name`	No	Doctor's name in Persian (part is enough), e.g. 'پرآذران'.
`page`	No	1-based page number.
`sort`	No	default = site ranking (sponsored first); popular = reviews and recommend rate.	default
`limit`	No	Doctors per page (about 1 KB each).
`gender`	No	Only male or only female doctors.
`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.
`speciality`	No	Speciality slug from dt_specialities or dt_suggest, e.g. 'cardiologist'.
`visit_type`	No	Only doctors offering this visit; instant = on-call phone/text now.
`service_tag`	No	Service or symptom tag slug from dt_suggest, e.g. 'echocardiography'.
`neighborhood`	No	Neighborhood slug from dt_neighborhoods, with city only, e.g. 'pasdaran'.
`has_free_slot`	No	Only doctors with a free appointment slot.
`insurance_ids`	No	Insurance ids from dt_insurances (any of them), e.g. [1]. Few doctors list insurances.

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedv0.3.0Oct 17, 2026

removedInput schema / properties / city / title
```
Removed value: -"City"
```
removedInput schema / properties / gender / title
```
Removed value: -"Gender"
```
removedInput schema / properties / has_free_slot / title
```
Removed value: -"Has Free Slot"
```
removedInput schema / properties / insurance_ids / title
```
Removed value: -"Insurance Ids"
```
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 / page / title
```
Removed value: -"Page"
```
removedInput schema / properties / service_tag / title
```
Removed value: -"Service Tag"
```

changedInput schema / properties / sort / description

Previous value: -"default = site ranking (sponsored first), popular = review count and recommend rate, earliest = soonest free slot, most_booked = most bookings."New value: +"default = site ranking (sponsored first); popular = reviews and recommend rate."

removedInput schema / properties / sort / title
```
Removed value: -"Sort"
```
removedInput schema / properties / speciality / title
```
Removed value: -"Speciality"
```

changedInput schema / properties / visit_type / description

Previous value: -"Only doctors offering this visit: office (in person), phone, text (chat), video, instant (on-call phone/text now), any_online."New value: +"Only doctors offering this visit; instant = on-call phone/text now."

removedInput schema / properties / visit_type / title
```
Removed value: -"Visit Type"
```

removedInput schema / title

Removed value: -"dt_search_doctorsArguments"

changedOutput schema / (root)

Previous value: -{
-  "additionalProperties": true,
-  "title": "dt_search_doctorsDictOutput",
-  "type": "object"
-}New value: +null

First observedv0.1.0Oct 6, 2026

TDQS

A4.2/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, openWorld), so the bar is lower; the description still adds genuinely useful payload context that no schema provides — result cards carry the hash `id` for dt_doctor and omit online prices. It does not mention auth needs, pagination limits, or result caps beyond what the schema implies.

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 front-loaded sentences: the filter summary first, then the payload caveat, then the follow-up workflow. Every sentence carries information and nothing is padded.

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?

For a 14-parameter read tool with no output schema, the description covers the essentials an agent needs: what filters exist, what a card contains, what it omits, and where to go next. It stops short of describing result shape or pagination behavior in full, but annotations already carry the safety profile.

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% across all 14 parameters, so each filter's slug source, defaults, and examples are already documented in the schema. The description's filter list restates those dimensions in aggregate without adding syntax or constraints, which is the expected baseline-3 case.

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?

States a specific verb (Search) and resource (doctors) and enumerates the filterable facets, making it easy to distinguish from dt_search_centers. It also names the downstream tools that operate on a result (dt_doctor, dt_free_slots), so the agent knows exactly what this tool returns.

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?

Explicitly routes the agent away from this tool for pricing ('online prices are not in cards (use dt_doctor)') and names the follow-up chain 'dt_doctor -> dt_free_slots'. There is no explicit when-not-to-use for search itself (e.g. vs dt_suggest for slug discovery), but the context and alternative are clear.

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

Deploy Server

Search doctors

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools