@shieldlabs-ai/mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SHIELDLABS_DOMAIN | No | Registered domain for the Management API, for example `example.com`. With `SHIELDLABS_SECRET_KEY` it enables `shieldlabs_get_domain_profile`. | |
| SHIELDLABS_API_KEY | Yes | Private API Key (sec_...) of one domain, for the History API tools. Without it the server starts with the offline tools only and explains how to add the key. | |
| SHIELDLABS_MCP_TOKEN | No | Bearer token for the HTTP endpoint (for `--transport http`); generated and printed once when unset. | |
| SHIELDLABS_SECRET_KEY | No | Secret Key of the domain, for the Management API. | |
| SHIELDLABS_API_BASE_URL | No | History API origin, default `https://account.shieldlabs.ai` (development and tests). Must be https; plain http is accepted only for `localhost`, `127.0.0.1` and `[::1]`. | |
| SHIELDLABS_WEBHOOK_SECRET | No | Default endpoint signing secret (whsec_...) for `shieldlabs_verify_webhook_signature`; several separated by commas while you rotate. | |
| SHIELDLABS_MANAGEMENT_BASE_URL | No | Management API origin, default `https://api.shieldlabs.ai` (development and tests). Must be https; plain http is accepted only for `localhost`, `127.0.0.1` and `[::1]`. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| shieldlabs_list_historyA | List identifications or users in one domain. domain is the public UUID from shieldlabs_list_domains. Repeat page_token with the same resource, window and flat filters. Filters are risk_bands, hre_min_accounts (3-99), hre_min_devices (4-99), ids (one user id on the user list), risk_signals, source, campaign and boolean flags. Dates are RFC3339 and the window is half-open. Nested filter, chips, offset, include_total and sort are rejected. visitor, device and ip have a card, not a list. |
| shieldlabs_get_identificationA | Read one identification card by identification_id in a public domain UUID. wait polls missing results for at most 10 seconds; unavailable risk remains unavailable. |
| shieldlabs_get_historyB | Read one identification, user, visitor, device or ip card. domain is the public UUID and resource_id is the record id. The same flat list filters apply, plus device_id_source (legacy or fp21_record). relation, relation_limit and relation_page_token are not accepted. Nested filter, chips, offset and include_total are rejected. |
| shieldlabs_explain_risk_scoreB | Read an identification card or explain a pasted identification. Missing signal weights are unavailable, never zero contribution. HRE confidence is separate from Risk Score. |
| shieldlabs_verify_webhook_signatureA | Check a received ShieldLabs webhook delivery: does its X-Shield-Signature header match the raw body for the endpoint signing secret? For debugging a webhook endpoint. SHIELDLABS_WEBHOOK_SECRET is not set on this server, so pass secret. The signature is "sha256=" plus the lowercase hex HMAC-SHA256 of the raw body, keyed with the full signing secret including its whsec_ prefix. While a secret is rotated, give several secrets separated by commas (in secret or in SHIELDLABS_WEBHOOK_SECRET): the delivery is valid when any of them matches, and matched_secret tells which. When the signature does not match a body of up to 64 KB, the tool tests common body changes (re-serialized JSON, unescaped characters, added newline) and says which one explains the mismatch. It never returns a secret or an expected signature. Args:
Returns (json): { "valid": boolean, "secret_source": "argument" | "environment", "secrets_checked": number, "matched_secret": number | null, "checks": [{ check, ok, detail }], "event": { event_type, schema_version, created_at, event_id, identification_id, risk_score, risk_band } | null, "hint": string | null } |
| shieldlabs_current_timeA | Return the current time of the machine running this server, in UTC and optionally in one IANA time zone. Use it to judge freshness: for example whether an identification's observed_at is older than a 5-minute window, or how long ago an account was last seen. Args:
Returns (json): { "utc": string, "unix_seconds": number, "unix_ms": number, "timezone": string | null, "local_time": string | null, "utc_offset": string | null } |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| integrate_shieldlabs | Step-by-step plan to integrate ShieldLabs into the current application: browser identification, server-side verdict, webhooks and a verification checklist. Uses the published ShieldLabs setup skill, with a built-in guide when it cannot be fetched. |
| investigate_user | Read one user card and its reported risk, counts and HRE availability. |
| review_request | Read one identification card, assess freshness and explain its reported risk. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| identification-schema | JSON Schema of a domain-scoped History entity card. Risk and signals availability are explicit. |
| webhook-event-schema | JSON Schema of a webhook delivery body (identification.scored, hre.multi_account.changed and webhook.ping) with the signature scheme. |
| risk-signals | Plain-language meaning of every known risk signal slug, the 20 detection flags and the connection types. Weights can change and unknown slugs are possible. |
| risk-bands | The three risk bands (trusted 0-29, suspicious 30-59, dangerous 60-100) and the 999 rate-limit marker. |
TDQS
Scored across 6 tools
While all tools have distinct prefixes and functions, there is some overlap between list_history, get_identification, and get_history. An agent might confuse which specific getter tool to use depending on the granularity of the required record.
All tool names strictly adhere to the shieldlabs_verb_noun pattern. The use of snake_case is uniform across the entire set, making the set highly predictable and easy to parse.
The 6 tools are well-scoped and earn their place. They successfully cover the core functionalities needed for a data-heavy security/risk information retrieval service.
The tool set is critically incomplete as it lacks any mutation capabilities. The entire surface appears read-only, missing essential CRUD operations (create, update, delete) for the identified entities.