TunnelMind Data API

get_freshness

D4 — the freshness contract a PDP can gate on. For each lens (Scry / Sigil / Tracker / GhostRoute) this reports the newest observation timestamp in the corpus, the declared ingest cadence (taken from the ingester's own code and cron schedules, never asserted), the published SLO, the current corpus age in seconds, and whether the SLO holds. GhostRoute reports its three corpus workers (CT hourly, RPKI 6-hourly, ASN daily) individually.

SLO rule: 2x the declared cadence — one fully missed ingest cycle trips it — except where an estate monitor already publishes a threshold, in which case the SLO matches the monitor.

Every source is independently null-tolerant: a momentarily-unmeasurable lens reports last_observation_at: null and slo_met: null — never a fabricated timestamp, never a silent pass. Cached ~5 minutes (unlike the weekly /v1/stats snapshot — freshness that was itself a week stale would be self-refuting).

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses the SLO rule (2x cadence), explains that cadence comes from code/cron (never asserted), details null-tolerance behavior (null timestamps never fabricated), and reveals caching behavior. This goes well beyond a basic summary and gives the agent critical behavioral expectations.

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 reasonably concise given the complexity, but the opening 'D4 — the freshness contract' is somewhat cryptic and may require domain knowledge. Still, every sentence contributes useful detail, and the structure with clear paragraphs aids readability. It could be slightly tighter but earns a strong score.

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?

There is no output schema, so the description must explain return values. It fully covers the per-lens fields, the per-worker breakdown for GhostRoute, the SLO calculation, null-handling, and caching. For a read-only status tool, this is remarkably complete and leaves no ambiguity about what the agent will receive.

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, and the schema coverage is 100% (trivially). Per the baseline for no-parameter tools, a score of 4 is appropriate, since there is no parameter meaning to add. The description does not attempt to invent parameters and stays focused on output behavior.

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's function: it reports freshness metrics per lens (Scry/Sigil/Tracker/GhostRoute), including observation timestamps, cadence, SLO, age, and whether the SLO holds. This is a specific verb ('reports') plus a well-defined resource (freshness contract), and it distinguishes itself from sibling tools like get_stats or snapshot_data by focusing on live freshness data.

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

Usage Guidelines4/5

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

The description implies usage context ('a PDP can gate on') and contrasts with the weekly /v1/stats snapshot, explaining why this tool is cached only 5 minutes. However, it does not explicitly name when to use this over alternatives or specify exclusion criteria. The indirect comparison provides clear context but stops short of explicit 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 tools Inspect

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

Need Help?