Skip to main content
Glama

TunnelMind Data API

by ai.tunnelmind

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

  • 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.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses a rich set of behaviors: inline Ed25519 signing with key source, Receipt v1.0 envelope wrapping via ?receipt=true, content negotiation via Accept headers, free anonymous access with a separate rate-limit counter, and latency expectations (<100ms typical, <500ms cold). This is far beyond what structured fields would provide.

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?

Although lengthy, the description is excellently structured with labeled sections (Inputs, Content negotiation, Returns, Headers, Cost, Latency) and is front-loaded with the core purpose. Every sentence carries useful information; the bullet-style lists make it easily scannable for an agent.

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?

The tool is complex (config bundle, content negotiation, signing, versioning, surfaces) and has no output schema. The description enumerates the returned fields (version, schema, issuer, system_prompts, tools.surface_subset, response_format, attestation_tiers, graph_state, references, bundle_signature, pin_recommended), lists relevant headers, and explains cost and latency. This is comprehensive enough for an agent to invoke and parse responses correctly.

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?

Schema description coverage is 67% (receipt and version have descriptions; surface does not). The description adds meaning beyond the schema: clarifies surface default as 'full surface', explains version pinning with '1' for latest 1.x.y, and introduces Accept header content negotiation not present in the schema. It doesn't fully explain the scry/sigil surfaces, but adds enough to merit above baseline.

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 opens with a specific verb and resource: 'Returns the TunnelMind analyst config bundle.' It clearly distinguishes from sibling data tools by positioning itself as the canonical config endpoint and explicitly excluding individual data tool calls in the 'Do NOT use' section, naming alternatives like check_receipt_revoked and @tunnelmindai/receipt-verify.

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?

Provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections with concrete scenarios (configuring a new LLM runtime, verifying the system prompt, BYOM deployments) and named alternatives (use data tools directly, check_receipt_revoked). This gives clear guidance for an agent to select this tool over siblings.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.3/5.0
Disambiguation2/5

Many tools overlap in purpose, such as cross_lens_verify, cross_lens_lookup, profile_entity, and preflight_should_i_act, which all return node verdicts with subtle differences. Sigil verification tools and receipt-related tools also have similar names and require deep reading to distinguish.

Naming Consistency3/5

The tool names are mostly readable, but the pattern is mixed: some use verb_noun (get_domain, create_subscription) while others use domain prefixes (sigil_*, ghostroute_*, intel_*). Within each domain, naming is consistent, but the overall style lacks uniformity.

Tool Count1/5

With 90 tools, this server is extremely overloaded. Even for a multi-purpose data API, the sheer number overwhelms and makes navigation difficult, far exceeding the typical well-scoped MCP server. The count is an extreme mismatch for the apparent scope.

Completeness4/5

The tool surface is very comprehensive, covering tracker lookup, cross-lens verification, receipts, compliance, subscriptions, tasks, intel probes, and more. Minor gaps exist, such as no batch cross-lens verification, but core workflows are well covered.

Resources