Skip to main content
Glama

FindADoctor.si France

Search doctors in France

search_doctors
Read-onlyIdempotent

Free short list of doctors in France for a need; use it first whenever the person needs a doctor, specialist or GP in France. Give at least one of need, specialty, place, name or hospital_finess. need = condition, procedure or focus, in French or English (e.g. 'endométriose', 'prothèse genou', 'knee replacement', 'cataract'; common English words are also searched in French); matched against the expertise and procedures doctors state, their official competences and university diplomas, hospital departments and roles, and specialty. specialty = French or English (e.g. 'cardiologie', 'dermatology', 'pédiatre', 'ORL', 'GP', 'généraliste'). place = city ('Lyon', 'Paris' includes all arrondissements), postcode ('75015'), arrondissement ('Paris 15', 'Lyon 3e'), département number ('69', '2A') or a practice or hospital name; a text match on practice addresses, not a distance search. Each result: doctor_id, name, gender, specialties (French, as registered), specialties_en, places (up to 3 practices, the ones matching place first), fee_sectors (Ameli category: Secteur 1 = standard fees; Secteur 2 = may charge extra; Non conventionné = not contracted, little reimbursed), optam (agreed to limit extra fees), match_basis (with a need: stated_expertise, official_competence, hospital_department_or_training, several_fields, specialty, specialty_usually_treats, partial), register (rpps, ameli_only = only in the Assurance Maladie directory, website_only = not matched to the official registers), warnings (e.g. barred from practising) and detail_has (what get_doctor adds). With a need, results are ranked by how directly the doctor's own data matches it: all its words in the expertise or procedures the doctor states, then in official competences or university diplomas, then in hospital department, role or training, then spread over several fields, then in the specialty name; then, when the need is a condition few doctors list, doctors in the specialty that usually treats it (specialty_usually_treats); then doctors matching only some of the words. Without a need, doctors with more data (stated expertise, official competences, profile pages) come first, then in a fixed shuffled order. Not ranked by quality, outcomes, fees or industry links. Then call get_doctor with the doctor_ids you are considering. Up to 10 results per search and paging stops at 30: narrow the need or the place instead of paging.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDoctor's name or part of it, to check a named doctor.
needNoCondition, procedure or focus, in French or English.
limitNoDefault 10.
placeNoCity, postcode, arrondissement ('Paris 15'), département number ('69', '2A') or a practice or hospital name.
genderNoOnly when the person asks. From the register's civil title (Madame/Monsieur); recorded for almost all doctors.
offsetNoFor paging (at most 20, so 30 results in all: narrow the search instead).
languageNoLanguage other than French, e.g. 'English', 'Arabic', 'anglais'. Only known for doctors with a Maiia or hospital profile (about 1,800 list one); many others speak it too.
specialtyNoSpecialty in French or English, e.g. 'cardiologie', 'dermatology', 'ORL', 'GP' (see list_specialties).
fee_sectorNoAssurance Maladie fee category. secteur_1 = standard fees, no extra charges; secteur_1_or_optam = standard fees or agreed limits on extra fees; secteur_2 = may charge extra. Kept if ANY of the doctor's practices has it (it can differ by practice): check each practice in get_doctor. Most hospital-only doctors have no category. Default any.
online_bookingNoTrue keeps doctors whose Maiia or hospital page shows online booking (Doctolib is not covered).
hospital_finessNoKeep doctors whose register address is this hospital site (FINESS number from hospital_procedure_volumes): mostly salaried hospital doctors.
teleconsultationNoTrue keeps doctors offering video consultations on Maiia.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safe-read profile, and the description goes well beyond them: ranking order and match_basis tiers, the fallback to specialty_usually_treats, the explicit 'not ranked by quality, outcomes, fees or industry links' disclaimer, register caveats (ameli_only, website_only, warnings such as barred from practising), and hard limits (10 per search, paging stops at 30). This is unusually rich disclosure for a read-only tool.

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?

Front-loaded with purpose and the use-first rule, then result fields, then ranking, then the get_doctor handoff. Every block carries information, though the result-field enumeration and the ranking walkthrough are dense and slightly repetitive ('common English words are also searched in French'), making it longer than strictly necessary.

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 no output schema, the description carries the full burden and does so: it enumerates the returned fields (doctor_id, specialties_en, fee_sectors, match_basis, register, warnings, detail_has) and explains what each means. Nothing an agent needs to call or interpret this tool 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%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot: the at-least-one-of constraint, that need is matched against stated expertise, official competences, diplomas, hospital departments and specialty, and that place is a text match on addresses rather than a distance search. Marginal value is added over an already thorough schema.

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 and resource ('short list of doctors in France for a need') and explicitly positions itself relative to the sibling it is not ('Then call get_doctor with the doctor_ids you are considering'). An agent can tell it apart from get_doctor, list_specialties and hospital_procedure_volumes 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?

Gives an explicit use-first rule ('use it first whenever the person needs a doctor, specialist or GP in France'), names the follow-up tool (get_doctor), and states the alternative to paging ('narrow the need or the place instead of paging'). It also states the minimum input requirement ('Give at least one of need, specialty, place, name or hospital_finess').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources