Telemetry Machine

Get widgets

get_widgets

Read-only

List, get or run saved widgets, through the Telemetry Machine REST API (https://telemetrymachine.com/docs/api.md). query runs a saved widget (body: {"time_range"?: {"last": "1h"}, "filters"?: [...]}, the filters ANDed with its own); preview runs an unsaved one (body: {"definition": ...}); schema gives the JSON Schema of a widget.

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": {
      "action": "<action>"
    },
    "name": "get_widgets"
  }
}

Input Schema

Name	Required	Description
`id`	No
`body`	No	The JSON body the action takes.
`limit`	No
`action`	Yes
`offset`	No
`search`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026
- changedInput schema / properties / body / additionalProperties
```
Previous value: -{}New value: +true
```
First observedOct 30, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description adds real behavioral context: it names the backing REST API and documents the body shapes for query and preview, including the important detail that supplied filters are ANDed with the widget's own filters. It does not cover pagination behavior, defaults, or error conditions for the lookup actions, which keeps it below a 5.

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?

Information-dense and front-loaded: verbs and resource first, then per-action body semantics, with no filler. The single semicolon-chained sentence is slightly compressed for the amount of structure it carries, but every clause adds distinct meaning.

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

Completeness3/5

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

For a 6-parameter, nested-body tool with no output schema, the description covers the riskiest unknowns (action semantics and body payloads) but leaves the list/get path, paging parameters, and any hint of return shape undocumented. An agent can call query and preview confidently, but must guess on list, get, and result handling.

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 only 17%, so the description carries most of the burden — and it does explain the hardest parameter (body) for the query and preview actions, including the time_range/filters shape. However, id, limit, offset, and search get no explanation at all, and the description never states which action requires id or how body is ignored for list/get, so the compensation is only partial.

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 gives specific verbs and a clear resource ('List, get or run saved widgets') and then maps the non-obvious actions (query, preview, schema) to what they do, so an agent can tell what the tool covers. It stops short of differentiating itself from siblings like edit_widgets, run_query, or get_query_result, so the boundary with the rest of the surface is left implicit.

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?

Action-level guidance is present and genuinely useful: query is for a saved widget, preview for an unsaved definition, schema for the JSON Schema. What's missing is tool-level routing — nothing says when to pick get_widgets over run_query/get_query_result, or when this is preferable to edit_widgets for inspecting a definition.

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

All Telemetry Machine tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?