Skip to main content
Glama

Search patients

search_patients
Read-only

Search patients with an active organization connection using exact filters for name, date of birth, email, phone, or up to 25 IDs; page the full list when no filters are set.

Instructions

Patients with an active connection to the Organization, filtered with the exact-match filters the API documents (all case-insensitive; ANDed): first_name, last_name, date_of_birth, email, phone_number, or up to 25 ids. There is no partial-name search. Without filters the whole connected list is paged. Names, sex and patient number are returned; contact details, date of birth, NHS number and address only with include_contact_details (a search by email or phone still confirms that such a record exists).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsNoOnly these patient ids (at most 25)
emailNoExact email address
cursorNonext_cursor from a previous call, to continue where it stopped (send the same filters)
last_nameNoExact last name
first_nameNoExact first name
max_resultsNoMaximum number of records to return (pages of up to 100 are fetched until this is reached)
phone_numberNoExact phone or mobile number, E.164 where possible (+447700900123); a number without + or 00 is treated as UK
date_of_birthNoExact date of birth, YYYY-MM-DD
include_contact_detailsNoInclude patient contact details, date of birth, NHS number, address, third-party identifier and payment-method link, and stop redacting email addresses, phone numbers, NHS-number-shaped digit groups and UK postcodes typed into names and other text

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly/openWorld annotations, it discloses what the default response returns (names, sex, patient number), that contact details, DOB, NHS number and address require include_contact_details, and that the flag also stops redaction of text fields. It further explains that an email/phone search still confirms a record exists even without contact details — meaningful disclosure the annotations do not cover.

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 dense sentences with no filler: the connection scope and filter semantics come first, then the no-filter paging case, then return-field visibility. The parenthetical about email/phone existence confirmation is the only aside and it earns its place.

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?

There is no output schema, so the description correctly carries the burden of describing return fields and their conditional visibility, plus paging via cursor and max_results interaction. For a 9-parameter read tool with zero required parameters, nothing an agent needs to call it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds semantics the schema omits: filters are case-insensitive and ANDed, no partial-name matching, and the 25-id cap. It also explains the pagination interaction ('without filters the whole connected list is paged') rather than just the cursor parameter itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description precisely scopes the resource ('patients with an active connection to the Organization') and the operation (exact-match filtered lookup, paged list without filters), which clearly separates it from the single-record get_patient sibling. It never states an explicit verb (e.g. 'search'/'list') and names no sibling, so it falls just short of the top band.

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?

It gives concrete usage context: filters are ANDed and exact-match, up to 25 ids, and calling with no filters pages the entire connected list. It also sets a negative boundary ('There is no partial-name search'), steering the agent away from substring queries, but it never points to an alternative tool or says when get_patient should be used instead.

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