Skip to main content
Glama
F6 Threat Intelligence MCP Server

F6 Threat Intelligence MCP Server

Official
by F6-Security

ti_get_collection

Read-onlyIdempotent

Browse and search threat-intelligence collection records with query, date-range, and pagination filters; use scroll mode to export result sets beyond 10,000 records.

Instructions

Common API — read records from a collection: GET /api/v2/{collection}. This is both the browse and the search call: add query to filter, df/dt to bound by date. The response carries count and items; records come back newest-first. Default paging is by offset: the first call returns the newest page, the next one passes offset += limit, until offset reaches count. The backend caps offset + limit at 10000, which is plenty for answering questions. Set scroll=true only to export a result set beyond 10000 records or to walk a whole collection: the response then carries resultId, which this tool remembers per collection+filter and passes back automatically on the next call (stop when items is empty; an id stays valid ~150 s after its last use, and on some collections a NEW scroll is allowed only once per 60 s). Use ti_get_updates instead when tracking a feed continuously.

Input Schema

NameRequiredDescriptionDefault
langNoResponse language, e.g. "en" or "ru".
limitNoInteger. Records per request. Default 100; capped per collection.
queryNoOptional q filter. Free text matches any attribute ("8.8.8.8", "GOFFEE") and is the safe default. Several terms without an operator are searched as one phrase: join them with AND / OR or quote a phrase: "Cobalt Strike". "attribute:value" matches one top-level field exactly ("domain:example.com", "name:GOFFEE"), but only where the collection supports that field: apt/threat and hi/threat accept nothing but id: and domain:. A 400 "invalid search field" means exactly that — repeat the value as free text. The collection's note (in every answer and in ti_describe_collections) says how to search it.
offsetNoInteger. Skip this many records: 0 for the first page, then offset += limit. offset + limit must stay within 10000. Not used with scroll=true.
scrollNotrue = iterate with resultId instead of offset, for sets beyond 10000 records or a full walk. Default false.
date_toNodt — YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ.
restartNoOnly with scroll=true: ignore the remembered resultId and open a new scroll from the first page (on some collections allowed once per 60 s).
date_fromNodf — YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ.
result_idNoOnly with scroll=true: resultId from the previous response. Normally omit it — the remembered one is used automatically.
collectionYesCollection name without an endpoint suffix, e.g. "ioc/common" or "compromised/account_group". Known: apt/threat, apt/threat_actor, attacks/ddos, attacks/deface, attacks/phishing_group, attacks/phishing_kit, compromised/access, compromised/account_group, compromised/bank_card_group, compromised/breached, compromised/discord, compromised/masked_card, compromised/messenger, compromised/mule, compromised/reaper, compromised/suspicious_payment, hi/open_threats, hi/threat, hi/threat_actor, ioc/common, malware/cnc, malware/config, malware/malware, malware/phishing_kit, malware/signature, malware/yara, osi/git_repository, osi/public_leak, osi/vulnerability, suspicious_ip/open_proxy, suspicious_ip/scanner, suspicious_ip/socks_proxy, suspicious_ip/tor_node, suspicious_ip/vpn. Unknown names are passed through as-is; ti_list_collections shows what this account may actually read, ti_describe_collections what each one contains.
extra_paramsNoAny further query parameters, passed through verbatim — e.g. {"tags[filterSpam][]": 1} to drop spam from compromised/messenger, or {"has_exploit": 1} for osi/vulnerability.
apply_hunting_rulesNo0 or 1. Applies this account's hunting rules so only matching data comes back. Supported by: apt/threat, attacks/ddos, attacks/phishing_group, compromised/breached, compromised/messenger, compromised/reaper, hi/open_threats, hi/threat, osi/public_leak, osi/vulnerability, suspicious_ip/open_proxy, suspicious_ip/scanner, suspicious_ip/socks_proxy, suspicious_ip/tor_node, suspicious_ip/vpn.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely useful behavior: newest-first ordering, the 10000 offset+limit cap, the ~150 s resultId lifetime, and the once-per-60 s new-scroll restriction on some collections. However, it omits practical call-level behavior such as error shapes beyond the one 400 example and how large responses are delivered. Solid additional context, but not exhaustive.

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?

Front-loaded with purpose, then paging model, then the scroll escalation, then the sibling handoff — a logical progression with no filler. It is long, and some paging details restate what the parameter descriptions already say, which costs a point but not much given the tool's complexity.

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?

For a 12-parameter tool with a nested extra_params object and no output schema, the description still covers the response shape (count and items, newest-first), the scroll continuation token, and the escape hatches to ti_list_collections and ti_describe_collections. An agent can call it correctly, including recovering from an invalid search field, without further information.

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?

With schema coverage at 100%, the baseline would be 3, but the description adds cross-parameter meaning the schema does not: the offset/limit arithmetic against count, the rule that offset is 'Not used with scroll=true', that restart is meaningless without scroll, and that result_id is normally omitted because the remembered id is applied automatically. The query guidance and the 400 'invalid search field' recovery workaround further reduce misuse of the most error-prone parameter.

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 ('read records from a collection: GET /api/v2/{collection}') and immediately resolves the ambiguity with 'both the browse and the search call', so an agent knows there is no separate search endpoint. It also names the sibling it is not (ti_get_updates) and the discovery siblings to use when the collection name is unknown.

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

Usage Guidelines5/5

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

Gives explicit when-to-use and when-not-to-use rules: default offset paging 'which is plenty for answering questions', scroll=true only for exports beyond 10000 or full walks, and ti_get_updates instead for continuous feed tracking. Even the escalating steps (offset += limit until offset reaches count; stop when items is empty) are spelled out.

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