Fetch the FHIR server's CapabilityStatement (GET /metadata) and return a compact summary: supported resource types, interactions, search parameters, and operations. Call this first to discover what the server supports.

Search resources of a given type (GET /{resourceType}?...). Search parameters are passed through to the server as-is, so chained parameters, _has, _include, _revinclude, _sort, _total etc. all work. To keep responses small, prefer _elements (comma-separated field list) or _summary=true, and page with _count plus the returned hasNextPage flag (use params like _count/_offset or the server's paging links).

Read a single resource by type and id (GET /{resourceType}/{id}).

Fetch all resources in a patient's compartment (GET /Patient/{id}/$everything): conditions, observations, encounters, medications, etc. Use types to limit resource types and since to limit to recently-updated resources — both are recommended to keep responses manageable.

Fetch version history. With resourceType and id: history of one resource (GET /{type}/{id}/_history). With only resourceType: history across that type. With neither: system-wide history.

Validate a resource against the server's profiles without saving it (POST /{resourceType}/$validate). Use this before create_fhir/update_fhir to catch structural or terminology errors early. The resource JSON must include resourceType.