Skip to main content
Glama
ShieldLabs-ai

@shieldlabs-ai/mcp

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SHIELDLABS_DOMAINNoRegistered domain for the Management API, for example `example.com`. With `SHIELDLABS_SECRET_KEY` it enables `shieldlabs_get_domain_profile`.
SHIELDLABS_API_KEYYesPrivate 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_TOKENNoBearer token for the HTTP endpoint (for `--transport http`); generated and printed once when unset.
SHIELDLABS_SECRET_KEYNoSecret Key of the domain, for the Management API.
SHIELDLABS_API_BASE_URLNoHistory 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_SECRETNoDefault endpoint signing secret (whsec_...) for `shieldlabs_verify_webhook_signature`; several separated by commas while you rotate.
SHIELDLABS_MANAGEMENT_BASE_URLNoManagement 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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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:

  • payload (string): raw body exactly as received

  • signature_header (string): value of X-Shield-Signature

  • secret (string, optional): whsec_... signing secret of the endpoint, or several separated by commas

  • payload_encoding ('utf8' | 'base64'): default 'utf8'

  • response_format ('markdown' | 'json'): default 'markdown'

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:

  • timezone (string, optional): IANA time zone such as "Europe/Berlin"

  • response_format ('markdown' | 'json'): default 'markdown'

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

NameDescription
integrate_shieldlabsStep-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_userRead one user card and its reported risk, counts and HRE availability.
review_requestRead one identification card, assess freshness and explain its reported risk.

Resources

Contextual data attached and managed by the client

NameDescription
identification-schemaJSON Schema of a domain-scoped History entity card. Risk and signals availability are explicit.
webhook-event-schemaJSON Schema of a webhook delivery body (identification.scored, hre.multi_account.changed and webhook.ping) with the signature scheme.
risk-signalsPlain-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-bandsThe three risk bands (trusted 0-29, suspicious 30-59, dangerous 60-100) and the 999 rate-limit marker.

TDQS

A3.7/5.0

Scored across 6 tools

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness2/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues