Skip to main content
Glama

Resolve user by client_user_id

vital_resolve_user
Read-only

Look up a Vital user by your own client_user_id (the stable id you assigned). Vital API: GET /v2/user/resolve/{client_user_id}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_user_idYesYour own stable id for the user.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

readOnlyHint=true already covers the safety profile, and the description consistently describes a read-only GET operation. It adds the endpoint but does not disclose behavior such as what happens when the client_user_id is not found or any rate limits. With annotations carrying the load, a 3 is appropriate.

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 one concise, front-loaded sentence that includes the essential endpoint. Every word earns its place; there is no filler or redundant explanation.

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?

For a simple one-parameter read-only lookup, the description plus schema and annotations are sufficient for an agent to invoke it correctly. It does not state the return shape, but with no output schema and a straightforward 'look up a Vital user' framing, this is a minor gap.

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 schema has 100% coverage for the single parameter, and the description essentially repeats the schema's description ('your own stable id for the user'). No additional semantic information is provided, so the parameter-semantics baseline of 3 applies.

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 states a specific verb ('Look up'), the resource ('Vital user'), and the lookup key ('your own client_user_id'). It clearly conveys what the tool does, though it does not explicitly differentiate itself from sibling tools like vital_get_user or vital_list_users.

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?

The description gives clear context for when to use this tool: when you have your own stable client_user_id. It does not explicitly name alternatives or state when not to use it, so it misses the full exclusions that would make it a 5.

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.

TDQS

A3.6/5.0
Disambiguation5/5

Each tool maps to a unique resource/action pairing—users, health summaries, timeseries, providers, and lab orders—so an agent can reliably distinguish them. Even similarly named getters are separated by the data domain (activity/body/sleep/workouts) and description.

Naming Consistency4/5

All tools use the vital_ prefix and snake_case verb_noun forms, which is highly predictable. Minor inconsistency: get is used for both single-resource fetches and list-returning calls (get_workouts, get_user_connected_providers) while list is reserved for global collections.

Tool Count4/5

21 tools is on the heavier side, but the breadth of the Vital API—users, providers, many health summary types, timeseries, and lab tests/orders—justifies most of them. It is slightly over a typical focused MCP server but not bloated or redundant.

Completeness3/5

The read side is strong: users, providers, summaries, timeseries, lab tests, and results are all covered. However, there are no update/delete user operations and no way to create a lab-test order, so core lifecycle/workflow gaps remain.