Skip to main content
Glama
Sign In

OneUptime

by com.oneuptime
OverviewDiscussionsAdmin

Get Data Store Finding

get_data_store_finding
Read-only

Get one Data Store Finding by ID.

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": {
      "id": "<id>"
    },
    "name": "get_data_store_finding"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesID.
selectNoOmit for all but maskedSamples.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"ID (UUID) of the Data Store Finding."New value: +"ID."
    • changedInput schema / properties / select / description
      Previous value: -"Field names to return. Omit for all but these large fields: maskedSamples."New value: +"Omit for all but maskedSamples."
  2. Changed2 schema fields changed
    • changedInput schema / properties / id / description
      Previous value: -"The unique identifier (UUID) of the Data Store Finding to retrieve. Example: \"550e8400-e29b-41d4-a716-446655440000\""New value: +"ID (UUID) of the Data Store Finding."
    • changedInput schema / properties / select / description
      Previous value: -"Optional: field names to return for each Data Store Finding (e.g. [\"_id\", \"name\"]). Omit to get all readable fields. Large fields excluded by default (request explicitly if needed): maskedSamples."New value: +"Field names to return. Omit for all but these large fields: maskedSamples."
  3. Added

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: no note on error behavior for an unknown ID, no mention that maskedSamples are omitted by default, and no indication of what a finding record contains.

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

Conciseness3/5

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

One short sentence with the resource and lookup key front-loaded, so there is no wasted wording. It is, however, terse to the point of under-specification rather than genuinely efficient.

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?

With no output schema, the description is the only place an agent could learn the shape of a returned finding, but it says nothing about return values or failure modes. For a single-resource read tool this leaves a meaningful 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?

Schema description coverage is 100%, so both the required id and the optional select array are documented in the schema itself, which sets the baseline at 3. The description adds no extra meaning such as the ID format or the practical effect of selecting fields.

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 uses a specific verb and resource ("Get one Data Store Finding by ID"), which is clearly distinct from list_data_store_findings and update_data_store_finding. It does not, however, name any sibling explicitly to reinforce that distinction.

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

Usage Guidelines2/5

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

There is no guidance on when to use this single-record fetch versus list_data_store_findings (filtering) or get_data_store (parent resource). The only implied condition is that an ID must already be known, which the reader has to infer from the name and schema.

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

All OneUptime toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources