Skip to main content
Glama
sepehr071

doctoreto-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Suggest doctors, specialities and centers

dt_suggest
Read-onlyIdempotent

Generate search-box suggestions for Persian doctor queries, returning matching doctors, specialty slugs, service tags, and centers; rank results by city to guide next searches.

Instructions

Search-box suggestions: doctors (hash id), speciality slugs, service tags and centers for a free phrase.

E.g. 'قلب' -> speciality 'cardiologist'. Doctors match by name, so for a speciality use the slug. Next: dt_search_doctors, dt_doctor or dt_center.

Input Schema

NameRequiredDescriptionDefault
limitNoMax items of each kind.
queryYesWhat the user typed, in Persian: a doctor's name, a speciality or a symptom, e.g. 'قلب' or 'پرآذران'.
city_idNoNumeric city id from dt_cities to rank one city first, e.g. 2200 (Tehran).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.0
    • removedInput schema / properties / city_id / title
      Removed value: -"City Id"
    • removedInput schema / properties / limit / title
      Removed value: -"Limit"
    • removedInput schema / properties / query / title
      Removed value: -"Query"
    • removedInput schema / title
      Removed value: -"dt_suggestArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "dt_suggestDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld). The description adds genuinely useful behavioral detail beyond them: what each suggestion kind looks like (hash id vs slug vs tag), and the semantic caveat that doctors match by name only. It stops short of covering empty-result or ordering behavior.

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?

Extremely tight: a one-line purpose, a clarifying example, and a routing line. The most important information (what it returns) is front-loaded with zero 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?

With no output schema, the description does the work of describing result kinds and their identifier formats, which is the critical missing piece for an agent. It could go slightly further on result structure or ordering, but an agent has enough to call it correctly.

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 coverage is 100%, so query, limit and city_id are fully documented in structured fields. The description only adds a slight nuance about slug-vs-name matching for the query term, which is close to what the schema example already conveys. Baseline 3 is correct.

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 function (search-box suggestions), enumerates the four result kinds (doctors by hash id, speciality slugs, service tags, centers), and scopes it to a free-text phrase. It is clearly a lightweight autocomplete-style tool, distinct from dt_search_doctors and dt_center, which it names.

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 a concrete routing rule and the exact follow-up tools ('Next: dt_search_doctors, dt_doctor or dt_center'), plus a usage hint that speciality lookups should use the returned slug rather than the doctor name. It lacks an explicit when-not-to-use clause (e.g. for full result sets) but the context is clear.

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

Deploy Server

Other Tools