Sigil
REMOTE · MCP.SIGIL.TUNNELMIND.AI
Programmatic-advertising supply verification: ads.txt, schain, ATAP receipts, cross_lens_verify.
Available components
Last scanned (1 hour ago)
Scores higher than 4% of remote servers
Reachable. Last reached 5 Nov 2026.
Deprecated
This server is marked deprecated in the MCP registry.
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security46
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. View diagnostics → Unverified
- HTTPS enforcement could not be verified: the plaintext port answered with HTTP 410, which proves neither a plaintext path nor enforcement. View diagnostics → Unverified
- HSTS check failed: the Strict-Transport-Security header is absent. See how to fix → View diagnostics → Fail
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability0
- Transport check failed: declared streamable-http, but the endpoint returned HTTP 410. See how to fix → View diagnostics → Fail
Schema Quality & AI Usability0
- Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
- Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
- Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified
Unverified: 5 categories
Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 28 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 25 Sept 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 22 Aug 26 0
- Endpoint reachability: reachable → not serving MCP ▼ security
- Stability: 0.87 → unverified ▼ security
- Transport: pass → fail ▼ security
- Authorization: Authorisation not fully verified: no authorisation is required to connect, but we couldn't read the whole tool list to see what that exposes. security
- Schema quality: 100 → unverified ▼ functional
- Capabilities: fail → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- 11 Aug 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 31 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://mcp.sigil.tunnelmind.ai/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=tunnelmind.ai | CN=WE1,O=Google Trust Services,C=US | 11 Sept 2026 | 10 Dec 2026 | ECDSA 256 | ECDSA-SHA256 | 2191dc5df11e8f8131b4d32168d8ff0 |
| SANs: tunnelmind.ai, mcp.sigil.tunnelmind.ai, *.mcp.sigil.tunnelmind.ai | ||||||
| CN=WE1,O=Google Trust Services,C=US (CA) | CN=GTS Root R4,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | ECDSA 256 | ECDSA-SHA384 | 7ff31977972c224a76155d13b6d685e3 |
| CN=GTS Root R4,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 15 Nov 2023 | 28 Jan 2028 | ECDSA 384 | SHA256-RSA | 7fe530bf331343bedd821610493d8a1b |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of mcp.sigil.tunnelmind.ai. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| ai. | present | 1814, 3799 | 8, 8 | Verified |
| tunnelmind.ai. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Inconclusive
We could not reach the endpoint well enough to judge its authorisation posture.
| Result | Inconclusive |
|---|---|
| HTTP status | 410 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://mcp.sigil.tunnelmind.ai/mcp | HTTP error | 410 | |
| http (plaintext) | http://mcp.sigil.tunnelmind.ai/mcp | Inconclusive | 410 |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
cross_lens_verify ~474
A2 — the cross-lens join. Fuse TunnelMind's two lenses (Scry attacker intelligence + Sigil supply graph) into ONE verdict on a single node key. This is the moat: no siloed competitor owns both halves of the graph, so the fused `cross_lens` block carries information neither lens can supply alone. Use this tool when: - An agent must decide whether to transact with an IP, domain, ASN, or entity_slug, and a one-lens answer is not enough. - You want a single composite trust verdict instead of running Scry + Sigil calls separately and reconciling them by hand. Inputs: - `node` (required): an IPv4 address, a domain, an ASN (e.g. `AS64500`), or an entity_slug. Type is auto-detected. - `weights` (optional): per-component weight overrides. - `thresholds` (optional): `{ pass, fail }` verdict cutoffs (defaults 0.7 / 0.3). - `ait` (optional): an ATAP AIT id. When present, the verdict is chained onto the AIT as a witness-tier `cross_lens:verified` event signed by Sigil (witness OAI-2026-0000201) — replayable evidence, not just JSON. Returns: per-lens `scry` + `sigil` blocks (transparency), a fused `cross_lens` block with `verdict` / `trust_score` / `confidence` / `signals` / `recommendations`, a 5-minute signed `sigil_token`, and a `witnessed_event` block when an AIT was supplied. Failure semantics: each lens fails independently. Single-lens answers still return 200 with a `confidence` of 0.55. Returns 503 only when BOTH lenses are unavailable.
| Name | Type | Req | Description |
|---|---|---|---|
| ait | string | – | Optional ATAP AIT id to witness this verification under. |
| node | string | yes | The node to verify. IPv4, domain, ASN (AS-prefixed or numeric), or entity_slug. |
| thresholds | object | – | – |
| weights | object | – | – |
No output schema declared.
No examples provided.
sigil_atap_register_ait ~278
Register an ATAP v0.1 Agent Identity Token for a media-buying agent. Sigil validates the capabilities + constraints against the `sigil:media_buyer:v1` profile, signs the AIT as the witness, and returns it. Do this once per agent campaign before witnessing any events. Inputs: - `profile` (required): must be `sigil:media_buyer:v1`. - `operator` (required): the agent operator's canonical OAI. - `capabilities` (required): array from the profile vocabulary. - `constraints` (required): { currency, max_bid_cpm, supply_trust_minimum, budget_total_cap, allowed_channels, ... }. - `attestation_policy` (required): { witness_granularity, block_interval_seconds (60-3600), receipt_generation }. - `expires_at` (required): ISO date-time, <= 365 days out. Returns: the signed AIT (note its `id` for subsequent witness calls).
| Name | Type | Req | Description |
|---|---|---|---|
| agent_type | string | – | – |
| attestation_policy | object | yes | – |
| capabilities | array | yes | – |
| constraints | object | yes | – |
| expires_at | string | yes | – |
| operator | string | yes | – |
| profile | string | yes | – |
No output schema declared.
No examples provided.
sigil_atap_witness ~242
Witness one agent-reported bid or budget event into an AIT's hash-chained attestation log. Sigil validates the payload (rejecting any PII), classifies the evidence tier — `anchored` if a bid cites a valid Sigil token, else `asserted` — derives constraint violations, and signs the event. Use this tool when: - An ATAP-enrolled media-buyer agent submits a bid, win, loss, or budget decrement and you want it on the attestation record. Inputs: - `ait` (required): the AIT id. - `event_type` (required): bid:submitted | bid:won | bid:lost | budget:decremented. - `payload` (required): the event payload (see the sigil:media_buyer:v1 profile). Returns: the signed witness event(s), the assigned `tier`, and any derived constraint violations. (supply:verified events come from verify_supply_path, not this tool.)
| Name | Type | Req | Description |
|---|---|---|---|
| ait | string | yes | – |
| event_type | string | yes | – |
| payload | object | yes | – |
No output schema declared.
No examples provided.
sigil_generate_receipt ~172
Generate the ATAP v0.1 compliance Receipt for an AIT — the portable, signed artifact a media buyer hands its principal. The receipt grades every event witnessed / anchored / asserted and is verifiable offline with the bundled verify.sh. Use this tool when: - A reporting period closes and you need a compliance export for the AIT. Inputs: - `ait` (required): the AIT id. - `format` (optional): `full` (default) or `summary`. Returns: JSON with `receipt_id` and `zip_base64` — base64-decode `zip_base64` to a .zip, unpack it, and run verify.sh to verify the chain independently.
| Name | Type | Req | Description |
|---|---|---|---|
| ait | string | yes | – |
| format | string | – | – |
No output schema declared.
No examples provided.
sigil_score_batch ~144
Pre-computed trust scores for up to 200 entities in one call — built for an agent evaluating many supply sources during campaign setup. Use this tool when: - You have a list of publishers/SSPs to grade at once. Inputs: - `entity_ids` (required): array of `{type}:{domain}` ids, up to 200. - `weights` (optional): custom component weights to re-score with. Returns: `count`, `scored_count`, and a per-entity `results` array (invalid ids are reported inline, never failing the batch).
| Name | Type | Req | Description |
|---|---|---|---|
| entity_ids | array | yes | – |
| weights | object | – | – |
No output schema declared.
No examples provided.
sigil_score_entity ~149
Get the pre-computed trust score for one supply-chain entity (a publisher or an SSP). Scores are recomputed daily from ads.txt health, supply-chain directness, reach, and stability — deterministic, no ML black box. Use this tool when: - You want a fast standing trust signal for an entity without running checks. Inputs: - `entity_id` (required): `{type}:{domain}` — e.g. `publisher:nytimes.com` or `ssp:pubmatic.com`. Returns: `trust_score` (0-1), `score_components`, the 14-day `trend`, and `warnings`.
| Name | Type | Req | Description |
|---|---|---|---|
| entity_id | string | yes | – |
No output schema declared.
No examples provided.
sigil_traverse_supply_chain ~395
Walk the supply graph for a publisher domain and get back the ITEMIZED sell paths — distinct from sigil_verify_supply_chain (which verifies a schain you BRING) and from the dark-pool-risk signal (which only returns counts). Here Sigil reconstructs the paths from its own crawl: every SSP the publisher declares it sells through, joined to that SSP's identity and classified two-sided against the SSP's sellers.json. Use this tool when: - You have a publisher domain but no schain, and want to SEE its real authorized supply paths and where the opacity is. - dark-pool-risk flagged a publisher and you need the specific contradicted paths driving the risk, not just the aggregate. Inputs: - `domain` (required): the publisher domain, e.g. `cnn.com`. - `limit` (optional): max paths returned (default 200, cap 500). The list is ordered riskiest-first (contradicted, then reseller) so a truncated page is still the most useful; the `supply_paths` counts are always over the FULL set. Returns: `supply_paths` aggregate counts (total / direct / reseller / corroborated / contradicted / unchecked) and `paths[]`, each with the SSP identity, `seller_id`, `seller_type`, `klass` (corroborated = seat present; contradicted = SSP crawled but seller_id absent → real risk; unchecked = SSP not yet crawled → not risk), and `resells_to` (one level of downstream reseller expansion). Returns in_supply_graph:false if the domain is not in the crawled corpus.
| Name | Type | Req | Description |
|---|---|---|---|
| domain | string | yes | Publisher domain to traverse. |
| limit | integer | – | Max paths returned (default 200, cap 500). |
No output schema declared.
No examples provided.
sigil_verify_ads_txt ~216
Check whether an exchange/SSP is authorized to sell a publisher's inventory, per the publisher's ads.txt file. Fast cached lookup against Sigil's daily crawl of the top ~10k publisher domains. Use this tool when: - You need a single, narrow authorization check (not a full supply-path score). - You are validating a (publisher, exchange, seller_id) triple from a bid request. Inputs: - `publisher_domain`, `exchange_domain`, `seller_id` (all required). - `resolve_chain` (optional): when true and the entry is RESELLER, Sigil walks one hop into the exchange's sellers.json to identify the upstream seller. Returns: `verified` (true/false/null), `confidence`, the matched ads.txt entry, and any `warnings` (e.g. seller_type mismatch).
| Name | Type | Req | Description |
|---|---|---|---|
| exchange_domain | string | yes | – |
| publisher_domain | string | yes | – |
| resolve_chain | boolean | – | – |
| seller_id | string | yes | – |
No output schema declared.
No examples provided.
sigil_verify_app_bundle ~157
Verify that a mobile/CTV app bundle ID actually exists in its app store and, optionally, that the listed developer matches. Detects bundle-ID spoofing in bid requests. Use this tool when: - A bid request names an app bundle and you must confirm the app is real. Inputs: - `bundle_id` (required), `platform` (required: ios | android | ctv_* | web), - `claimed_developer` (optional): developer name to match against the listing. Returns: `verified` (true/false/null), the store listing, and `developer_match`.
| Name | Type | Req | Description |
|---|---|---|---|
| bundle_id | string | yes | – |
| claimed_developer | string | – | – |
| platform | string | yes | – |
No output schema declared.
No examples provided.
sigil_verify_ip_type ~115
Classify an IPv4 address as datacenter, residential, mobile, or unknown. Detects datacenter traffic posing as real user devices. Stateless — the IP is never logged or stored. Use this tool when: - You need to know whether bid-request traffic originates from a datacenter. Inputs: - `ip` (required): an IPv4 address. Returns: `ip_type`, `confidence` (high/medium/low), and the ASN + AS-org name.
| Name | Type | Req | Description |
|---|---|---|---|
| ip | string | yes | – |
No output schema declared.
No examples provided.
sigil_verify_supply_chain ~214
Verify a full OpenRTB SupplyChain (schain) object — every node, end to end. Per node Sigil checks the seller against the exchange sellers.json and the origin ads.txt, then returns a per-node and aggregate verdict plus a signed token. Use this tool when: - A bid request carries an OpenRTB `schain` and you want it verified verbatim. Inputs: - `schain` (required): an OpenRTB SupplyChain object ({ ver, complete, nodes:[{asi,sid,hp}] }). - `site_domain` or `app_bundle` (optional): the inventory origin, checked against node[0] via ads.txt / OWNERDOMAIN. Returns: per-node `nodes` results, an aggregate `verdict`, `recommendations`, and a signed `sigil_token`.
| Name | Type | Req | Description |
|---|---|---|---|
| app_bundle | string | – | – |
| schain | object | yes | OpenRTB SupplyChain object. |
| site_domain | string | – | – |
No output schema declared.
No examples provided.
sigil_verify_supply_path ~281
The core pre-bid check. Verify the trustworthiness of one programmatic ad supply path and get back a composite trust verdict plus a signed proof token. Sigil composes ads.txt authorization, datacenter-IP classification, Scry fraud-corpus lookup, and app-bundle checks into one score. Use this tool when: - An ad-buying agent is about to bid and must confirm the supply is genuine. - You want one call instead of running ads.txt / IP / bundle checks separately. Inputs: - `supply_path` (required): { publisher_domain, exchange, seller_id, and optionally ip_address, app_bundle:{bundle_id,platform} }. - `ait` (optional): an ATAP AIT id — when present, Sigil records this verification as a witnessed attestation event and binds the token to it. Returns: `trust_score` (0-1), `verdict` (pass/warn/fail/unknown), per-check results, `recommendations`, and a signed `sigil_token` (5-min) to attach to the bid as proof. The submitted IP is used for lookup only — never stored.
| Name | Type | Req | Description |
|---|---|---|---|
| ait | string | – | Optional ATAP AIT id to witness this verification under. |
| supply_path | object | yes | – |
No output schema declared.
No examples provided.
How do I install the Sigil MCP server?
Sigil is a hosted endpoint at https://mcp.sigil.tunnelmind.ai/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · mcp.sigil.tunnelmind.ai
claude mcp add --transport http ai-tunnelmind-sigil 'https://mcp.sigil.tunnelmind.ai/mcp'
What is the Sigil MCP server?
Sigil is an MCP server listed in the public MCP registry as ai.tunnelmind/sigil. Programmatic-advertising supply verification: ads.txt, schain, ATAP receipts, cross_lens_verify. This page covers its hosted endpoint (https://mcp.sigil.tunnelmind.ai/mcp).
Is the Sigil MCP server safe to use?
Sigil scores 18 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Sigil MCP server expose?
Sigil exposes 12 tools: cross_lens_verify, sigil_verify_supply_path, sigil_verify_ads_txt, sigil_verify_ip_type, sigil_verify_app_bundle, and 7 more. Their descriptions and schemas cost roughly 2,837 tokens of context every time the server is loaded.
Does the Sigil MCP server require authentication?
Its publisher declares no required credentials for Sigil. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.
Is the Sigil MCP server still maintained?
Sigil is marked deprecated in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.