Skip to main content
Glama
Sign In
F6 Threat Intelligence MCP Server

F6 Threat Intelligence MCP Server

Official
by F6-Security
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

ti_get_updates

Read-onlyIdempotent

Polls a threat-intelligence collection for records changed since a sequence point, returning updates oldest-first so you can page through changes and stop when no items remain.

Instructions

Updated API — poll a collection for records changed since a point in the update sequence: GET /api/v2/{collection}/updated. Start with a seq_update from ti_get_sequence_list (or omit it, optionally bounding with date_from), then feed the seqUpdate value from each response into the next call. Records come back oldest-first; stop when items is empty. Every record in TI has a unique seqUpdate and a record that gets updated is renumbered, so it resurfaces. Not available for compromised/breached, compromised/reaper — use ti_get_collection for those.

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.
date_toNodt — sent as pyf6 does, though the guide lists dt only for the Common API.
date_fromNodf — YYYY-MM-DD or YYYY-MM-DDTHH:MM:SSZ.
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.
seq_updateNoInteger seqUpdate to continue from; omit for the first call.
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 declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: records return oldest-first, every record has a unique seqUpdate and updated records are renumbered so they resurface, and the empty-items termination condition. It does not cover rate limits or response envelope shape, keeping it below the top of the scale.

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 the operation and endpoint, then the pagination loop, then the ordering rule, then exclusions — a logical sequence with little waste. It is dense and packs several distinct concerns into one block, which costs it the top score, but no sentence is filler.

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 nine-parameter, no-output-schema polling tool, the description supplies everything an agent needs: the cursor source, the loop and its termination condition, result ordering, and the collection-level exclusions. Return-value shape is covered implicitly via 'items' and 'seqUpdate', which is sufficient given the pagination contract.

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 schema already documents all nine parameters and the baseline is 3. The description adds real meaning on top by explaining the seq_update continuation contract (feed the returned seqUpdate into the next call) and the date_from bounding option, which the schema only hints at.

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 ('poll a collection for records changed since a point in the update sequence') and even gives the underlying endpoint GET /api/v2/{collection}/updated. It distinguishes itself from siblings by naming ti_get_sequence_list as the source of the starting cursor and ti_get_collection as the fallback for excluded collections.

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 an explicit workflow: start with seq_update from ti_get_sequence_list or omit it and bound with date_from, then feed each response's seqUpdate into the next call, and stop when items is empty. It also states when NOT to use it (compromised/breached, compromised/reaper) and names the alternative tool for those cases.

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

Deploy Server

Other Tools