Skip to main content
Glama
sikcapri

SuperGlookoQuery

by sikcapri
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

Preview a schema registry contribution (step 1 of 2)

get_registry_contribution_report
Read-only

Generate a privacy-safe discovery report of device field names and types for patient review, then confirm before submitting to the schema registry.

Instructions

Builds the privacy-guardrailed discovery report for this account's device(s) — step 1 of contributing to the public schema registry. Contains NO real values from the account: every example is a fixed, fabricated placeholder (see docs/DESIGN.md section 2b); only field names, types, and how often each is populated are real.

CRITICAL — how to use this: show the patient the FULL entries array verbatim (every field, every example, exactly as returned — never summarise, paraphrase, or omit any of it) and the disclaimer text, then ask them to type the exact confirmation phrase in requiredPhrase if and ONLY if they have personally reviewed it and confirm it contains nothing sensitive. Do NOT proceed to submit_registry_contribution on the patient's behalf without them actually typing that phrase themselves — a paraphrase, a "yes", or your own judgement that it looks fine are not acceptable substitutes for this gate. When they do confirm, call submit_registry_contribution with confirmationPhrase set to EXACTLY what they typed and reportHash set to EXACTLY this call's own reportHash value.

Returns: generatedAt, disclaimer, requiredPhrase (the exact string the patient must type), entries (one per device component: component, deviceName, slug, discoveredAt, windowDaysActual, lowConfidence, fields), and reportHash (an opaque integrity token for the next call — not meant to be shown to the patient).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals critical behavior: it contains NO real values, only fabricated placeholders, and reportHash is an opaque integrity token not meant for the patient. It also openly describes the confirmation gate and warns against substituting judgment. No contradiction with annotations exists.

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?

The description is front-loaded with the core privacy guarantee and then the critical usage gate, and it is well structured with a return summary. It is longer than average due to safety-critical repetition, but nearly every sentence earns its place. A small amount of redundancy could be trimmed without losing meaning.

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?

With no parameters, no output schema, and only a readOnly annotation, the description carries the full burden of explaining the tool. It completely specifies the returned fields, their semantics, how to use them in the follow-up call, and the confirmation requirement. An agent has everything needed to call it correctly and safely.

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

Parameters4/5

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

The tool has zero parameters, so there are no parameter semantics to clarify. The description appropriately explains the outputs that matter for the next call, including requiredPhrase and reportHash. This matches the 0-parameter baseline of 4.

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 clearly states the tool builds a discovery report and is step 1 of 2 for contributing to the schema registry. It explicitly differentiates itself from submit_registry_contribution and from the many read-only data retrieval siblings. The verb 'Builds' plus the resource and step context make the purpose unambiguous.

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

Usage Guidelines5/5

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

The description provides an explicit, detailed usage flow: show the full entries verbatim, obtain the patient's exact typed phrase, then call submit_registry_contribution with confirmationPhrase and reportHash. It also states what not to do, such as proceeding on a paraphrase or 'yes', and names the next sibling to call. This is exceptionally clear guidance.

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

Install Server

Other Tools