Skip to main content
Glama

Find New Zealand general practices

search_gp_practices
Read-onlyIdempotent

New Zealand only. Free list of New Zealand general practices (GP clinics), or urgent care clinics, near a place, from Healthpoint. Use it when the person needs a GP, wants to enrol with a practice, or needs urgent but not emergency care. Each practice: whether it says it is enrolling new patients (yes; restricted = only some people, e.g. family of patients or people living nearby; no; does not apply = urgent care that does not enrol; unknown = the page does not say), the practice's own enrolment note, its fee table (the first fee table on its page, usually fees for enrolled patients by age, without and with a Community Services Card; with age, the row for that age), addresses, phone numbers, website, online booking link, languages, hours, the doctors listed there (doctor_ids for get_doctor) and the date Healthpoint says the page was last updated. In New Zealand most people enrol with one general practice: visits cost less once enrolled, and a GP referral is the usual way to a public specialist. Give place or name. Practices are not doctors, so this does not count toward the daily doctor limit. Enrolment and fees change often: tell the person to phone the practice to confirm.

Input Schema

NameRequiredDescriptionDefault
ageNoThe patient's age: each result then shows the fee row for that age.
kindNogp = general practices (default; also nurse-led, online, student and rest-home practices, named so in each result's kind); urgent_care = accident and urgent medical care and after-hours clinics (no enrolment needed); any = both.
nameNoPractice name or part of it, to check a named practice.
limitNoDefault 10.
placeNoNew Zealand city, suburb or region (e.g. 'Papanui', 'Hamilton', 'North Shore', 'Canterbury').
offsetNoFor paging (at most 40).
languageNoLanguage other than English the practice lists, e.g. 'Mandarin', 'Samoan', 'te reo Maori'.
enrollingNoyes = only practices that say they are enrolling new patients; yes_or_restricted also keeps practices enrolling only some people (read enrolling_note). Default any (enrolling practices come first).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

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, non-destructive, idempotent), but the description adds real behavioral context beyond them: NZ-only, free, the daily doctor limit exclusion, and a data-freshness caveat ('Enrolment and fees change often: tell the person to phone the practice to confirm'). It does not describe paging/limit behavior in prose, so it stops short of full marks.

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 leading sentences are well front-loaded (NZ-only, free, when-to-use), but the long middle sentence enumerating every returned field reads as a dense run-on. With no output schema this detail is defensible, yet the structure is heavy and not easy to scan.

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?

No output schema exists, so the description must describe return fields — and it does so thoroughly (enrolment, fees, addresses, phones, hours, doctors, last-updated). Combined with the annotations' safety profile and the usage framing, an agent has enough to call it correctly; only paging/limit prose is thin.

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 description coverage is 100%, so a baseline of 3 applies; the description nonetheless adds meaning to the 'enrolling' enum by expanding restricted/no/does-not-apply/unknown, which the schema only partially covers. It also ties doctor_ids to get_doctor and explains the age-to-fee-row relationship.

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+scope: 'Free list of New Zealand general practices (GP clinics), or urgent care clinics, near a place.' It explicitly disambiguates from the sibling search_doctors ('Practices are not doctors'), so an agent can distinguish it without opening a schema.

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 trigger conditions: 'when the person needs a GP, wants to enrol with a practice, or needs urgent but not emergency care,' plus 'Give place or name.' It implies but never names the alternative tool to use for doctors, so the routing guidance is clear but not fully explicit.

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