Skip to main content
Glama
Sign In

TunnelMind Data API

by ai.tunnelmind
OverviewDiscussionsAdmin

generate_receipt

At least one of domains (or domain) is required.

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

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/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 so: it discloses a durable side effect (receipt written to the public registry), signing behavior including the empty-signature case when no key is configured, deduplication and URL-to-host normalization, cost against the daily limit, and latency figures. These are behaviors the agent cannot infer from the schema.

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?

Headers for Inputs/Returns/Cost/Latency make it scannable, and the leading 'at least one of domains or domain is required' is a valuable clarification given zero required params in the schema. A few 'Use this tool when' bullets overlap substantially (verifiable record, signed evidence artifact, share with user), which is the only waste.

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

Completeness4/5

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

With no output schema and no annotations, the description correctly supplies a full return-field breakdown (receipt_id, receipt, content_hash, signature, signed, verify_url) plus the exposure-level enum values and their basis. Remaining gaps are small: no mention of error behavior for unknown domains or any authentication/tier prerequisite.

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 coverage is 100%, so the 1–50 range and the single-domain shorthand are already documented; the description adds genuinely new semantics (duplicates deduplicated, URLs stripped to host). It does not explain the 'domain' vs 'domains' precedence when both are supplied, which matters since the schema marks neither as required.

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?

States a precise verb+resource chain: looks up each submitted domain, aggregates risk metrics (avg/max score, fingerprinters, high-risk domains, entity ownership), and issues a signed surveillance receipt stored in a public registry. It explicitly names what it is not (get_domain, get_receipt, /v1/intel/*), so an agent can route correctly without opening another schema.

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 an explicit 'Use this tool when' block with four concrete scenarios (verifiable record, signed audit artifact, exposure level, shareable evidence) and a matching 'Do NOT use' block naming three alternatives and the condition that selects each. This is the strongest form of when/when-not guidance.

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