Skip to main content
Glama
jmaciasc-google

Google Threat Intelligence MCP Server

search_digital_threat_monitoring

Query historical threat data from surface, deep, and dark web sources using Lucene syntax. Filter by document type or threat type to find relevant intelligence.

Instructions

Search for historical data in Digital Threat Monitoring (DTM) using Lucene syntax.

Digital theat monitoring is a collection of documents from surface, deep, and dark web sources.

To filter by document type or threat type, include the conditions within the query string using the fields __type and label_threat, respectively. Combine multiple conditions using Lucene boolean operators (AND, OR, NOT).

Examples of filtering in the query:

  • Single document type: (__type:forum_post) AND (body:security)

  • Multiple document types: (__type:(forum_post OR paste)) AND (body:security)

  • Single threat type: (label_threat:information-security/malware) AND (body:exploit)

  • Multiple threat types: (label_threat:(information-security/malware OR information-security/phishing)) AND (body:exploit)

  • Combined: (__type:document_analysis) AND (label_threat:information-security/information-leak/credentials) AND (body:password)

Important Considerations for Effective Querying:

  • Date/Time Filtering (since and until):

  • Input parameters since and until filter documents by their creation/modification time.

  • These must be strings in RFC3339 format, specifically ending with 'Z' to denote UTC.

  • Example: '2025-04-23T00:00:00Z'

  • Pagination for More Than 25 Results:

    • A single API call returns at most size results (maximum 25).

    • To retrieve more results, you must paginate:

      1. Make your initial search request.

      2. The response dictionary will contain a key named page.

      3. If this page key holds a non-empty string value, there are more results available.

      4. To fetch the next page, make a subsequent API call. This call MUST include the exact same parameters as your original request (query, size, since, until, doc_type, etc.), PLUS the page parameter set to the token value received in the previous response's page field.

      5. Continue this process, using the new page token from each response, until the page field is absent or empty in the response, indicating the end of the results.

Tokenization:

  • DTM breaks documents into tokens.

  • Example: "some-domain.com" -> "some", "domain", "com".

  • Wildcard/Regex queries match single tokens, not phrases.

Special Characters:

  • Escape with : + - & | ! ( ) { } [ ] ^ " ~ * ? : / and space.

  • Example: To find "(1+1):2", query (1+1):2

Case Sensitivity:

  • DTM entity values are often lowercased.

  • Boolean operators (AND, OR, NOT) MUST be UPPERCASE.

Domain Search Nuances:

  • Use wildcards/regex on fields like doc.domain.

  • Example: doc.domain:google.*.dev

  • Avoid pattern searches on group_network.

Performance Limit:

  • Searches timeout after 60 seconds.

  • For broad or complex queries, it is highly recommended to use the since and until parameters to add time delimiters. This narrows the search scope and helps prevent timeouts.

Noise Reduction:

  • Use typed entities for higher precision.

  • Example: organization:"Acme Corp"

  • Prefer typed entities over free text searches.

The following fields and their meanings can be used to compose a query using Lucene syntax (including combining them with AND, OR, and NOT operators along with parentheses):

  • author.identity.name - The handle used by the forum post author

  • subject - The subject line of the forum post

  • body - The body text of the content

  • inet_location.url - What URL content was found

  • language - The content language

  • title - The title of the web page

  • channel.name - The Telegram channel name

  • domain - A DNS domain name

  • cve - A CVE entry by ID

__type: one of the following

  • web_content_publish - General website content

  • domain_discovery - Newly discovered domain names

  • forum_post - Darkweb forum posts

  • message - Chat messages like Telegram

  • paste - Paste site content like Pastebin

  • shop_listing - Items for sale on the dark web

  • email_analysis - Suspicious emails

  • tweet - Tweets from Twitter on cybersecurity topics.

  • document_analysis - Documents (PDF, Office, text) from VirusTotal, including malicious and corporate confidential files.

label_threat: one of the following

  • information-security/anonymization - Anonymization

  • information-security/apt - Advanced Persistent Threat

  • information-security/botnet - Botnet

  • information-security/compromised - Compromised Infrastructure

  • information-security/doxing - Personal Information Disclosure

  • information-security/exploit - Exploits

  • information-security/phishing - Phishing

  • information-security/information-leak - Information Leak

  • information-security/information-leak/confidential - Confidential Information Leak

  • information-security/information-leak/credentials - Credential Leak

  • information-security/information-leak/payment-cards - Credit Card Leak

  • information-security/malicious-activity - Malicious Activity

  • information-security/malicious-infrastructure - Malicious Infrastructure

  • information-security/malware - Malware

  • information-security/malware/ransomware - Ransomware

  • information-security/malware/ransomware-victim-listing - Ransomware Victim Listing

  • information-security/security-research - Security Research

  • information-security/spam - Spam

Args: query (required): The Lucene-like query string for your document search. size (optional): The number of results to return in each page (0 to 25). Defaults to 10. since (optional): The timestamp to search for documents since (RFC3339 format). until (optional): The timestamp to search for documents from (RFC3339 format). page (optional): The page ID to fetch the page for. This is only used when paginating through pages greater than the first page of results. truncate (optional): The number of characters (as a string) to truncate all documents fields in the response (e.g., '500'). sanitize (optional): If true (default), any HTML content in the document fields are sanitized to remove links, scripts, etc.

Returns: A dictionary containing the list of documents found and search metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
sizeNo
queryYes
sinceNo
untilNo
sanitizeNo
truncateNo
Behavior4/5

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

With no annotations, the description carries the full burden. It clearly explains pagination behavior, the 60-second timeout, tokenization, special character escaping, and sanitization. While it doesn't explicitly state that the tool is read-only, the search context and detail imply safe operation. The disclosure of performance pitfalls enhances transparency.

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

Conciseness3/5

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

The description is very long and includes extensive examples, a full field list, and many considerations. While well-structured with headings and bullet points, it could be more concise without losing essential information. Some redundancy exists (e.g., repeating the field list separately when already in query examples).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 7 parameters and no output schema, the description covers query syntax, field meanings, pagination, performance, and edge cases. It lacks explicit details about the response structure (only mentions 'dictionary with documents and metadata'), but the examples and pagination description partially compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It richly documents all parameters: query (required, Lucene syntax), size (max 25, default 10), since/until (RFC3339 with Z), page (pagination token), truncate (character limit), sanitize (default true). It also lists usable fields and their meanings, far exceeding schema titles.

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?

The description clearly states it searches historical data in Digital Threat Monitoring using Lucene syntax. It immediately distinguishes itself from sibling tools like search_campaigns or get_threat_profile, which focus on specific entity types, by indicating it covers surface, deep, and dark web documents broadly.

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?

The description provides extensive guidance on query construction, filtering by type and threat, pagination, date formatting, performance limits, and noise reduction. However, it does not explicitly state when NOT to use this tool or alternative search tools like search_threat_reports, leaving a minor gap.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jmaciasc-google/gti-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server