Skip to main content
Glama
F6 Threat Intelligence MCP Server

F6 Threat Intelligence MCP Server

Official
by F6-Security

ti_get_item

Read-onlyIdempotent

Retrieve a threat-intelligence record by collection and ID to inspect indicators, malware, leaks, or actors. Use IDs from collection or update results; a 404 can mean no by-ID endpoint, not deletion.

Instructions

Fetch one record by id: GET /api/v2/{collection}/{id}. Ids come from ti_get_collection or ti_get_updates results. Not every collection supports it — a 404 here does not mean the record is gone, only that this collection has no by-id endpoint.

Input Schema

NameRequiredDescriptionDefault
idYesRecord id from a collection or search result.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/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), so the description is free to add the genuinely non-obvious behavior: a 404 here reflects a missing collection endpoint, not a deleted record. That is exactly the kind of misinterpretation risk annotations cannot express. It does not describe return shape or whether results are cached, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, zero filler: the operation and route come first, then id provenance, then the error-semantics caveat. Each sentence carries distinct information an agent needs and nothing is repeated from the title or schema.

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 two-parameter read tool with full annotation coverage and no output schema, this covers the operation, where inputs come from, and the one failure mode that would otherwise be misread. The schema already handles collection enumeration and id format, so no meaningful gap remains.

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 even without description help, and the collection parameter is already enumerated exhaustively in the schema. The description adds real semantic constraint on that parameter by warning that collection support for by-id lookup varies, which tells the agent the enum being valid does not guarantee this tool works for it.

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 ("Fetch one record by id") and pins it to a concrete route, GET /api/v2/{collection}/{id}. The singular "one record" contrasts implicitly but clearly with the sibling list tools ti_get_collection and ti_get_updates, so an agent can separate single-item retrieval from listing without opening a 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 explicit prerequisites — ids must come from ti_get_collection or ti_get_updates — and a clear when-not signal: not every collection has a by-id endpoint. It stops short of naming the fallback tool to use when this one 404s (the schema points to ti_list_collections/ti_describe_collections), so the alternative path lives in the schema rather than the description.

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