mcp-google-health

update_data_point

Replace a health data point previously written by this client, such as steps, sleep, or heart rate, by specifying its data type, resource ID, and updated payload.

Instructions

Replace a data point that this client wrote.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dataType": "<dataType>",
      "dataPointId": "<dataPointId>",
      "dataPoint": "<dataPoint>"
    },
    "name": "update_data_point"
  }
}

Input Schema

Name	Required	Description
`dataType`	Yes	Data type in kebab case, such as steps, sleep, or heart-rate. See list_data_types.
`dataPoint`	Yes	DataPoint body. Put the payload under the camelCase data type field, such as {"weight": {...}}. Call describe_schema with the data type for its fields.
`apiVersion`	No	API version. Defaults to v4, or v4beta for beta-only data types.
`dataPointId`	Yes	A resource ID without slashes.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the ownership restriction, which is genuinely beyond the annotations. It does not disclose that "Replace" is a full overwrite (fields omitted from dataPoint are dropped) or what happens to server-assigned fields, which are the behaviors an agent most needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no filler, and the ownership constraint is front-loaded where it matters. It is arguably terse for a mutation tool, but nothing in it is wasted or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter mutation tool with a nested free-form body and no output schema, the description leaves key questions open: full-replace versus merge semantics, error behavior on non-owned data points, and whether the response echoes the stored point. The rich schema offsets some of this, but the behavioral gaps remain.

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?

Schema description coverage is 100%, and the schema itself carries strong guidance (kebab-case dataType pointing to list_data_types, dataPoint pointing to describe_schema, apiVersion defaulting behavior). The description adds nothing about any of the four parameters, so the baseline of 3 is correct.

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?

"Replace a data point" names a specific verb and resource, and the qualifier "that this client wrote" narrows the scope in a way an agent can act on. It does not explicitly distinguish itself from create_data_point or delete_data_points, so the sibling separation is only implicit in the verb choice.

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 clause "that this client wrote" implies a precondition (only data points owned by this client can be replaced), which is useful routing context. However, there is no explicit when-to-use versus create_data_point or delete_data_points, and no statement about what happens when the precondition fails.

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