Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind
OverviewDiscussionsAdmin

get_analyst_config

Returns the TunnelMind analyst config bundle. Configures any LLM (Claude, GPT, Gemini, local) to behave as a TunnelMind analyst that knows the data graph, follows the 5-call golden path, and surfaces attestation_tier on every claim.

The bundle is signed inline (Ed25519, key_id from /.well-known/receipt-signing-key.json). Add ?receipt=true to wrap the response in a Receipt v1.0 envelope for end-to-end audit.

Use this tool when:

  • You want to configure a new LLM runtime to act as a TunnelMind analyst

  • You want to verify the system prompt you're running matches what TunnelMind serves

  • You're building a BYOM (bring-your-own-model) deployment and need the canonical config

Do NOT use this tool when:

  • You want to call individual TunnelMind data tools — use the tools directly

  • You want to verify a specific receipt — use check_receipt_revoked or @tunnelmindai/receipt-verify

Inputs (all optional):

  • surface (query): "data" (default, full surface), "scry", or "sigil"

  • version (query): pin a specific bundle version (e.g. "1.0.0" or "1" for latest 1.x.y)

  • receipt (query): "true" to wrap the response in a signed Receipt v1.0 envelope

Content negotiation (via Accept header):

  • application/json (default) — full bundle JSON

  • text/markdown — system prompt only (Anthropic flavor)

  • application/vnd.anthropic.config+json — Anthropic-shaped subset

  • application/vnd.openai.config+json — OpenAI-shaped subset

Returns:

  • version, schema, issuer, surface, surface_label

  • system_prompts.{anthropic,openai,generic} — three encodings of the same semantic prompt

  • tools.surface_subset — array of operationIds for this surface (null = all)

  • response_format — JSON Schema the analyst's verdicts must conform to

  • attestation_tiers — the 4-tier vocabulary (self_asserted → silicon_root)

  • graph_state — live corpus counts at serve time (best-effort, any may be absent: observations_total from the scry stats cache, with observations_as_of = the ISO time that cached scry block was fetched, which may lag as_of_ms by up to the KV TTL (~30 days); tracker_entities_total, sells_through_total, oai_registry_total from Supabase estimated counts)

  • references — URLs to the rest of the open-protocol layer

  • bundle_signature — inline Ed25519 signature for offline verification

  • pin_recommended — stable supply-chain identifier (survives hourly graph_state updates)

Headers: X-Bundle-Version, X-Pin-Recommended, ETag, X-RateLimit-*.

Cost:

  • Free, anonymous-accessible. Rate-limited on a SEPARATE counter from data-API calls (cfg:ip:<ip> identity) so a config refetch loop can't burn your data quota.

Latency:

  • Typical <100ms (cached); cold fetch <500ms (live Supabase counts).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
receiptNoWhen true, wrap the bundle in a Receipt v1.0 envelope.false
surfaceNodata
versionNoPin a specific bundle version. Omit for latest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose a lot: inline Ed25519 signing, key_id source, rate limiting on a separate counter from data-API calls, free/anonymous access, and latency expectations. It is largely complete for a read tool; the gaps are minor (rate-limit ceilings, behavior on unknown version pins).

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?

Long but well-organized with a front-loaded purpose sentence followed by when/when-not bullets, inputs, content negotiation, returns, headers, cost, and latency. Every section earns its place given no output schema, though the verbose Returns enumeration could be tightened. Structure is excellent, so the length is defensible.

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?

No output schema and no annotations exist, so the description compensates fully by enumerating return fields, signature/verification mechanism, content negotiation, headers, cost, and latency. An agent has everything needed to call and interpret this tool without opening other artifacts.

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 coverage is 67%; receipt and version already have schema descriptions, and surface has an enum but no description. The description adds meaning beyond the schema for surface (default 'data' = full surface) and version ('1' for latest 1.x.y) plus content-negotiation behavior via the Accept header. That is useful incremental context over the structured fields, but it does not deepen the individual parameter semantics much.

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?

Opening sentence gives a specific verb+resource ('Returns the TunnelMind analyst config bundle') and immediately qualifies its scope: a canonical config that configures an LLM to act as a TunnelMind analyst. It is clearly distinguishable from sibling data tools and from check_receipt_revoked / receipt-verify, which it names explicitly.

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?

Dedicated 'Use this tool when' and 'Do NOT use this tool when' blocks name concrete scenarios (configuring a new runtime, verifying a running system prompt, BYOM deployment) and route the agent elsewhere for the excluded cases by naming the alternative tools. Nothing is left to inference.

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

All TunnelMind Data API 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