Skip to main content
Glama

isMalicious threat intelligence for AI agents

Check indicator reputation

check_indicator
Read-onlyIdempotent

The one tool for any single indicator: an IP address, domain, URL, file hash (MD5, SHA-1 or SHA-256; an imphash is looked up as an MD5), email address or phone number. Defanged input (hxxp://, [.], [@]) is accepted. Returns a verdict (malicious, suspicious, clean or unknown), a headline you can relay as is, recommendedAction (block, review, allow or unverified), a 0-100 risk score, the threat blocklists that cite it, up to three evidence reasons, first/last seen, and network, registration or file context. An email address or phone number is never called clean: not being in our sources is unknown / unverified; its answer adds the sender domain's reputation, disposable and MX facts, or the E.164 form of the number. infrastructure says what the entity is known as (cloud range, CDN, Tor exit, VPN, crawler, allowlist) without being a verdict. SHA-512, TLSH, ssdeep and input that is none of the six kinds (an address in a form the API cannot read, digits that are not a phone number, a number written with letters, a host that is not a dotted domain name) are refused before any request, at no cost. The default level, fast, answers from cached intelligence without a live DNS, WHOIS or OTX call (a hash nobody has cached may wait up to ~2.5 s on CIRCL); facets not cached yet are listed in meta.pending, and one re-check after a few seconds may complete them; if they are still pending then, keep the answer and do not re-check again. Costs one request of the monthly quota; check_url is the cheaper pre-fetch gate for a link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoISO 3166-1 alpha-2 country (FR, GB, DE…) for a phone number written in national format, e.g. 06 12 34 56 78 with FR. Not needed for +… or 00… numbers; without it a 10-digit number is read as North American. Ignored for other indicators.
indicatorYesThe IP, domain, URL, file hash (MD5, SHA-1 or SHA-256), email address or phone number to check. Defanged forms are accepted, and so are full-width characters, a display-name address (Name <user@example.com>), a mailto:, tel:, sms: or callto: link, and a labelled hash (sha256:…).
enrichmentNo"fast" (default): cached intelligence only, no live upstream call before the answer; facets not cached yet are listed in meta.pending and fetched in the background, so one re-check after a few seconds may complete them (a hash no source has cached may wait up to a few seconds on CIRCL). "standard": may call live upstreams (DNS, OTX, CIRCL) before answering; seconds on an entity nobody has checked recently. "basic": verdict and blocklists only, no risk score. Email addresses and phone numbers are answered from cached data at every level.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the readOnly/openWorld/idempotent annotations with caching semantics (fast answers from cache, no live DNS/WHOIS/OTX), latency (~2.5 s CIRCL wait), meta.pending behavior and an explicit 're-check once, then stop' rule. It also discloses quota cost, that unsupported hash types are refused before any request at no cost, and that email/phone are never labelled clean.

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?

Purpose and accepted inputs are front-loaded, and the dense sentences mostly earn their place by packing routing, cost and caching facts. It is still a long, back-loaded paragraph where the refusal rules and re-check guidance arrive late, which slightly hurts scannability.

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?

With no output schema, the description carries the full burden and delivers: it enumerates the return fields (verdict, headline, recommendedAction, risk score, blocklists, reasons, timestamps, context). Combined with the coverage of weird inputs and latency, an agent has everything needed to call and interpret it.

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 baseline is 3; the description adds value by restating the default level and its cost ('Costs one request of the monthly quota') and clarifying the fast-vs-standard trade-off in prose. The country parameter's national-format behavior is left to the schema, so it stops short of a 5.

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 specific verb and resource up front ('The one tool for any single indicator') and enumerates exactly the six accepted input kinds (IP, domain, URL, file hash, email, phone). It also implicitly separates itself from the plural sibling check_indicators and explicitly routes links to check_url, so an agent can distinguish it without opening the schema.

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?

Gives clear routing context: it is the single-indicator tool, and 'check_url is the cheaper pre-fetch gate for a link' names an alternative with its selecting condition. It does not, however, explicitly name check_indicators as the batch alternative or state exclusions for the other siblings (scan_email, search_indicators).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.