Skip to main content
Glama

TunnelMind Data API

generate_receipt

Looks up each submitted domain in the TunnelMind tracker database, aggregates risk metrics (avg score, max score, fingerprinters, high-risk domains, entity ownership), and issues a signed surveillance receipt. The receipt is stored in the public registry and can be verified at /verify/{receipt_id}.

Use this tool when:

  • You want a verifiable record of which trackers were observed in a context (page, app, session).

  • You need a signed evidence artifact for a privacy audit or compliance report.

  • You want to know the overall surveillance exposure level for a set of domains.

  • You are generating a receipt to share with a user as evidence of tracker presence.

Do NOT use this tool when:

  • You want full tracker details per domain — use get_domain instead.

  • You want to look up an existing receipt — use get_receipt instead.

  • You need live probes (HTTP headers, stack detection) — use /v1/intel/* instead.

Inputs:

  • domains (body, required): Array of 1–50 fully qualified domain names. Duplicates are deduplicated. URLs are stripped to host component.

  • domain (body, alternative): Single domain string (shorthand for domains: [domain]).

Returns:

  • receipt_id: Unique receipt ID (e.g. rcpt_01JXYZ...).

  • receipt: Full receipt document including domains submitted, tracker findings, high-risk domains, fingerprinters, unique entities, and exposure metrics.

  • content_hash: SHA-256 of the canonical receipt JSON.

  • signature: Base64 Ed25519 signature (empty string if signing key not configured).

  • signed: Boolean — true if the receipt is cryptographically signed.

  • verify_url: Path to retrieve this receipt from the public registry.

Exposure levels: minimal / moderate / high / critical Based on average tracker score and proportion of high-risk domains (score ≥ 70).

Cost:

  • Counts as one request against the daily limit regardless of domain count.

Latency:

  • Typical: <100ms (pure D1 lookup, no outbound probing). p99: <300ms.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoSingle domain shorthand (alternative to `domains`)
domainsNoDomain names to look up (1–50)

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden, disclosing that the receipt is stored in a public registry, verifiable at /verify/{receipt_id}, that signature may be empty if signing key is not configured, cost implications, and latency. It also explains deduplication and URL stripping.

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?

The description is well-structured with clear sections (intro, usage, inputs, returns, exposure, cost, latency), each sentence providing essential information. It is front-loaded with the core functionality and avoids redundancy.

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 description covers inputs, outputs, cost, latency, and alternatives comprehensively, despite lacking an output schema and annotations. It provides enough detail for an agent to invoke the tool correctly and understand its side effects.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds meaningful details: 'Array of 1–50 fully qualified domain names', 'Duplicates are deduplicated', 'URLs are stripped to host component', and the relationship between `domain` and `domains` as a shorthand alternative.

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 states a specific action: 'Looks up each submitted domain in the TunnelMind tracker database, aggregates risk metrics... and issues a signed surveillance receipt.' It clearly distinguishes from siblings by naming alternatives like get_domain, get_receipt, and /v1/intel/*.

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?

It provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections with concrete alternative tool names (get_domain, get_receipt, /v1/intel/*), giving clear context for selection.

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

Try in Browser

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