Google Health MCP — Remote

Google Health Data Inventory

google_health_data_inventory

Read-onlyIdempotent

Lists supported Google Health data types, auth scopes, privacy modes and recommended first calls, so you can plan queries without calling Google APIs.

Instructions

Inventory supported Google Health data types, auth scopes, privacy modes and recommended first calls without calling Google APIs.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "google_health_data_inventory"
  }
}

Input Schema

Name	Required	Description	Default
`response_format`	No		markdown

Output Schema

Name	Required	Description	Default
`auth`	No
`kind`	Yes
`links`	Yes
`notes`	Yes
`scopes`	Yes
`source`	Yes
`totals`	Yes
`mcp_name`	Yes
`categories`	Yes
`unofficial`	Yes
`first_tools`	Yes
`api_boundary`	No
`generated_at`	Yes
`privacy_modes`	Yes
`data_access_model`	Yes
`recommended_agent_flow`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Nov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the important behavioral detail that it works 'without calling Google APIs', meaning it has no external side effects and is purely informational. This goes beyond the annotations and helps an agent understand the tool's operational profile.

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?

The description is a single, tight sentence that front-loads the primary purpose ('Inventory supported Google Health data types') and then appends the additional included categories and the no-API-call qualifier. Every word earns its place; there is no filler or redundancy.

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?

The tool has zero required parameters, an output schema, and annotations covering its read-only/idempotent behavior. The description adds the crucial offline nature and enumerates the inventory categories. Nothing essential is missing for a tool of this simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, response_format, is clearly structured with an enum of 'markdown' and 'json' plus a default, so its meaning is essentially self-evident. However, the schema description coverage is 0% and the tool description does not mention this parameter at all. The description adds no semantic value beyond the schema, though the parameter is simple enough that this is a minor gap.

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?

The description uses a specific verb ('Inventory') and clearly names the resource scope: supported Google Health data types, auth scopes, privacy modes, and recommended first calls. It also distinguishes itself from live API calls by adding 'without calling Google APIs', which separates it from siblings like google_health_list_data_types that may make actual API requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool—when you need an offline inventory of data types, scopes, privacy modes, and first calls—but it does not explicitly state when to choose this over alternatives or name sibling tools. There is no exclusion guidance (e.g., 'use list_data_types when you need only data types'), leaving the agent to infer the routing decision.

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