Skip to main content
Glama

FindADoctor.si New Zealand

Open New Zealand doctors

get_doctor
Read-onlyIdempotent

Evidence for New Zealand doctors from search_doctors: pass doctor_ids (up to 10 at once) or one doctor_id. Each different doctor you open counts toward a daily limit for your connection (replies show daily_doctor_limit when it matters); opening a doctor again the same day is free. Open the doctors you are seriously considering, not every result. Each doctor: specialties, title, qualifications, focus areas and subspecialties they list, further training, languages, whether their services see children; every private and public service with clinic addresses, phone numbers and websites, procedures and conditions the service lists, fee categories and fee lines, ages, hours, how to get referred, and whether it says Southern Cross Affiliated Provider or nib First Choice (insurer_notes also says whether the doctor's own page says so); the Medical Council register entry (status, scope of practice, conditions, qualifications, practising certificate); experience (each vocational scope with the date it was granted and years since, first New Zealand registration, primary medical degree year, New Zealand honours with citation, University of Auckland title and hospital appointments, approximate count of papers with a New Zealand affiliation and a link to the list); hospital website links; and source links with read dates. For a GP, services include the practice's enrolment status and fee table. Profiles are not reproduced: give the person the Healthpoint link (sources.healthpoint) for the doctor's own words.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doctor_idNoOne doctor_id from search_doctors, e.g. 'nz_4k9m2x7qph3t'.
doctor_idsNoUp to 10 doctor_ids from search_doctors, e.g. ['nz_4k9m2x7qph3t', 'nz_8w2c5n1kd7ra'].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/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=false), and the description adds substantial non-obvious behavior: a per-connection daily limit, that replies surface daily_doctor_limit when relevant, that re-opening the same doctor the same day is free, and that profile text is not reproduced (use sources.healthpoint instead). That is exactly the kind of quota/rights context annotations cannot convey.

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 first sentence is well front-loaded, but the return-value enumeration is a single ~120-word run-on sentence listing dozens of fields with semicolons. Because there is no output schema that content is load-bearing, yet it would be far more usable as a structured list, so it reads as exhaustive rather than concise.

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 carries the return-value burden and does so thoroughly, and it covers quota mechanics and the copyright/attribution constraint. What is missing is failure behavior (invalid or unknown IDs, what happens if more than 10 are passed) and any hint of the response's shape.

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 baseline is 3; the description adds real value by framing the two parameters as alternatives ('pass doctor_ids (up to 10 at once) or one doctor_id') rather than merely restating the schema, and it ties the batch size to the quota cost. It does not explain behavior when both are supplied or when the cap is exceeded.

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+resource: opens the full evidence profile for a New Zealand doctor identified by doctor_id(s) obtained from search_doctors. It is immediately distinguishable from sibling search_doctors (discovery) and list_specialties (browsing), and the 'Each doctor: ...' enumeration makes the scope of retrieval unambiguous.

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 clear context ('from search_doctors') and an explicit when-not ('Open the doctors you are seriously considering, not every result'), plus the batching affordance. It stops short of a fully explicit routing rule (e.g. 'use search_doctors to find IDs, do not call this to search'), but the workflow is easy to infer.

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