What can you do with this server?

The Google Threat Intelligence MCP Server provides access to Google Threat Intelligence (VirusTotal + Mandiant) for searching, analyzing, and managing threat data. Key capabilities include: Threat & Collection Intelligence * Search across threats, campaigns, threat actors, malware families, software toolkits, reports, and vulnerabilities * Retrieve full collection reports, related entities, MITRE ATT&CK trees, timelines, YARA/Sigma/IDS rules, and IOC commonalities * Create, update, and manage threat collections (attributes and IOCs) File & Artifact Analysis * Analyze files by hash (MD5/SHA-1/SHA-256) for detections and classifications * Retrieve sandbox behavior reports and summaries * Upload files for multi-engine VirusTotal scanning * Pivot from files to contacted domains/IPs/URLs, dropped files, malware families, and more Domain, IP & URL Intelligence * Analyze domains (passive DNS, registrar, reputation), IPs (geolocation, ASN), and URLs (maliciousness, classifications) * Pivot to related files, resolutions, SSL certificates, WHOIS, threat actors, and campaigns * Search IOCs using advanced search modifiers Threat Profiles * List and retrieve organizational threat profiles (targeted industries, regions, actor motivations) * Get ML-recommended threats and association timelines for a profile Digital Threat Monitoring (DTM) * Search historical documents from surface, deep, and dark web sources (forums, Telegram, paste sites, shop listings, emails, tweets) using Lucene syntax Hunting Rulesets * Retrieve YARA hunting rulesets and find files that matched them

Which integrations are available for this server?

Allows AI agents to access Google Threat Intelligence (VirusTotal) data including IOC search, file/domain/IP/URL reports, and threat hunting rulesets.

How do I use Google Threat Intelligence MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Threat Intelligence MCP Server get report for IP 8.8.8.8" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Google Threat Intelligence MCP Server

by jmaciasc-google

Overview Schema Related Servers Score Discussions

Python

Hybrid

Google Threat Intelligence MCP Server

A production-ready, highly optimized Model Context Protocol (MCP) server for Google Threat Intelligence (GTI) (incorporating VirusTotal and Mandiant threat analytics). This server supports cloud-native network deployments via Stateless HTTP (streamable-http) or Server-Sent Events (SSE), making it fully compatible with Google Cloud Run or any other container-native environment.

Project Origin & Deployment Philosophy

This repository is 100% based on the official Google open-source implementation hosted in the google/mcp-security repository.

While the official project is designed as a broad, developer-focused, multi-tool mono-repo, this project was created specifically to empower non-technical users, security analysts, and IT administrators to deploy a secure, enterprise-grade Google Threat Intelligence (GTI) MCP server in minutes with zero friction.

🔍 How This Repository Differs from the Official Mono-Repo

Feature / Aspect	Official Google `mcp-security` Mono-Repo	This Dedicated GTI Project
Project Focus	Multi-server (SCC, SecOps, SOAR, GTI) developers workspace.	100% focused on Google Threat Intelligence (GTI). Completely stripped of unrelated bloat.
Nesting Structure	Nested deeply under `/server/gti` folders.	Flattened to the root. Clean git clone and run.
Secrets Security	Basic environment variables (risk of plaintext leak).	Strictly Enforced Google Secret Manager.
Cloud Deployment	Minimal developer deployment scaffolding.	Production-ready Google Cloud Run templates.
User Onboarding	Targeted at software developers and engineers.	Designed for non-technical users, complete with beginner-friendly command guides.
No-Agent Verification	Requires setting up and connecting an LLM desktop client.	Instant, zero-agent verification via a dynamic, automated `verify.sh` script.

IMPORTANT

Production Security Mandate: To ensure enterprise compliance and prevent credential leakage, this deployment strictly requires the use of Google Secret Manager to store and load your API key. Direct injection of plaintext credentials via environment variables is disabled/prohibited for cloud deployments.

Related MCP server: MITRE ATT&CK MCP Server

Core Features

This MCP server exposes high-performance threat intelligence endpoints to any compatible LLM agent.

🔍 Intelligence & Hunting

search_iocs(query, limit): Queries Indicators of Compromise (IOCs) using advanced search filters.
get_hunting_ruleset & get_entities_related_to_a_hunting_ruleset: Accesses and maps structured threat detection signatures.

📁 Files & Artifacts

get_file_report(hash): Inspects MD5, SHA1, or SHA256 hashes to check multi-engine detections and threat actor classifications.
get_file_behavior_report(id) & get_file_behavior_summary(hash): Retreives deep sandbox execution data.

🌐 Domains, IPs, and URLs

get_domain_report(domain) & get_entities_related_to_a_domain: Resolves passive DNS mappings, registrar details, and reputational classifications.
get_ip_address_report(ip_address): Retrieves geolocations, Autonomous System Numbers (ASN), and detections.
get_url_report(url) & get_entities_related_to_an_url: Inspects specific URLs.

Configuration & Customization (Optional)

This project is pre-configured and completely ready to run out-of-the-box. You do not need to modify any of these files to deploy. However, if you have specific network or architectural requirements, you can customize these configuration files:

File Path	Purpose	Modification Details
`docker-compose.yml`	Local Container Config	Change the container port mappings or local environment references if needed.
`Dockerfile`	Image Build Spec	Customize the base Python version or update build-stage packages.

IMPORTANT

Zero-Credential File Design: No secrets or API keys are written to disk in this repository. Local development utilizes memory-only shell environment variables, and production environments strictly load keys from cloud-managed secret vaults.

Getting Started

Regardless of whether you plan to run the server locally, package it in a container, or deploy it directly to Google Cloud Run, you must first clone the repository and navigate into the project directory:

# Clone this repository
git clone <your-repository-url>

# Enter the project directory
cd gti-mcp-server

🚀 Choose Your Path

Once inside the directory, choose the section that matches your goal:

💻 Laptop (Python): Proceed to Local Development & Setup.
🐳 Local Docker Container: Skip to Containerization & Docker.
☁️ Google Cloud Run (Production): Skip to Production Google Cloud Run Deployment.

Local Development & Setup

Prerequisites

Python 3.11 or higher.
A valid Google Threat Intelligence (VirusTotal) API key.

Quick Start (Local Python)

Configure your API Key (In-Memory Only): Export your Google Threat Intelligence API key directly in your terminal session. This key resides only in your shell's temporary RAM and is never written to disk:
```
export VT_APIKEY="your_actual_gti_api_key_here"
```

Install the package and dependencies:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install -e .

Run the server locally:
Start the server in SSE/HTTP network mode. This boots the server as an HTTP service listening on port 8000 by default and outputs active startup logs once initialized:
```
gti-mcp-server
```

🧪 Verifying Your Local SSE Server (No Agent Required)

Because Model Context Protocol (MCP) uses Server-Sent Events (SSE) under the hood, you can verify your local server using standard command-line tools without needing a desktop AI client or agent installed.

This test requires two additional terminal windows (or tabs), leaving your local server running in your current window from the previous step:

Step 1: Run the Server (Terminal Window 1)

This is the server you already started in the previous Quick Start step! (If you stopped it, simply open Terminal Window 1, activate your virtual environment, and run gti-mcp-server again). Leave this server running.

Step 2: Open the Event Stream (Terminal Window 2)

Establish a streaming SSE connection. Because SSE is a streaming protocol, this connection will stay open ("hanging") to capture real-time responses:

curl -i -N http://localhost:8000/sse

What you will see: It will connect instantly and output the initial dynamic connection endpoint along with a unique session ID:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

event: endpoint
data: /messages/?session_id=a1b2c3d4e5f6...

Leave this window running and copy your generated session_id.

Step 3: Perform the Handshake and Run Queries (Terminal Window 3)

In your third terminal window, run the following three requests sequentially (substituting your copied session_id) to complete the protocol handshake and list your tools:

Initialize the MCP Session:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {},
      "clientInfo": {
        "name": "curl-test-client",
        "version": "1.0"
      }
    }
  }' \
  "http://localhost:8000/messages/?session_id=YOUR_ACTIVE_SESSION_ID"

(Check Terminal Window 1: you will see a streamed message event containing the server's protocol capabilities).

Confirm Handshake Completion:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "notifications/initialized"
  }' \
  "http://localhost:8000/messages/?session_id=YOUR_ACTIVE_SESSION_ID"

List Available Threat Intelligence Tools:

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/list",
    "params": {}
  }' \
  "http://localhost:8000/messages/?session_id=YOUR_ACTIVE_SESSION_ID"

Look back at Terminal Window 1: You will see a complete, beautiful JSON-RPC stream containing all your Google Threat Intelligence capabilities (get_file_report, search_iocs, etc.)!

Containerization & Docker (Alternative)

This server is pre-configured with a secure, multi-stage Docker build spec and a companion Docker Compose layout.

Since docker-compose.yml is configured to build your container automatically, you do not need to run a separate build command! You can compile the image and launch the container on-the-fly with a single command:

# Make sure your API key is in your active terminal environment
export VT_APIKEY="your_actual_gti_api_key_here"

# Compile and start the server in the background
docker compose up -d

This starts the containerized server in the background, maps port 8000 to port 8000 on your host computer, and passes your terminal's ${VT_APIKEY} directly into the secure container memory.

Production Google Cloud Run Deployment (Strict Secret Manager)

This section provides a secure-by-default, step-by-step walkthrough for deploying to Google Cloud Run. It uses Google Secret Manager for credential storage and restricts invocations using GCP IAM OIDC Authentication (disallowing unauthenticated access).

Step 1: Set Your Deployment Variables

Replace the placeholder values below with your GCP details:

PROJECT_ID="your-gcp-project-id"   # Your GCP Project ID
REGION="us-central1"               # GCP Region to deploy to
REPO="mcp-servers"                 # Artifact Registry Repository name
IMAGE="gti-mcp-server"             # Container Image name

Step 2: Authenticate and Enable Required GCP Services

Authenticate your local shell session with Google Cloud and enable the APIs required for container hosting and secure secret storage:

# Authenticate your local shell session with Google Cloud
gcloud auth login

# Set your active gcloud project context
gcloud config set project ${PROJECT_ID}

# Enable Secret Manager, Artifact Registry, and Cloud Run APIs
gcloud services enable \
  secretmanager.googleapis.com \
  artifactregistry.googleapis.com \
  run.googleapis.com

Step 3: Secure your API Key in Google Secret Manager

Create a managed secret to host your Google Threat Intelligence (VirusTotal) API key securely:

Create the Secret container:

gcloud secrets create VT_APIKEY --replication-policy="automatic"

Add your API key value as version 1 of the secret: Replace YOUR_ACTUAL_GTI_API_KEY with your actual token:
```
echo -n "YOUR_ACTUAL_GTI_API_KEY" | gcloud secrets versions add VT_APIKEY --data-file=-
```

Step 4: Grant Access to the Cloud Run Service Account

Cloud Run services run under a designated service account. By default, Cloud Run uses the Compute Engine default service account to call other GCP APIs.

Get your Project Number:

PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
echo "Your Project Number is: ${PROJECT_NUMBER}"

Determine the Default Service Account Email: The default service account email follows the pattern: ${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Grant Secret Accessor permission to this service account: This authorizes the Cloud Run container to fetch and decrypt the secret at startup:

gcloud secrets add-iam-policy-binding VT_APIKEY \
  --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

Step 5: Deploy to Cloud Run (Choose Your Path)

You can choose either of these two paths to compile and deploy your server. Option A is highly recommended for non-technical users as it does not require Docker or manual registry configurations!

🚀 Option A: Direct Source-to-Cloud Deployment (No Local Docker Required)

This is the fastest, simplest method. Google Cloud will securely package your source directory, upload it, run Google Cloud Build in the background using your Dockerfile, automatically provision a private Artifact Registry under the hood, and deploy the service.

Simply run this single command from your repository root:

gcloud run deploy gti-mcp-server \
  --source . \
  --region=${REGION} \
  --platform=managed \
  --no-allow-unauthenticated \
  --set-secrets="VT_APIKEY=VT_APIKEY:latest" \
  --set-env-vars="TRANSPORT=http,STATELESS=1" \
  --port=8000 \
  --max-instances=5 \
  --cpu=1 \
  --memory=512Mi \
  --no-cpu-throttling

🐳 Option B: Traditional Docker Build, Push, & Deploy

Choose this path if you prefer to compile, tag, and push your container image using Docker running locally on your laptop:

Create the Docker repository in Artifact Registry:

gcloud artifacts repositories create ${REPO} \
  --repository-format=docker \
  --location=${REGION} \
  --description="MCP Servers Repository"

Authenticate Docker to push to your GCP registry:

gcloud auth configure-docker ${REGION}-docker.pkg.dev

Build and Tag the image (Intel/AMD64 target format):

docker build --platform linux/amd64 -t ${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO}/${IMAGE}:latest .

Push the image to GCP:

docker push ${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO}/${IMAGE}:latest

Deploy the pushed image to Cloud Run:

 gcloud run deploy gti-mcp-server \
   --image=${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO}/${IMAGE}:latest \
   --region=${REGION} \
   --platform=managed \
   --no-allow-unauthenticated \
   --set-secrets="VT_APIKEY=VT_APIKEY:latest" \
   --set-env-vars="TRANSPORT=http,STATELESS=1" \
   --port=8000 \
   --max-instances=5 \
   --cpu=1 \
   --memory=512Mi \
   --no-cpu-throttling

Step 6: Retrieve and Save Your Cloud Run Service URL

Once successfully deployed, retrieve your Cloud Run live service URL and export it as an environment variable in your terminal session. This variable is required to register your server with Gemini Enterprise later:

SERVICE_URL=$(gcloud run services describe gti-mcp-server --region=${REGION} --format="value(status.url)")
echo "Your live Service URL is: ${SERVICE_URL}"

[NOTE] Setting host="0.0.0.0" in our server configuration ensures that the container is fully compatible with Cloud Run and can accept incoming production connections smoothly.

🧪 Verifying Your Cloud Run Stateless HTTP Server (No Agent Required)

Once your service is deployed, you can verify that the live production server is functioning, authenticated, and communicating properly over the network without needing to set up an AI agent first.

Using the official Google Cloud secure proxy is the simplest, safest, and most recommended method because it handles OAuth authentication and Host headers automatically.

This test requires two separate terminal windows (or tabs):

Step 1: Start the Cloud Run Proxy (Terminal Window 1)

Run this command to boot up a secure local authentication tunnel mapped to port 8000:

gcloud run services proxy gti-mcp-server --region=${REGION} --port 8000

Leave this terminal running. It will output a confirmation log indicating that port 8000 is proxying to your secure Cloud Run service.

Step 2: Query the Tools List (Terminal Window 2)

In your second terminal window, send a single JSON-RPC POST request to the proxied server at /mcp to list all available tools:

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {}
  }' \
  "http://localhost:8000/mcp"

What you will see: It will connect instantly and output a beautiful JSON-RPC response containing your entire suite of Google Threat Intelligence tools (get_file_report, search_iocs, etc.) served directly from your secure Cloud Run deployment!

Gemini Enterprise Integration (Optional)

You can easily connect and register this secure Cloud Run MCP server directly with your Gemini Enterprise App (such as default-chat within Vertex AI Agent Builder) using a 100% command-line driven Discovery Engine custom MCP data store workflow.

Follow these command-driven steps to enable the required APIs, configure your OAuth identity provider, create your data store, authorize security, enable threat intelligence actions, and link them to Gemini:

Step 1: Enable Required APIs

Enable the advanced core APIs required for Discovery Engine custom datastores first, as initialization may take a minute:

gcloud services enable discoveryengine.googleapis.com \
  --project=${PROJECT_ID}

Step 2: Define Your OAuth Endpoints

Configure your session variables for your OAuth identity provider (required by Discovery Engine to federate and authenticate custom MCP servers):

# Default Google Cloud Identity OAuth 2.0 endpoints (change these if you are using a custom/external Identity Provider)
AUTH_URL="https://accounts.google.com/o/oauth2/v2/auth"
TOKEN_URL="https://oauth2.googleapis.com/token"

Step 3: Create an OAuth Client ID

Because OAuth Clients cannot be created programmatically via gcloud APIs, you must create one manually in the Google Cloud Console:

Navigate to the Google Cloud Console API Credentials page.
Click Create Credentials > OAuth client ID.
Select Web application as the application type.
Name your client (e.g., GTI MCP Server Client).
Under Authorized redirect URIs, add any redirect URIs if required by your identity environment.
Click Create and copy your Client ID and Client Secret.

Once you have your credentials, define them in your active terminal session:

CLIENT_ID="your-client-id"                      # Replace with your copied OAuth Client ID
CLIENT_SECRET="your-client-secret"              # Replace with your copied OAuth Client Secret

TIP

For more details on Google's OAuth 2.0 implementation and general concepts, refer to theOfficial Google Identity OAuth 2.0 Documentation.

Step 4: Create the Custom MCP Data Store (via setUpDataConnector REST API)

Because the discoveryengine command group is not standard in the public gcloud SDK, use curl to invoke the Discovery Engine custom MCP setup API directly.

First, define your Discovery Engine settings:

LOCATION="us"                           # Discovery Engine location (e.g., us, global)
COLLECTION_ID="gti-mcp-server-collection"  # Your unique collection identifier
DISPLAY_NAME="Google Threat Intelligence Tools"

Now, execute the API call to establish a federated custom MCP connector:

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: ${PROJECT_ID}" \
  -H "Content-Type: application/json" \
  -d '{
    "collectionDisplayName": "'"${DISPLAY_NAME}"'",
    "dataConnector": {
      "dataSource": "custom_mcp",
      "connectorSourceId": "custom_mcp",
      "params": {
        "oauth_access_token": "unused",
        "auth_type": "AUTHORIZATION_TYPE_UNDEFINED"
      },
      "refreshInterval": "86400s",
      "entities": [
        {
          "entityName": "mcp_data"
        }
      ],
      "dataSourceVersion": 1,
      "staticIpEnabled": false,
      "actionConfig": {
        "actionParams": {
          "instance_uri": "'"${SERVICE_URL}"'/mcp",
          "auth_uri": "'"${AUTH_URL}"'",
          "token_uri": "'"${TOKEN_URL}"'",
          "client_id": "'"${CLIENT_ID}"'",
          "client_secret": "'"${CLIENT_SECRET}"'",
          "scopes": "openid",
          "auth_type": "OAUTH",
          "mcp_server_description": "Google Threat Intelligence (GTI) MCP server. Exposes tools to query Indicators of Compromise (IOCs), threat analytics, domain and IP address intelligence, and file/artifact reputation or sandbox analysis.",
          "mcp_agent_instructions": "You are a security analyst assistant. Use this Google Threat Intelligence (GTI) MCP server to analyze security threats, investigate network artifacts (domains, IPs, URLs), and query file reports or execution behaviors. Always validate hash formats (MD5, SHA1, SHA256) and ensure domain inputs are stripped of protocol schemas before querying.",
          "mcp_server_source": "BYO_MCP"
        },
        "createBapConnection": true,
        "isActionConfigured": false
      },
      "connectorModes": [
        "FEDERATED"
      ]
    }
  }' \
  "https://${LOCATION}-discoveryengine.googleapis.com/v1alpha/projects/${PROJECT_ID}/locations/${LOCATION}:setUpDataConnector?collectionId=${COLLECTION_ID}"

Step 5: Authorize the Gemini Enterprise Service Account (IAM)

Because your Cloud Run service is locked down securely (--no-allow-unauthenticated), you must explicitly authorize the Gemini Enterprise Discovery Engine system service account to call and invoke your Cloud Run endpoint.

Run these commands to bind the Cloud Run Invoker role:

# Retrieve your active Discovery Engine system service account email
DISCOVERY_ENGINE_SA="service-${PROJECT_NUMBER}@gcp-sa-discoveryengine.iam.gserviceaccount.com"

# Grant it invoker rights to your Cloud Run service
gcloud run services add-iam-policy-binding gti-mcp-server \
    --member="serviceAccount:${DISCOVERY_ENGINE_SA}" \
    --role="roles/run.invoker" \
    --region=${REGION} \
    --project=${PROJECT_ID}

Step 6: Reload and Enable Your Actions (GCP Console UI)

Because the custom actions discovery and OAuth consent handshake are handled securely by Google Cloud Console's frontend, you must perform a one-time manual reload to authorize and activate your threat intelligence tools:

Open the Google Cloud Agent Builder Data Stores Console.
Select your newly created Google Threat Intelligence Tools data store.
Click on the Actions tab on the left-hand navigation pane.
If prompted, click Re-authenticate to sign in and complete the OAuth connection.
Click the Reload custom actions button. This will connect to your Cloud Run service's /mcp endpoint and dynamically populate all 45+ GTI tools.
Select the tools you want to enable, and click Enable actions.

Step 7: Link the Custom MCP Data Store to your Gemini App (GCP Console UI)

Finally, link your newly configured threat intelligence data store to your active Gemini App configuration (e.g., your chat or search application):

Open the Gemini Enterprise Console.
In the left-hand navigation pane, click on Apps
Click on your Gemini Enterprise application
In the left-hand navigation pane, click on Connected data stores.
Click Add existing data store
Select your newly created Google Threat Intelligence Tools data store from the list.
Click Connect (or Save) to confirm.

Your Gemini Enterprise conversational app is now fully integrated with real-time Google Threat Intelligence capabilities, securely authorized, and ready to assist your security operations team! 🚀

Available Tools

36 tools

analyse_fileA

Upload and analyse the file in VirusTotal.

The file will be uploaded to VirusTotal and shared with the community.

Args: file_path (required): Path to the file for analysis. Use absolute path. Returns: The analysis report.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes

TDQS

A4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses critical behavior: the file will be shared with the community (public disclosure). This is a key transparency point. However, it lacks details on rate limits, authentication requirements, or what happens if the file already exists.

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?

The description is relatively concise with an Args/Returns structure. Every sentence adds value, though it could be slightly more streamlined without losing clarity.

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

Completeness3/5

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

Given no output schema, the description mentions returns 'The analysis report' but is vague about its format. For a simple upload tool, this may be sufficient, but more detail on the report structure would enhance completeness.

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 has one parameter (file_path) with no description. The description adds 'Use absolute path', providing guidance beyond the schema. Schema description coverage is 0%, so description compensates well.

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 'Upload and analyse the file in VirusTotal' with a specific verb and resource. It distinguishes from sibling tools that are read-only (e.g., get_file_report) by indicating this tool performs an upload.

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

Usage Guidelines3/5

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

Usage context is implied by describing the upload action, but no explicit guidelines on when to use this tool versus alternatives (e.g., get_file_report for existing analyses). No when-not-to-use or prerequisite information.

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

create_collectionA

Creates a new collection in Google Threat Intelligence. Ask for the collection's privacy (public or private) if the user doesn't specify.

Args: name (required): The name of the collection. description (required): A description of the collection. iocs (required): Indicators of Compromise (IOCs) to include in the collection. The items in the list can be domains, files, ip_addresses, or urls. At least one IOC must be provided. private: Indicates whether the collection should be private. Returns: A dictionary representing the newly created collection.

ParametersJSON Schema

Name	Required	Description	Default
`iocs`	Yes
`name`	Yes
`private`	No
`description`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries full burden but only covers basic behavior (creation, asking for privacy). It omits details like whether the operation is idempotent, effects on existing collections, authentication requirements, or rate limits.

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?

The description is concise, with two clear paragraphs. The first states purpose and an action prompt, the second details parameters. No redundant sentences, though the 'Ask' instruction could be integrated.

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

Completeness3/5

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

Given the lack of annotations and schema descriptions, the description provides adequate context but misses details about asynchronous behavior, error handling, and prerequisites. The presence of an output schema reduces the need for return value explanation.

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 0%, so the description compensates well by explaining 'iocs' as a list of IOC types and requiring at least one, and clarifying that 'private' indicates privacy. This adds significant meaning beyond the schema's type and default.

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 uses the specific verb 'Creates' and the resource 'collection', clearly stating the tool's function. It also instructs to ask for privacy if not specified, distinguishing it from sibling tools which are primarily retrieval or update operations.

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

Usage Guidelines2/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives. It lacks comparisons to sibling tools like 'update_collection_attributes' and offers no context for when creation is appropriate.

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

get_collection_feature_matchesB

Retrieves Indicators of Compromise (IOCs) from a collection that match a specific feature.

This tool allows pivoting from a commonality to the specific IOCs within a collection that exhibit that feature. Commonalities are shared characteristics and hidden relationships between various Indicators of Compromise (e.g., files, URLs, domains, IPs).

Available feature types by entity type: Files:

android_certificates, android_main_activities, android_package_names, attributions, behash, collections, compressed_parents, contacted_domains, contacted_ips, contacted_urls, crowdsourced_ids_results, crowdsourced_yara_results, elfhash, email_parents, embedded_domains, embedded_ips, embedded_urls, execution_parents, imphash, itw_domains, itw_urls, mutexes_created, mutexes_opened, pcap_parents, registry_keys_deleted, registry_keys_opened, registry_keys_set, tags, vhash, file_types, crowdsourced_sigma_results, deb_info_packages, debug_codeview_guids, debug_codeview_names, debug_timestamps, dropped_files_path, dropped_files_sha256, elfinfo_exports, elfinfo_imports, exiftool_authors, exiftool_companies, exiftool_create_dates, exiftool_creators, exiftool_last_modified, exiftool_last_printed, exiftool_producers, exiftool_subjects, exiftool_titles, filecondis_dhash, main_icon_dhash, main_icon_raw_md5, netassembly_mvid, nsrl_info_filenames, office_application_names, office_authors, office_creation_datetimes, office_last_saved, office_macro_names, permhash, pe_info_imports, pe_info_exports, pe_info_section_md5, pe_info_section_names, pwdinfo_values, sandbox_verdicts, signature_info_comments, signature_info_copyrights, signature_info_descriptions, signature_info_identifiers, signature_info_internal_names, signature_info_original_names, signature_info_products, symhash, trusted_verdict_filenames, rich_pe_header_hash, telfhash, tlshhash, email_senders, email_subjects, popular_threat_category, popular_threat_name, suggested_threat_label, attack_techniques, malware_config_family_name, malware_config_campaign_id, malware_config_campaign_group, malware_config_dga_seed, malware_config_dns_server, malware_config_service, malware_config_registry_key, malware_config_event, malware_config_pipe, malware_config_mutex, malware_config_folder, malware_config_file, malware_config_process_inject_target, malware_config_crypto_key, malware_config_displayed_message, malware_config_c2_url, malware_config_download_url, malware_config_misc_url, malware_config_decoy_url, malware_config_c2_user_agent, malware_config_download_user_agent, malware_config_misc_user_agent, malware_config_decoy_user_agent, malware_config_c2_password, malware_config_misc_username, malware_config_misc_password, malware_config_host_port, malware_config_dropped_file, malware_config_dropped_file_path, malware_config_registry_value, malware_config_download_password, malware_config_c2_username, malware_config_download_username, malware_config_exfiltration_username, malware_config_exfiltration_password, malware_config_exfiltration_url, malware_config_exfiltration_user_agent, malware_config_pivot_hash, memory_pattern_urls

Domains:

attributions, collections, communicating_files, downloaded_files, favicon_dhash, favicon_raw_md5, urls, registrant_names

IP Addresses:

attributions, collections, communicating_files, downloaded_files, urls

URLs:

attributions, http_response_contents, collections, contacted_domains, communicating_files, cookie_names, cookie_values, downloaded_files, domains, embedded_js, favicon_dhash, favicon_raw_md5, html_titles, ip_addresses, memory_patterns, outgoing_links, path, prefix_paths, suffix_paths, ports, users, passwords, user_passwords, query_strings, query_param_keys, query_param_values, query_param_key_values, referring_files, tags, tracker_ids

Args: collection_id (required): The ID of the collection to search within. feature_type (required): The type of feature to search for (e.g., 'attack_techniques'). feature_id (required): The specific value of the feature (e.g., 'T1497.001'). entity_type (required): search_space (required): The scope of the search. Use 'collection' to search only within the specified collection, or 'corpus' to search across the entire VirusTotal dataset. entity_type_plural (required): The plural of 'entity_type'. descriptors_only (optional): Returns only the descriptors. Returns: A dictionary containing the list of matching IOCs.

ParametersJSON Schema

Name	Required	Description	Default
`feature_id`	Yes
`entity_type`	Yes
`feature_type`	Yes
`search_space`	Yes
`collection_id`	Yes
`descriptors_only`	No
`entity_type_plural`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states it retrieves IOCs and returns a dictionary, but does not disclose any behavioral traits such as read-only nature, rate limits, pagination, or side effects. The list of feature types is present but does not cover behavioral aspects.

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 front-loaded with the purpose, but the extensive list of feature types occupies significant space. While structured into sections, the verbosity could be reduced by referencing external documentation. It is informative but not optimally concise.

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

Completeness2/5

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

Despite the output schema, the description fails to fully guide on required parameters like entity_type (allowed values implied but not explicit). It explains the concept well but leaves practical gaps. The feature type list adds some completeness, but parameter details are insufficient for an agent to reliably fill all parameters.

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

Parameters3/5

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

Schema coverage is 0%, so description must compensate. It provides some parameter details: search_space options, entity_type_plural definition, and descriptors_only description. However, many parameters like feature_type and entity_type lack explicit allowed values or formats beyond the extensive list, leaving gaps.

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 retrieves IOCs matching a specific feature from a collection, with the verb 'retrieves' and specific resource (IOCs from a collection). It distinguishes from siblings like 'get_entities_related_to_a_collection' by focusing on feature matching.

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 explains the use case of pivoting from commonalities to IOCs, providing context for when to use. However, it does not explicitly state when not to use or compare with related tools like 'get_collection_commonalities', but the implication is clear.

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

get_collection_mitre_treeB

Retrieves the Mitre tactics and techniques associated with a threat.

Args: id (required): Collection identifiers. Return: A dictionary including the tactics and techniques associated to the given threat.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, description must fully convey behavior. It states it retrieves data and returns a dictionary, but omits details on error handling, authorization, performance, or any side effects. Minimal transparency.

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?

Concise at two sentences plus structured Args/Return. Purpose is front-loaded. Minor inefficiency: 'Args:' and 'Return:' section could be considered redundant but clear.

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

Completeness3/5

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

Given low complexity and presence of output schema, description explains return format adequately. However, it lacks context on prerequisites (e.g., collection must exist) and potential errors.

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

Parameters2/5

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

Schema coverage is 0%; description only says 'Collection identifiers' for the 'id' parameter, adding little beyond the schema's type and requirement. Does not specify format or example.

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?

Clearly specifies verb 'Retrieves' and resource 'Mitre tactics and techniques associated with a threat'. Distinguishes from siblings like get_collection_report which focus on other attributes.

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

Usage Guidelines2/5

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

No guidance on when to use this vs alternatives (e.g., get_collection_report, get_collection_feature_matches). Does not mention prerequisites or exclusions.

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

get_collection_reportB

At Google Threat Intelligence, threats are modeled as "collections". This tool retrieves them from the platform.

They have different collections types like:

"malware-family"
"threat-actor"
"campaign"
"report"
"collection".

You can find the collection type in the "collection_type" field.

Args: id (required): Google Threat Intelligence identifier. Returns: A collection object. Put attention to the collection type to correctly understand what it represents.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It correctly describes the tool as retrieving a collection and notes the importance of collection_type, but does not explicitly state read-only nature or other behavioral traits.

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?

The description is structured with Args/Returns and is reasonably concise. A minor redundancy in mentioning 'Google Threat Intelligence' twice, but overall efficient.

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

Completeness3/5

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

Given output schema exists, return value details are not required. However, the description lacks usage context relative to sibling tools and could more fully explain when this tool is appropriate.

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

Parameters3/5

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

Schema coverage is 0%, so description must compensate. It identifies 'id' as a required Google Threat Intelligence identifier, adding context beyond the schema but lacking format specifics.

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 explicitly states it retrieves collections, which are threat models at Google Threat Intelligence. It lists collection types, distinguishing it from sibling tools that handle specific entities or operations.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus sibling tools like search_threat_actors or get_domain_report. The description does not provide when-to-use or when-not-to-use context.

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

get_collection_rulesA

Retrieve top N community rules and all curated hunting rules for a specific collection.

Note: The rule_types argument filters the types of rules returned. Available types are:

'crowdsourced_ids'
'crowdsourced_sigma'
'crowdsourced_yara'
'curated_yara_rule' If rule_types is not provided, all types are returned.

Example:

rule_types=['crowdsourced_yara']: Only crowdsourced YARA rules.
rule_types=['crowdsourced_ids', 'curated_yara_rule']: Crowdsourced IDS and curated YARA rules.

Args: collection_id (required): The ID of the collection. top_n (optional): The number of top community rules to return from each category. Defaults to 4. rule_types (optional): List of rule types to fetch.

Returns: A list of dictionaries, where each dictionary contains a rule and its metadata, or an error dictionary.

ParametersJSON Schema

Name	Required	Description	Default
`top_n`	No
`rule_types`	No
`collection_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations are not provided, so the description carries full burden. It describes the basic return behavior (list of dicts or error) and the rule types filter, but lacks details on side effects, rate limits, or authentication requirements. This is adequate but not richly transparent.

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?

The description is well-structured with clear sections (main action, note on rule_types, example, args, returns). Each sentence adds value; the note and example are particularly helpful. No unnecessary fluff.

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?

The tool has three parameters (one required) and an output schema. The description explains the return format (list of dicts with rule and metadata or error) and covers all input semantics. It is complete enough for an agent to understand how to invoke the tool correctly.

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 0% schema description coverage, the description compensates well. It provides meaningful context for each parameter: collection_id (ID of collection), top_n (number of top community rules from each category, default 4), and rule_types (list of types with possible values and an example). This adds significant value beyond the schema's raw types and defaults.

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 the tool retrieves 'top N community rules and all curated hunting rules for a specific collection.' It uses a specific verb ('Retrieve') and resource ('rules for a collection'), and distinguishes it from sibling tools like get_collection_report or get_hunting_ruleset.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention when not to use it or compare to siblings like get_hunting_ruleset, leaving the agent to infer usage context.

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

get_collections_commonalitiesB

Retrieve the common characteristics or features (attributes / relationships) of the indicators of compromise (IoC) within a collection, identified by its ID. Args: collection_id (required): Collection identifier. Returns: Markdown-formatted string with the commonalities of the collection.

ParametersJSON Schema

Name	Required	Description	Default
`collection_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

No annotations, so description carries the burden. It does mention the return is a Markdown-formatted string, but lacks details on side effects, prerequisites, or whether it is read-only.

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?

Concise with a clear structure: purpose, args, returns. Every sentence serves a purpose, but the args and returns sections add minimal value.

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

Completeness3/5

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

Given the existence of an output schema, the description is adequate but lacks details on what commonalities entail. Could be more informative for a one-parameter tool.

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

Parameters2/5

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

With 0% schema coverage, description should add meaning. It only states 'collection_id (required): Collection identifier,' which adds no more than the schema. Does not explain format or source.

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 retrieves common characteristics of IoCs in a collection, using specific verb 'retrieve' and specifying the resource. It distinguishes from siblings like get_collection_feature_matches.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. Does not mention when not to use or provide context for selection among similar tools.

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

get_collection_timeline_eventsA

Retrieves timeline events from the given collection, when available.

This is super valuable curated information produced by security analysits at Google Threat Intelligence.

We should fetch this information for campaigns and threat actors always.

It's common to display the events grouped by the "event_category" field.

Args: id (required): Collection identifier Return: List of events related to the given collection.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description bears full burden. It notes events are retrieved 'when available' and are 'super valuable curated information', indicating data quality and availability, but lacks details on error handling, permissions, or pagination.

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?

The description is front-loaded with the purpose, followed by valuable context and usage recommendation, then parameter and return definitions. Each sentence adds value, no redundancies.

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

Completeness3/5

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

While the tool is simple (one parameter, no output schema), the description omits details about the structure of returned events beyond mentioning 'event_category', and does not specify if the list can be empty or other fields. For an AI agent, this could leave ambiguity about the return format.

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

Parameters3/5

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

With 0% schema description coverage, the description must define the parameter. It states 'id (required): Collection identifier', which is basic but sufficient. No example or formatting hints are given.

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 the tool retrieves timeline events from a given collection, distinguishing it from siblings like 'get_collection_feature_matches' and 'get_threat_profile_associations_timeline' by focusing on collection-specific curated timeline data.

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 explicitly recommends fetching this information 'for campaigns and threat actors always', providing clear positive use-case guidance, though it does not discuss when not to use it or compare to alternatives explicitly.

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

get_domain_reportB

Get a comprehensive domain analysis report from Google Threat Intelligence.

Args: domain (required): Domain to analyse. Returns: Report with insights about the domain.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It does not disclose behavioral traits like read-only nature, rate limits, or prerequisites. 'Comprehensive report' is vague.

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?

The description is extremely concise, front-loaded with the action, and uses clear bullet points for arguments and returns. Every sentence adds value, no fluff.

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

Completeness3/5

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

Given an output schema exists (context signal), the description need not detail return structure. However, for a single-param tool, it could hint at the report's content. Adequate but not rich.

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

Parameters3/5

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

The only parameter 'domain' is described as 'Domain to analyse', which adds some meaning beyond the schema (which has no description). With 0% schema coverage, this is acceptable but minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'domain analysis report'. It is specific enough to distinguish from siblings like get_ip_address_report, though it does not explicitly differentiate.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs. alternatives. With many sibling report tools, explicit usage context (e.g., 'Use for domain analysis; for IPs use get_ip_address_report') is missing.

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

get_entities_related_to_a_collectionA

Retrieve entities related to the the given collection ID.

The following table shows a summary of available relationships for collection objects.

Relationship	Description	Return type
associations	List of associated threats	collection
attack_techniques	List of attack techniques	attack_technique
domains	List of Domains	domain
files	List of Files	file
ip_addresses	List of IP addresses	ip_address
urls	List of URLs	url
threat_actors	List of related threat actors	collection
malware_families	List of related malware families	collection
software_toolkits	List of related tools	collection
campaigns	List of related campaigns	collection
vulnerabilities	List of related vulnerabilities	collection
reports	List of reports	collection
suspected_threat_actors	List of related suspected threat actors	collection
hunting_rulesets	Google Threat Intelligence Yara rules that identify the given collection	hunting_ruleset

Note on descriptors_only: When True, returns basic descriptors. When False, returns detailed attributes. IMPORTANT: descriptors_only must be False for the 'attack_techniques' relationship.

Args: id (required): Collection identifier. relationship_name (required): Relationship name. limit (optional): Limit the number of collections to retrieve. 10 by default. descriptors_only (optional)): Bool. Default True. Must be False when the target object type is 'attack_techniques'. Returns: List of objects related to the collection.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`limit`	No
`descriptors_only`	No
`relationship_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description discloses important behavioral traits: it explains the effect of the 'descriptors_only' parameter and the special requirement for 'attack_techniques' relationship. However, it omits details on error handling, rate limits, or authentication, which is acceptable for a retrieval tool.

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?

The description is well-organized with a table and clear sections, but it is somewhat lengthy. Every sentence adds value, and it is front-loaded with the purpose. Slight improvement could be made by trimming redundant phrasing.

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?

Given the tool's complexity (multiple relationships, special constraints) and the presence of an output schema, the description covers all necessary aspects: required and optional parameters, behavior of each, and the constraint for attack_techniques. It is complete for an agent to use correctly.

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 schema has 0% description coverage, but the description fully compensates by explaining each parameter: 'id' as collection identifier, 'relationship_name' with a table of valid values, 'limit' with default, and 'descriptors_only' with its behavior and constraint for attack_techniques.

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 the tool retrieves entities related to a collection given an ID and relationship name. It includes a comprehensive table of available relationships, distinguishing it from sibling tools that are specific to other object types.

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 clear usage context: it explains the required parameters and the available relationships. However, it does not explicitly state when to use this tool over other similar 'get_entities_related_to_*' tools, though the name makes it obvious for collections.

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

get_entities_related_to_a_domainA

Retrieve entities related to the the given domain.

The following table shows a summary of available relationships for domain objects.

Relationship	Description	Return type
associations	Domain's associated objects (reports, campaigns, IoC collections, malware families, software toolkits, vulnerabilities, threat-actors), without filtering by the associated object type.	Everyone.
caa_records	Records CAA for the domain.	domain
campaigns	Campaigns associated to the domain.	collection
cname_records	Records CNAME for the domain.	domain
collections	IoC Collections associated to the domain.	collection
comments	Community posted comments about the domain.	comment
communicating_files	Files that communicate with the domain.	file
downloaded_files	Files downloaded from that domain.	file
graphs	Graphs including the domain.	graph
historical_ssl_certificates	SSL certificates associated with the domain.	ssl-cert
historical_whois	WHOIS information for the domain.	whois
immediate_parent	Domain's immediate parent.	domain
malware_families	Malware families associated to the domain.	collection
memory_pattern_parents	Files having a domain as string on memory during sandbox execution.	file
mx_records	Records MX for the domain.	domain
ns_records	Records NS for the domain.	domain
parent	Domain's top parent.	domain
referrer_files	Files containing the domain.	file
related_comments	Community posted comments in the domain's related objects.	comment
related_reports	Reports that are directly and indirectly related to the domain.	collection
related_threat_actors	Threat actors related to the domain.	collection
reports	Reports directly associated to the domain.	collection
resolutions	DNS resolutions for the domain.	resolution
siblings	Domain's sibling domains.	domain
soa_records	Records SOA for the domain.	domain
software_toolkits	Software and Toolkits associated to the domain.	collection
subdomains	Domain's subdomains.	domain
urls	URLs having this domain.	url
user_votes	Current user's votes.	vote
votes	Domain's votes.	vote
vulnerabilities	Vulnerabilities associated to the domain.	collection

Args: domain (required): Domain to analyse. relationship_name (required): Relationship name. descriptors_only (required): Bool. Must be True when the target object type is one of file, domain, url, ip_address or collection. limit: Limit the number of entities to retrieve. 10 by default. Returns: List of entities related to the domain.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`domain`	Yes
`descriptors_only`	Yes
`relationship_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It adds value by listing available relationships and return types, and notes the required descriptors_only constraint. However, it does not disclose potential side effects, pagination behavior, or rate limits.

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 long due to the necessary relationship table. It is front-loaded with the purpose, but the table is somewhat repetitive. While informative, it could be more concise without losing essential detail.

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?

Given an output schema exists, the description does not need to detail return values. It adequately covers parameter semantics, usage constraint, and relationship options. Lacks mention of pagination or maximum limit, but is generally complete for a complex tool.

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 0%, so the description must compensate. It explains domain and relationship_name through the extensive table, clarifies descriptors_only with a usage constraint, and notes limit defaults to 10. This adds significant meaning beyond the bare schema.

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 starts with a clear verb+resource statement 'Retrieve entities related to the given domain.' and distinguishes from siblings like get_entities_related_to_a_file by focusing on domain objects.

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 guidance on when descriptors_only must be True ('Must be True when the target object type is one of file, domain, url, ip_address or collection') and specifies a default limit. However, it does not explicitly contrast with alternative tools or state when to choose this over similar sibling tools.

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

get_entities_related_to_a_fileB

Retrieve entities related to the the given file hash.

The following table shows a summary of available relationships for file objects.

Relationship	Description	Return type
analyses	Analyses for the file	analysis
associations	File's associated objects (reports, campaigns, IoC collections, malware families, software toolkits, vulnerabilities, threat-actors), without filtering by the associated object type.	collection
behaviours	Behaviour reports for the file.	file-behaviour
attack_techniques	Returns the Attack Techniques of the File.	attack_technique
bundled_files	Files bundled within the file.	file
campaigns	Campaigns associated to the file.	collection
carbonblack_children	Files derived from the file according to Carbon Black.	file
carbonblack_parents	Files from where the file was derived according to Carbon Black.	file
collections	IoC Collections associated to the file.	collection
comments	Comments for the file.	comment
compressed_parents	Compressed files that contain the file.	file
contacted_domains	Domains contacted by the file.	domain
contacted_ips	IP addresses contacted by the file.	ip_address
contacted_urls	URLs contacted by the file.	url
dropped_files	Files dropped by the file during its execution.	file
email_attachments	Files attached to the email.	file
email_parents	Email files that contained the file.	file
embedded_domains	Domain names embedded in the file.	domain
embedded_ips	IP addresses embedded in the file.	ip_address
embedded_urls	URLs embedded in the file.	url
execution_parents	Files that executed the file.	file
graphs	Graphs that include the file.	graph
itw_domains	In the wild domain names from where the file has been downloaded.	domain
itw_ips	In the wild IP addresses from where the file has been downloaded.	ip_address
itw_urls	In the wild URLs from where the file has been downloaded.	url
malware_families	Malware families associated to the file.	collection
memory_pattern_domains	Domain string patterns found in memory during sandbox execution.	domain
memory_pattern_ips	IP address string patterns found in memory during sandbox execution.	ip_address
memory_pattern_urls	URL string patterns found in memory during sandbox execution.	url
overlay_children	Files contained by the file as an overlay.	file
overlay_parents	File that contain the file as an overlay.	file
pcap_children	Files contained within the PCAP file.	file
pcap_parents	PCAP files that contain the file.	file
pe_resource_children	Files contained by a PE file as a resource.	file
pe_resource_parents	PE files containing the file as a resource.	file
related_attack_techniques	Returns the Attack Techniques of the Collections containing this File.	attack_technique
related_reports	Reports that are directly and indirectly related to the file.	collection
related_threat_actors	File's related threat actors.	collection
reports	Reports directly associated to the file.	collection
screenshots	Screenshots related to the sandbox execution of the file.	screenshot
similar_files	Files that are similar to the file.	file
software_toolkits	Software and Toolkits associated to the file.	collection
submissions	Submissions for the file.	submission
urls_for_embedded_js	URLs where this (JS) file is embedded.	url
user_votes	File's votes made by current signed-in user.	vote
votes	Votes for the file.	vote
vulnerabilities	Vulnerabilities associated to the file.	collection

Args: hash (required): MD5/SHA1/SHA256) hash that identifies the file. relationship_name (required): Relationship name. descriptors_only (required): Bool. Must be True when the target object type is one of file, domain, url, ip_address or collection. limit: Limit the number of files to retrieve. 10 by default. Returns: List of objects related to the given file.

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes
`limit`	No
`descriptors_only`	Yes
`relationship_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It describes a read-like operation but does not disclose behavioral traits such as idempotency, rate limits, authentication needs, or potential side effects. The function appears safe but is not explicitly stated.

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?

The description is fairly concise given the need for a large table. The initial sentence is clear, and the arguments section is structured. The table is necessary and well-formatted, making it easy to scan.

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?

Covers all parameters, lists all relationship names, and explains the descriptors_only requirement. The return type is mentioned generically, but output schema exists so fine. Could mention pagination if limit is exceeded, but overall complete for the tool's complexity.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: hash types, relationship_name via exhaustive table, descriptors_only condition, and limit default. This provides rich meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves entities related to a file hash. The detailed table of relationship types makes the purpose exhaustive, but it does not explicitly differentiate from sibling tools like get_entities_related_to_a_domain, relying on the tool name for distinction.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The table implies it is used for any file relationship, but does not mention when not to use it or compare to sibling tools.

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

Retrieve entities related to the the given Hunting Ruleset.

The following table shows a summary of available relationships for Hunting ruleset objects.

Relationship	Return object type
hunting_notification_files	Files that matched with the ruleset filters

Args: ruleset_id (required): Hunting ruleset identifier. relationship_name (required): Relationship name. limit: Limit the number of entities to retrieve. 10 by default. Returns: List of objects related to the Hunting ruleset.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`ruleset_id`	Yes
`relationship_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It mentions the default limit and return type but lacks disclosure of read-only nature, error conditions, or authentication needs. The relationship table adds context.

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?

The description is well-structured with Args and Returns sections. The table is necessary and concise. It is not overly long but includes essential details.

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

Completeness3/5

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

Given there is an output schema, the description adequately covers parameters and return type. However, it is missing details like pagination, error handling, or limits on the number of entities retrieved.

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

Parameters3/5

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

With 0% schema coverage, the description adds meaning by explaining ruleset_id, relationship_name (via table), and limit with default. However, it does not elaborate on valid values for relationship_name beyond the table.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves entities related to a Hunting Ruleset and provides a table of relationships. However, it does not explicitly differentiate from sibling tools like get_entities_related_to_a_collection, though the target entity is distinct.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. There are no explicit when-to-use or when-not-to-use statements, nor mention of prerequisites.

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

get_entities_related_to_an_ip_addressA

Retrieve entities related to the the given IP Address.

The following table shows a summary of available relationships for IP Address objects.

Relationship	Description	Return type
associations	IP's associated objects (reports, campaigns, IoC collections, malware families, software toolkits, vulnerabilities, threat-actors), without filtering by the associated object type.	collection
campaigns	Campaigns associated to the IP address.	collection
collections	IoC Collections associated to the IP address.	collection
comments	Comments for the IP address.	comment
communicating_files	Files that communicate with the IP address.	file
downloaded_files	Files downloaded from the IP address.	file
graphs	Graphs including the IP address.	graph
historical_ssl_certificates	SSL certificates associated with the IP.	ssl-cert
historical_whois	WHOIS information for the IP address.	whois
malware_families	Malware families associated to the IP address.	collection
memory_pattern_parents	Files having an IP as string on memory during sandbox execution.	file
referrer_files	Files containing the IP address.	file
related_comments	Community posted comments in the IP's related objects.	comment
related_reports	Reports that are directly and indirectly related to the IP.	collection
related_threat_actors	Threat actors related to the IP address.	collection
reports	Reports directly associated to the IP.	collection
resolutions	IP address' resolutions	resolution
software_toolkits	Software and Toolkits associated to the IP address.	collection
urls	URLs related to the IP address.	url
user_votes	IP's votes made by current signed-in user.	vote
votes	IP's votes.	vote
vulnerabilities	Vulnerabilities associated to the IP address.	collection

Args: ip_address (required): IP Addres to analyse. relationship_name (required): Relationship name. descriptors_only (required): Bool. Must be True when the target object type is one of file, domain, url, ip_address or collection. limit: Limit the number of entities to retrieve. 10 by default. Returns: List of entities related to the IP Address.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`ip_address`	Yes
`descriptors_only`	Yes
`relationship_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description must fully disclose behavior. It mentions that descriptors_only must be True for certain object types, and describes the return type per relationship via the table. However, it does not cover pagination, error handling, or permission requirements.

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?

The description is front-loaded with a clear purpose sentence. The table adds length but is well-structured and necessary for parameter clarity. It is verbose but not wasteful.

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?

Given the output schema exists and the description covers all parameters with a detailed relationship table, it is complete for the tool's complexity. It provides sufficient context for an AI agent to understand the tool's capabilities.

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 0%, so the description adds crucial meaning. It explains ip_address, relationship_name (with a table of valid values), descriptors_only (boolean constraint), and limit (default 10). The table effectively enriches the relationship_name parameter beyond the schema.

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 retrieves entities related to an IP address, and the detailed table of relationships with descriptions and return types makes the purpose very specific. It distinguishes itself from sibling tools like get_entities_related_to_a_domain by focusing on IP addresses.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives (e.g., other get_entities_related_to_* tools). There are no explicit conditions, exclusions, or prerequisites mentioned.

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

get_entities_related_to_an_urlA

Retrieve entities related to the the given URL.

The following table shows a summary of available relationships for URL objects.

Relationship	Description	Return type
analyses	Analyses for the URL.	analyse
associations	URL's associated objects (reports, campaigns, IoC collections, malware families, software toolkits, vulnerabilities, threat-actors), without filtering by the associated object type.	collection
campaigns	Campaigns associated to the URL.	collection
collections	IoC Collections associated to the URL.	collection
comments	Community posted comments about the URL.	comment
communicating_files	Files that communicate with a given URL when they're executed.	file
contacted_domains	Domains from which the URL loads some kind of resource.	domain
contacted_ips	IPs from which the URL loads some kind of resource.	ip_address
downloaded_files	Files downloaded from the URL.	file
embedded_js_files	JS files embedded in a URL.	file
graphs	Graphs including the URL.	graph
http_response_contents	HTTP response contents from the URL.	file
last_serving_ip_address	Last IP address that served the URL.	ip_address
malware_families	Malware families associated to the URL.	collection
memory_pattern_parents	Files having a domain as string on memory during sandbox execution.	file
network_location	Domain or IP for the URL.	domain or ip_address
parent_resource_urls	Returns the URLs where this URL has been loaded as resource.	url
redirecting_urls	URLs that redirected to the given URL.	url
redirects_to	URLs that this url redirects to.	url
referrer_files	Files containing the URL.	file
referrer_urls	URLs referring the URL.	url
related_collections	Returns the Collections of the parent Domains or IPs of this URL.	collection
related_comments	Community posted comments in the URL's related objects.	comment
related_reports	Reports that are directly and indirectly related to the URL.	collection
related_threat_actors	URL's related threat actors.	collection
reports	Reports directly associated to the URL.	collection
software_toolkits	Software and Toolkits associated to the URL.	collection
submissions	URL's submissions.	url
urls_related_by_tracker_id	URLs that share the same tracker ID.	url
user_votes	URL's votes made by current signed-in user.	vote
votes	Votes for the URL.	vote
vulnerabilities	Vulnerabilities associated to the URL.	collection

Args: url (required): URL to analyse. relationship_name (required): Relationship name. descriptors_only (required): Bool. Must be True when the target object type is one of file, domain, url, ip_address or collection. limit: Limit the number of objects to retrieve. 10 by default. Returns: List of entities related to the URL.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`limit`	No
`descriptors_only`	Yes
`relationship_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It discloses the input parameters and the return type (list of entities). It does not mention error handling, rate limits, or explicit read-only nature, but the tool name and description imply a safe read operation. Overall, it is fairly transparent.

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?

The description is well-structured with a clear first sentence stating purpose, followed by a helpful table, then parameter explanations. The table is somewhat long but provides necessary details. It is appropriately sized given the complexity of relationships.

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?

Considering the presence of an output schema (not shown), the description covers all needed aspects: purpose, all parameters, a comprehensive list of relationship types, and return type. It is complete for an AI agent to select and invoke the tool correctly.

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?

Despite 0% schema description coverage, the description thoroughly explains each parameter: 'url' as the URL to analyse, 'relationship_name' via a detailed table, 'descriptors_only' with a rule for when it must be True, and 'limit' with default. This adds significant value beyond the schema.

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 explicitly states the purpose: 'Retrieve entities related to the the given URL.' It also lists specific relationship types via a table, distinguishing it from sibling tools that target other entity types (e.g., domains, files).

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 tool name and description make it clear that it is for URLs. The table of relationships guides which relationship_name to use. However, it does not explicitly state when not to use this tool or mention alternatives like get_entities_related_to_a_domain, relying on the name for differentiation.

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

get_file_behavior_reportA

Retrieve the file behaviour report of the given file behaviour identifier.

You can get all the file behaviour of a given a file by calling get_entities_related_to_a_file as the file hash and the behaviours as relationship name.

The file behaviour ID is composed using the following pattern: "{file hash}_{sandbox name}".

Args: file_behaviour_id (required): File behaviour ID. Returns: The file behaviour report.

ParametersJSON Schema

Name	Required	Description	Default
`file_behaviour_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description must cover behavioral traits. It does not mention read-only nature, side effects, or potential failures. However, it does describe the parameter behavior (ID pattern), which is helpful.

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?

Multiple sentences but no fluff. Structure is clear: main sentence, explanatory paragraph, then Args/Returns. Could be slightly tighter but effective.

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?

Output schema exists, so return details are not needed. It explains the parameter well and gives contextual info about obtaining the ID. Missing error conditions or performance notes, but adequate for a retrieval tool.

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?

Schema has 0% description coverage but the description adds the ID pattern (file hash + sandbox name) and how to derive it, adding significant meaning beyond the schema.

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 retrieves a report for a file behaviour ID. It distinguishes from siblings like get_file_report and get_entities_related_to_a_file by specifying the unique input and how to obtain it.

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?

It explains how to get the file behaviour identifier via get_entities_related_to_a_file and the ID pattern, providing strong context for when to use this tool. Does not explicitly state when not to use it, but the guidance is clear.

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

get_file_behavior_summaryB

Retrieve a summary of all the file behavior reports from all the sandboxes.

Args: hash (required): MD5/SHA1/SHA256) hash that identifies the file. Returns: The file behavior summary.

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden for behavioral transparency. It states the required hash parameter and that it returns a summary, but does not disclose any potential issues such as size limits, caching behavior, or whether the hash must be from a known file.

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?

The description is concise, with a clear single-sentence purpose followed by parameter details. The return statement is minimal but acceptable. It is front-loaded with the main purpose.

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

Completeness3/5

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

The tool has a single parameter and a simple purpose. The description covers the input adequately and states the return type. However, it lacks guidance on when to use this vs the similar sibling get_file_behavior_report, and it does not describe any error conditions or special cases.

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

Parameters3/5

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

The description explains the hash parameter, specifying that it is required and listing the accepted types (MD5, SHA1, SHA256). Since the schema property has no description, this adds valuable context. However, it does not specify exact length or format constraints.

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 uses a specific verb ('Retrieve') and identifies the resource ('summary of file behavior reports'). It implicitly distinguishes from sibling tools like get_file_behavior_report (which likely gets a detailed report) and get_file_report. The mention of 'from all the sandboxes' adds specificity.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives such as get_file_behavior_report or get_file_report. The description assumes the agent knows the distinction from tool names alone, which may not be sufficient.

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

get_file_reportA

Get a comprehensive file analysis report using its hash (MD5/SHA-1/SHA-256).

Returns a concise summary of key threat details including detection stats, threat classification, and important indicators. Parameters: hash (required): The MD5, SHA-1, or SHA-256 hash of the file to analyze. Example: '8ab2cf...', 'e4d909c290d0...', etc.

ParametersJSON Schema

Name	Required	Description	Default
`hash`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses it returns a report with detection stats, etc., but does not explicitly state it is read-only or mention any side effects. The name 'get' implies idempotence, but additional context could be helpful.

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?

Two sentences plus parameter description and example. Front-loaded with the core action. Every sentence adds value with no waste.

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?

Describes input, output summary, and return content. Output schema exists, so no need to detail return structure. Could mention if the file must be previously submitted, but overall sufficient for a single-parameter tool.

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 has 0% description coverage, but description provides detailed parameter info: accepted hash types (MD5, SHA-1, SHA-256) and example formats. This adds significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it gets a comprehensive file analysis report using a hash, and lists the types of hashes accepted. Differentiates from sibling tools like get_domain_report, but does not explicitly distinguish from get_file_behavior_report.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives such as analyse_file or get_file_behavior_report. The description implies it's for a comprehensive report, but lacks explicit when-to-use or when-not-to-use instructions.

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

get_hunting_rulesetA

Get a Hunting Ruleset object from Google Threat Intelligence.

A Hunting Ruleset object describes a user's hunting ruleset. It may contain multiple Yara rules.

The content of the Yara rules is in the rules attribute.

Some important object attributes:

creation_date: creation date as UTC timestamp.
modification_date (int): last modification date as UTC timestamp.
name (str): ruleset name.
rule_names (list[str]): contains the names of all rules in the ruleset.
number_of_rules (int): number of rules in the ruleset.
rules (str): rule file contents.
tags (list[str]): ruleset's custom tags.

Args: ruleset_id (required): Hunting ruleset identifier.

Returns: Hunting Ruleset object.

ParametersJSON Schema

Name	Required	Description	Default
`ruleset_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It explains the tool is a read operation (get), lists important attributes of the returned object, and mentions the rules content. It does not cover error scenarios or permissions, but for a simple retrieve, it is sufficiently transparent.

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?

The description is front-loaded with the purpose and includes a clear list of object attributes. Though slightly verbose, each sentence adds value and the structure is logical.

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?

An output schema exists, but the description still explains return values and the parameter. It is complete for a simple retrieve tool, though it could mention error handling or permission requirements.

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 description coverage is 0%, yet the description adds meaning by describing the required parameter as 'Hunting ruleset identifier' and details the output object's attributes, compensating for the lack of schema descriptions.

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 'Get a Hunting Ruleset object from Google Threat Intelligence', which is a specific verb+resource. It distinguishes from sibling tools like get_entities_related_to_a_hunting_ruleset by focusing on the ruleset object itself.

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

Usage Guidelines3/5

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

The description implies usage for retrieving a specific ruleset by ID, but does not explicitly state when to use this tool versus alternatives like search tools or get_entities_related_to_a_hunting_ruleset. No exclusions or prerequisites are mentioned.

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

get_ip_address_reportA

Get a comprehensive IP Address analysis report from Google Threat Intelligence.

Args: ip_address (required): IP Address to analyze. It can be IPv4 or IPv6. Returns: Report with insights about the IP address.

ParametersJSON Schema

Name	Required	Description	Default
`ip_address`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions returning a report with insights but lacks details on data freshness, caching, rate limits, or authentication requirements. This under-specifies the tool's behavior.

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?

The description is concise with a clear structure: a one-sentence summary followed by an Args and Returns section. Every sentence serves a purpose, and the main action is front-loaded.

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?

Given the tool's simplicity (one parameter, output schema present), the description covers the essentials. However, it could be improved by mentioning whether the report is live or cached, and any limitations or caveats about the analysis.

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?

The input schema has 0% coverage, but the description adds meaningful detail: the parameter is required and accepts IPv4 or IPv6. This goes beyond the schema's bare type definition. Adding an example format would elevate the score further.

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 the verb 'Get', the resource 'IP Address analysis report', and the source 'Google Threat Intelligence'. It effectively distinguishes this tool from siblings like 'get_domain_report' and 'get_url_report' by specifying the IP address focus.

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

Usage Guidelines3/5

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

The description indicates the tool is used to get a report for an IP address, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. Usage is implied through context.

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

get_threat_profileA

Get Threat Profile object.

A threat profile object contains the following attributes:

enable_recommendations (bool): whether or not Recommendations automatically generated by our ML are enabled.
interests (dict): Threat Profile's configured interests such as industries, target regions, source regions, malware roles and actor motivations to recommend the most relevant threats.
- INTEREST_TYPE_TARGETED_INDUSTRY (list[str]): List of targeted industries.
- INTEREST_TYPE_TARGETED_REGION (list[str]): list of targeted regions (ISO-3166 country code).
- INTEREST_TYPE_SOURCE_REGION (list[str]): list of source regions (ISO-3166 country code).
- INTEREST_TYPE_MALWARE_ROLE (list[str]): list of malware roles.
- INTEREST_TYPE_ACTOR_MOTIVATION: (list[str]): list of threat actors motivations.
last_modification_date: Threat Profile's last modification date (UTC timestamp).
name (str): Threat Profile's name.
creation_date (int): Threat Profile's creation date (UTC timestamp).
aliases (list[str]): alternative names by which the threat actor is known.
description (str): description / context about the threat actor.
first_seen_date (int): estimated threat actor's first seen date of activity (UTC timestamp).
last_seen_date (int): estimated threat actor's last seen date of activity (UTC timestamp).
last_modification_date (int): last time when the threat actor was updated (UTC timestamp).
related_entities_count (int): estimated number of related IOCs to the threat actor.
source_region (str): threat actor's source region.
sponsor_region (str): region sponsoring the threat actor.
targeted_industries (list[str]): list of industries the threat actor has targeted.
targeted_regions (list[str]): list of regions the threat actor has targeted.

Args: profile_id (str): Threat Profile identifier at Google Threat Intelligence.

Returns: Threat Profile object.

ParametersJSON Schema

Name	Required	Description	Default
`profile_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

Annotations are absent, so the description carries the full burden. It does not disclose whether the operation is read-only, any authentication needs, rate limits, or side effects. While 'Get' implies idempotency, the description lacks explicit behavioral context beyond listing attributes.

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 structured with sections (Args, Returns) and bullet points, but it is lengthy and includes many attribute details that could be moved to the output schema. It front-loads the purpose, but the attribute list adds verbosity without earning its place given the existence of an output schema.

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 simple get operation with one parameter, the description covers the return object comprehensively. However, it omits error conditions, access requirements, or pagination. Given that an output schema exists, the description adds value by explaining the attributes, making it fairly complete.

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?

With 0% schema description coverage, the description fully compensates by providing a clear explanation of 'profile_id': 'Threat Profile identifier at Google Threat Intelligence'. This adds meaningful context beyond the schema's bare title.

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 'Get Threat Profile object' and lists its attributes. It specifies the required parameter (profile_id), differentiating it from siblings like 'list_threat_profiles' which lists all profiles. The purpose is specific and unambiguous.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives such as 'list_threat_profiles', 'get_threat_profile_associations_timeline', or 'get_threat_profile_recommendations'. The context does not indicate any prerequisites or exclusions.

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

get_threat_profile_associations_timelineC

Retrieves the associations timeline for the given Threat Profile.

Some important response attributes:

event_type (str): the type of the timeline association such as Alias, Motivation, Malware, Actor, Toolkit, Report, Campaign, etc.
event_entity (str): The name or value of the timeline association.
first_seen (int): Unix epoch UTC time (seconds) when the association between the object and the threat profile was made.
last_seen (int): Unix epoch UTC time (seconds) of most recent observed relationship between the object and the threat profile.
name (str): name of the object directly associated with the threat profile.
link (str): URL of the object directly associated with the threat profile

Returns: List of dictionaries containing timeline associations.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`profile_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description must fully convey behavioral traits. It lists output attributes, implying a read operation, but does not explicitly state whether the operation is read-only, destructive, or requires specific permissions. No side effects or limitations are mentioned.

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 reasonably concise with a clear first sentence and a structured list of response attributes. However, the list could be streamlined if an output schema were present, and some sentences are redundant (e.g., 'Returns: List of dictionaries').

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

Completeness2/5

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

Despite having an output schema (inferred), the description lacks context about the timeline concept, data ordering, pagination, or how profile_id relates to the response. For a tool with no annotations and low schema coverage, more completeness is needed to ensure correct usage.

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

Parameters2/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 should clarify parameter semantics. It only mentions 'for the given Threat Profile' without explaining the profile_id parameter's format or source. The limit parameter is self-explanatory but no additional context is given for how it affects results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Retrieves the associations timeline for the given Threat Profile,' which identifies the verb and resource. While it is specific about the output attributes, it does not explicitly differentiate from sibling tools like get_threat_profile or list_threat_profiles, though the name suggests a distinct purpose.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as get_threat_profile_recommendations or search_threat_actors. There is no discussion of prerequisites, typical use cases, or scenarios where this tool is appropriate or not.

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

get_threat_profile_recommendationsA

Returns the list of objects associated to a given Threat Profile.

Each of these objects has one of the following types:

Threat Actors
Malware Families
Software or Toolkits
Campaigns
IoC Collections
Reports
Vulnerabilities

We can distinguish between two other types of objects based on how they were associated with the Threat Profile:

Recommended objects are automatically recommended or assigned to a Threat Profile based on our proprietary ML that takes into account the Threat Profile's configured interests such as the targeted industries, target regions, source regions, malware roles and actor motivations to recommend the most relevant threats. These objects are identified by the presence of "source": "SOURCE_RECOMMENDATION" within the "context_attributes" response parameter below.
Added objects are assigned or added by users to a Threat Profile, when users find other relevant threats not automatically recommended by our ML module. These objects are identified by the presence of "source": "SOURCE_DIRECT_FOLLOW" within the "context_attributes" response parameter below.
Args: profile_id (str): Threat Profile identifier at Google Threat Intelligence. limit: Limit the number of objects to retrieve. 10 by default.
Returns: List of Threat (collection) objects identifiers associated to the Threat Profile. Use get_collection_report to retrieve the full objects.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`profile_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It explains the difference between recommended and added objects via source attribute, default limit, and that it returns identifiers. However, it does not disclose error handling, authentication needs, or rate limits.

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?

The description is well-structured with bullet points and front-loads the main purpose. It is detailed but not overly verbose; every sentence adds value, though the object type list could be more concise.

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

Completeness3/5

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

Given complexity and presence of output schema, the description covers object types and source differentiation. However, it omits pagination, sorting, error cases, and examples, leaving gaps for an agent to fully understand the tool's behavior.

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?

Despite 0% schema coverage, the description explains profile_id as 'Threat Profile identifier at Google Threat Intelligence' and limit with default value, adding meaning beyond the schema structure.

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 the tool returns a list of objects associated to a given Threat Profile, listing specific object types and distinguishing between recommended and added objects. This differentiates it from sibling tools like get_collection_report or search_threats.

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

Usage Guidelines3/5

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

The description implies usage for retrieving associated objects for a threat profile, but lacks explicit guidance on when to use this tool versus alternatives like get_collection_feature_matches or get_threat_profile. It only hints at using get_collection_report for full objects.

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

get_url_reportB

Get a comprehensive URL analysis report from Google Threat Intelligence.

Args: url (required): URL to analyse. Returns: Report with insights about the URL.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It only mentions 'Report with insights about the URL' without detailing what kind of insights, whether the operation is read-only, or any limitations. This is minimal disclosure.

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?

The description is short and front-loaded with a clear purpose. The Args/Returns structure is neat, though the Args section largely repeats the schema. No unnecessary words.

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

Completeness3/5

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

Given there is an output schema, the return description is sufficient. However, for a tool with no annotations, the description could be more complete by explaining the scope of the report or usage notes. It is adequate but not thorough.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It states 'url (required): URL to analyse,' which adds a basic description but lacks format, examples, or constraints. The value added is minimal.

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 'Get a comprehensive URL analysis report from Google Threat Intelligence.', which specifies both the action (get) and the resource (URL analysis report). It distinguishes from sibling tools that focus on domains, files, or IP addresses.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify whether this tool is preferred over 'get_domain_report' for URLs that are also associated with domains, or any prerequisites.

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

list_threat_profilesA

List your Threat Profiles at Google Threat Intelligence.

Threat Profiles filter all of Google TI's threat intelligence so you can focus only on the threats that matter most to your organization.

Threat Profiles let you apply top-level filters for Target Industries and Target Regions to immediately provide a more focused view of relevant threats.

When searching for threats, we must use this tool first to check if there is any Threat Profile that matches the user query before peforming a general search using the search_threats tool.

Recommendations from Threat Profiles are more relevants to users than generic search threats. Use them as long as they match user's query.

Returns: List of Threat Profiles.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It describes the tool as listing threat profiles and mentions return type, but lacks details on pagination, ordering, or what happens when no profiles exist. The existence of an output schema partially mitigates the lack of behavioral details.

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 somewhat verbose with two paragraphs explaining what Threat Profiles are. While front-loaded with the main purpose, it could be more concise by removing explanatory text that is not directly about tool usage.

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 simple list tool with one optional parameter and an output schema, the description provides sufficient context: explains what Threat Profiles are, when to use them, and their importance. It doesn't detail return field structure, but the output schema compensates.

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

Parameters1/5

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

The input schema has one parameter 'limit' with no description (0% coverage). The description does not mention this parameter at all, failing to add meaning beyond the schema. Since schema coverage is low, the description should compensate, but it does not.

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 the verb 'List' and the resource 'Threat Profiles', explaining their purpose as filters for threat intelligence. It distinguishes itself from the sibling tool 'search_threats' by specifying that this tool should be used first.

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?

Explicitly provides when-to-use guidance: 'When searching for threats, we must use this tool first... before performing a general search using the search_threats tool.' Also explains that recommendations from Threat Profiles are more relevant, giving clear priority rules.

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

search_campaignsA

Search threat campaigns in the Google Threat Intelligence platform.

Campaigns are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

Args: query (required): Search query to find threats. limit: Limit the number of threats to retrieve. 10 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits beyond the search and ordering syntax (e.g., no mention of read-only nature, rate limits, authentication, or side effects). The description is adequate but lacks explicit safety or mutability details.

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?

The description is well-structured with a clear purpose, follow-up context, parameter details, and return type. It is slightly verbose in the ordering explanation but earns its place. The front-loading is good.

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?

Given the presence of an output schema, the description's return type ('List of collections, aka threats') is sufficient. It covers the tool's operation, parameters, and relationship to other tools thoroughly. No major gaps are apparent.

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?

With 0% schema description coverage, the description adds significant meaning. It explains the 'query' parameter as required, 'limit' with default 10, and 'order_by' with valid values ('relevance', 'creation_date') and syntax (+/- for ascending/descending). This goes well beyond the schema's type and default information.

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 the tool's purpose: 'Search threat campaigns in the Google Threat Intelligence platform.' It also explains that campaigns are modeled as collections and directs users to subsequent tools like get_collection_report. This differentiates it from sibling tools like search_threats or search_threat_actors.

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 clear usage context: it tells users to use this tool to search for threat campaigns (collections) and then mentions get_collection_report as a follow-up. It also explains ordering options. However, it does not explicitly state when not to use this tool or specify alternatives among the many sibling search tools.

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

search_digital_threat_monitoringA

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.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`size`	No
`query`	Yes
`since`	No
`until`	No
`sanitize`	No
`truncate`	No

TDQS

A4.3/5.0

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.

search_iocsA

Search Indicators of Compromise (IOC) in the Google Threat Intelligence platform.

You can search by for different IOC types using the entity modifier. Below, the different IOC types and the supported orders:

Entity type	Supported orders	Default order
file	first_submission_date, last_submission_date, positives, times_submitted, size	last_submission_date-
url	first_submission_date, last_submission_date, positives, times_submitted, status	last_submission_date-
domain	creation_date, last_modification_date, last_update_date, positives	last_modification_date-
ip	ip, last_modification_date, positives	last_modification_date-

Note: The entity modifier can only be used ONCE per query.

You can find all available modifers at:

With integer modifers, use the - and + characters to indicate:

Greater than: p:60+
Less than: p:60-
Equal to: p:60

Args query (required): Search query to find IOCs. limit: Limit the number of IoCs to retrieve. 10 by default. order_by: Order the results. "last_submission_date-" by default.

Returns: List of Indicators of Compromise (IoCs).

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	last_submission_date-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It discloses the query syntax, default behavior (limit 10, order_by default), and constraints (entity modifier once). It does not mention rate limits or authentication, but those are likely global. The description is transparent about the search behavior.

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?

The description is well-structured with a clear introduction, table, notes, and parameter explanations. While lengthy, the table and links are valuable. It is front-loaded with purpose. A slightly shorter version could exist, but it earns its length.

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?

Given the schema richness (3 params, no enums) and presence of an output schema, the description is complete. It covers query syntax, modifiers, entity-specific ordering, constraints, and defaults. No gaps are apparent for using the tool effectively.

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 defines each parameter meaningfully: 'query' as search query, 'limit' with default 10, 'order_by' with default and a full table of supported values per entity type. This adds essential semantic meaning beyond the bare schema.

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 the tool's purpose: 'Search Indicators of Compromise (IOC) in the Google Threat Intelligence platform.' It specifies the resource (IOCs) and differentiates from sibling tools like search_threats by focusing on IOC-specific search modifiers and entity types.

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 detailed guidance on syntax, entity types, supported orders, and modifier constraints, including explicit notes about the `entity` modifier being used once. However, it lacks explicit when-to-use or when-not-to-use versus sibling search tools, which would elevate clarity.

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

search_malware_familiesA

Search malware families in the Google Threat Intelligence platform.

Malware families are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

Args: query (required): Search query to find threats. limit: Limit the number of threats to retrieve. 10 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations, the description carries the transparency burden. It explains that malware families are collections and returns a list of collections. It also covers default behavior for parameters. However, it lacks details on potential side effects, rate limits, or authentication requirements, leading to a moderate score.

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?

The description is concise and well-structured. It starts with a clear purpose, then provides context about collections, followed by parameter details, and ends with return type. Every sentence adds value without redundancy.

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?

Given the presence of an output schema and numerous siblings, the description is complete. It specifies the return type as a list of collections and links to a related tool for further actions, covering the essential context for an agent to use the tool effectively.

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?

Schema description coverage is 0%, so the description adds significant value. It explains each parameter: query (search query), limit (limit number, default 10), and order_by (sorting with +/- prefix, default 'relevance-'). This is far beyond the bare schema, which only provides types and defaults.

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 the tool's purpose: 'Search malware families in the Google Threat Intelligence platform.' It further explains that malware families are collections and directs users to a related tool for full reports, effectively distinguishing it from siblings like search_threats.

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 clear usage context, explaining that results are collections and suggesting a follow-up tool (get_collection_report). It also details sorting options and defaults. However, it does not explicitly state when not to use this tool versus alternatives like search_threats or search_campaigns, which would improve guidance.

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

search_software_toolkitsA

Search software toolkits (or just tools) in the Google Threat Intelligence platform.

Software toolkits are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

Args: query (required): Search query to find threats. limit: Limit the number of threats to retrieve. 10 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description fully explains behavior: it searches and returns collections, with details on ordering and defaults. It does not mention rate limits or errors, but for a search tool this is reasonable.

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?

The description is concise (around 100 words) and well-structured with sections for purpose, modeling, ordering explanation, and Args/Returns. Every sentence is informative.

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 simple search tool with 3 parameters, the description covers what it does, how to use parameters, and the return type. It lacks mention of pagination, but this is acceptable given the tool's simplicity and the presence of an output schema.

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 description adds significant value beyond the schema (0% coverage). It explains the query parameter required, limit default, order_by options with values and sorting syntax, vastly improving usability.

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 software toolkits (collections) in Google Threat Intelligence. It distinguishes from siblings by specifying the resource type and linking to get_collection_report for further details.

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 clear guidance on when to use (for searching software toolkits) and what to do next (use get_collection_report). It does not explicitly exclude alternative tools, but the context implies differentiation from other search tools listed as siblings.

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

search_threat_actorsA

Search threat actors in the Google Threat Intelligence platform.

Threat actors are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

Args: query (required): Search query to find threats. limit: Limit the number of threats to retrieve. 10 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations exist, so the description carries the transparency burden. It explains ordering behavior and defaults but does not cover pagination, rate limits, or return format details. Adequate for a search tool but could be more explicit.

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?

The description is moderately concise with clear sections: main purpose, argument details, and return type. No unnecessary sentences, though it could be slightly tighter by removing the redundant default mention in both prose and args.

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?

With an output schema present, the return description is sufficient. The description covers the search functionality, ordering, limit, and post-usage steps. Missing pagination details or behavior when results exceed limit, but overall adequate for the complexity.

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?

Schema description coverage is 0%, so the description compensates thoroughly. It explains the query parameter, limit default, and order_by values ('relevance', 'creation_date') along with usage of '+' and '-' for sorting direction, which the schema omits.

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 threat actors in the Google Threat Intelligence platform, explains that threat actors are modeled as collections, and distinguishes from siblings by noting that results can be processed further with get_collection_report. The verb 'search' is specific, and the resource is well-defined.

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 explicitly says to use get_collection_report after obtaining collections, providing sequential guidance. However, it does not compare with sibling search tools like search_threats or search_malware_families, so some ambiguity remains on when to use this specific tool.

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

search_threat_reportsA

Search threat reports in the Google Threat Intelligence platform.

Google Threat Intelligence provides continuously updated reports and analysis of threat actors, campaigns, vulnerabilities, malware, and tools

Threat reports are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

Args: query (required): Search query to find threats. limit: Limit the number of threats to retrieve. 10 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the tool as a search returning collections and explains ordering, but it does not mention pagination, error handling, or rate limits. The read-only nature is implied but not explicit.

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 well-structured with clear sections but includes some redundancy, such as repeating the default ordering. It is moderately concise but could be tightened to reduce verbosity without losing clarity.

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?

Given the tool has 3 parameters and an output schema (though not described), the description adequately explains the return value and the relationship to other tools. It covers the essential aspects for a search tool, though it could mention output structure.

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 0% schema description coverage, the description adds significant value by explaining each parameter: query is a search query, limit has a default of 10, and order_by includes format and defaults. However, the query parameter could benefit from more detail on syntax or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches threat reports, specifying the platform and that reports are modeled as collections. However, it does not explicitly differentiate from sibling tools like 'search_threats', which might cause confusion about when to use each.

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

Usage Guidelines3/5

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

The description mentions using 'get_collection_report' to fetch full reports, implying a workflow. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'search_threats' or 'search_iocs', nor does it specify any prerequisites or prohibitions.

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

search_threatsA

Search threats in the Google Threat Intelligence platform.

Threats are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

IMPORTANT CONTEXT CLUE: Pay close attention to the user's request. If their request mentions specific kinds of threats such as "threat actor", "malware family", "campaign", "report", or "vulnerability", treat this as a strong signal that you must use the collection_type filter in your query to ensure relevant results. Using this filter significantly improves search precision.

Filtering by Type: To filter your search results to a specific type of threat, include the collection_type modifier within your query string. Syntax: collection_type:"<type>" Available <type> values:

"threat-actor": Use when the user asks about specific actors, groups, or APTs.
"malware-family": Use when the user asks about malware, trojans, viruses, ransomware families.
"software-toolkit": Use when the user asks about legit tools usually related to malware.
"campaign": Use when the user asks about specific attack campaigns.
"report": Use when the user is looking for analysis reports.
"vulnerability": Use when the user asks about specific CVEs or vulnerabilities.
"collection": A generic type, use only if no other type fits or if the user explicitly asks for generic "collections".

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

When asked for latest threats, prioritize campaigns or vulnerabilities over reports.

Args: query (required): Search query to find threats. collection_type: Filter your search results to a specific type of threat limit: Limit the number of threats to retrieve. 5 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats. They are full collection objects, you do not need to retrieve themusing the get_collection_reporttool. You may need to extend with relationships usingget_entities_related_to_a_collection` tool.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-
`collection_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations provided, the description adequately discloses behavior: it returns a list of collection objects, and mentions the need for further tools to extend relationships. It explains ordering syntax and default limits. However, it does not cover error conditions, rate limits, or pagination behavior, but for a read-only search tool, transparency is sufficient.

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?

The description is structured with sections like 'IMPORTANT CONTEXT CLUE' and 'Filtering by Type', making it readable. It front-loads the main purpose. Some redundancy exists (e.g., repeating filter info in the Args section), but the length is justified by the detailed guidance it provides. Slight verbosity prevents a 5.

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

Completeness3/5

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

Given the four parameters and presence of an output schema, the description covers most essential aspects: return type, relationship to other tools, parameter syntax. However, it lacks guidance on error handling, result pagination, and critically, when to use this tool vs. the many specialized search siblings. This incomplete contextual mapping leaves the agent underinformed.

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?

The input schema has 0% description coverage, so the description must clarify parameters. It does so effectively: explains 'collection_type' with syntax and available values, 'order_by' with ordering keys and signs, 'query' as required search, and 'limit' as count with default. However, it does not specify query format or maximum limits, but overall compensates well for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches threats modeled as collections. It distinguishes from 'get_collection_report' by noting that tool fetches full reports. However, it does not differentiate from specialized sibling tools like 'search_threat_actors' or 'search_malware_families', which could cause confusion about which tool to use for specific threat types.

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

Usage Guidelines3/5

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

The description gives explicit guidance on when to use the 'collection_type' filter based on user request, and offers ordering preferences for latest threats. However, it fails to provide guidance on when to use this broad search tool versus the specialized search tools (e.g., 'search_campaigns', 'search_vulnerabilities'), leaving a gap in decision-making for the agent.

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

search_vulnerabilitiesA

Search vulnerabilities (CVEs) in the Google Threat Intelligence platform.

Vulnerabilities are modeled as collections. Once you get collections from this tool, you can use get_collection_report to fetch the full reports and their relationships.

You can use order_by to sort the results by: "relevance", "creation_date". You can use the sign "+" to make it order ascending, or "-" to make it descending. By default is "relevance-"

Args: query (required): Search query to find threats. limit: Limit the number of threats to retrieve. 10 by default. order_by: Order results by the given order key. "relevance-" by default.

Returns: List of collections, aka threats.

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`order_by`	No	relevance-

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description must carry the burden. It explains that the tool returns a list of collections (threats) and details ordering behavior. However, it omits information on side effects, authentication requirements, rate limits, or that it is a read-only operation. This is adequate but not comprehensive.

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?

The description is well-structured with an Args section. It is concise with no redundant sentences, delivering necessary information efficiently. Every sentence adds value.

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?

Given the presence of an output schema, the description does not need to explain return values. It covers the usage flow with get_collection_report. However, it could be more complete by mentioning pagination or result limits beyond the default.

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?

Input schema has 0% description coverage, so description must compensate. It explains query is required, limit default is 10, and order_by defaults to 'relevance-' with accepted values (relevance, creation_date) and sign usage (+/-). This adds significant meaning beyond the schema, though the query format itself is not detailed.

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?

Clearly states it searches vulnerabilities (CVEs) in the Google Threat Intelligence platform. Distinguishes from siblings by specifying it returns collections that can be used with get_collection_report, differentiating from search_threats and other search tools.

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

Usage Guidelines3/5

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

Provides guidance on using get_collection_report after obtaining collections, but does not explicitly state when to use this tool versus alternatives like search_iocs or search_threats. More explicit when-not-to-use guidance would improve clarity.

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

update_collection_attributesA

Allows updating a collection's attributes (such as name or description) Args: id (required): The ID of the collection to update. attributes: Available attributes in a collection: * name: string * description: string * private: boolean * tags: array of strings * alt_names: array of strings Returns: A dictionary representing the updated collection.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`attributes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states 'updates a collection's attributes' but does not explain whether updates are partial or full, whether existing attributes are overwritten or merged, authentication requirements, rate limits, or side effects. The schema allows additionalProperties:true but description lists specific attributes, creating ambiguity.

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?

The description is concise (around 80 words) and uses a clear structure with Args and Returns sections. Minor redundancy (e.g., 'A dictionary' appears twice) does not detract significantly. Every sentence adds value.

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

Completeness3/5

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

Given the tool has 2 parameters, 1 required, no enums, and an output schema (though content unknown), the description covers the basic input and output. However, it lacks details on error handling, idempotency, and whether the attributes parameter supports partial updates, which would enhance completeness for a mutation tool.

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 description coverage is 0%, so the description must compensate. It explains that 'id' is required and lists the available attributes with their types (name: string, description: string, private: boolean, tags: array of strings, alt_names: array of strings), adding significant meaning beyond the schema which only has generic 'object' type.

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 uses a specific verb 'updating' and identifies the resource 'collection's attributes', listing the attributes that can be updated (name, description, private, tags, alt_names), which clearly distinguishes it from sibling tools like create_collection (creation) or update_iocs_in_collection (IOC updates).

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

Usage Guidelines3/5

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

The description states what the tool does but does not explicitly provide guidance on when to use it versus alternatives, nor does it mention prerequisites or when not to use it. The purpose is clear from context, but explicit usage guidelines are missing.

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

update_iocs_in_collectionB

Updates (add or remove) Indicators of Compromise (IOCs) to a collection. Args: id (required): The ID of the collection to update. relationship (required): The type of relationship to add. Can be "domains", "files", "ip_addresses", or "urls". iocs (required): List of IOCs to add to the collection. For "urls", these are the full URLs. For other types, they are the identifiers (hashes for files, domain names for domains, etc.). operation (required): The operation to perform. Can be "add" or "remove".

Returns: A string indicating the success or failure of the operation.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`iocs`	Yes
`operation`	Yes
`relationship`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It mentions it is an update operation and returns a success/failure string, but lacks details on idempotency, error handling, side effects (e.g., overwriting vs appending), or required permissions.

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?

The description is concise and structured with clear Args/Returns sections. No redundant information, though could be slightly more polished.

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

Completeness3/5

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

Given the tool's complexity (mutation, 4 required params, no output schema details beyond a string), the description covers the basics but omits error conditions, idempotency, and rate limits. Adequate for simple usage, but incomplete for an autonomous agent.

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 0%, so the description compensates by explaining each parameter: id is collection ID, relationship types are enumerated, iocs format depends on type, operation is add or remove. This adds essential meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it updates IOCs in a collection with add/remove operations. It identifies the specific resource (collection) and action, distinguishing it from sibling tools like create_collection or search_iocs.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. While the verb 'update' implies modification, there is no mention of prerequisites, exclusions, or comparison to similar tools like update_collection_attributes.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes, e.g., searching different entity types (search_campaigns, search_malware_families) and retrieving reports (get_file_report, get_domain_report). However, search_threats can filter by collection_type, causing slight overlap with the specific search tools. Overall clear differentiation.

Naming Consistency4/5

Predominantly follows verb_noun pattern (e.g., create_collection, get_collection_report). Inconsistencies include 'analyse_file' (British spelling) versus American spelling used elsewhere, and verbose names like get_entities_related_to_a_collection. Still largely predictable.

Tool Count3/5

With 36 tools, the count is on the high side. The server covers a broad threat intelligence domain, but multiple similar tools (e.g., seven search tools, five get_entities_related_to_* tools) add redundancy. Could be streamlined without losing functionality.

Completeness4/5

The tool set covers CRUD operations for collections, detailed reports for various IOC types, and specialized searches. Notable gap: no tool to delete a collection entirely (only update). Digital threat monitoring and hunting rulesets are well-integrated. Minor missing features prevent a perfect score.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Nullcone Threat Intelligence A
io.github.maco144
Real-time threat intel for AI agents: 890K+ IOCs incl. prompt-injection & AI-skill threats
Security AI & Machine Learning
302
Metrifyr
cloud.metrifyr
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Monitoring Search Marketing
2
SOAR Record Gateway
ai.lateos
SOAR security playbooks for AI agents: fetch, full-text search, and count. Metered via Stripe.
Security Customer Support Search
1
Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
1

Related MCP Servers

Google Threat Intelligence MCP
Security Search
googleSandy
F
license
A
quality
C
maintenance
Enables AI assistants to access Google's Threat Intelligence suite for file analysis, indicator of compromise searches, and reputation checking. It supports both local and cloud-based deployments for investigating campaigns, threat actors, and malware families.
Updated 6 months ago (2026-03-08 21:14 UTC)
36
4
MITRE ATT&CK MCP Server
Security Open Data Research & Data
imouiche
A
license
A
quality
D
maintenance
Enables AI-native access to the MITRE ATT\&CK framework, allowing LLMs and agents to query techniques, threat groups, software, and generate ATT\&CK Navigator layers for threat intelligence and security workflows.
Updated 8 months ago (2025-12-22 01:21 UTC)
65
76
5
Apache 2.0
falcon-mcp
Security Monitoring
carlosmmatos
A
license
Not graded
quality
B
maintenance
Connects AI agents with the CrowdStrike Falcon platform to programmatically access detections, threat intelligence, host management, and other security capabilities for intelligent security analysis and automation.
Updated 5 days ago (2026-08-28 20:01 UTC)
MIT
OpenCTI MCP Server
Security Research & Data
Space-C0wboy
A
license
Not graded
quality
B
maintenance
Enables AI assistants to query and manage OpenCTI threat intelligence data, including indicators, observables, reports, malware, and more, with read-only and optional write operations.
Updated 2 months ago (2026-07-14 21:36 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

Google Threat Intelligence MCP Server

Project Origin & Deployment Philosophy

🔍 How This Repository Differs from the Official Mono-Repo

Table of Contents

Core Features

🔍 Intelligence & Hunting

📁 Files & Artifacts

🌐 Domains, IPs, and URLs

Configuration & Customization (Optional)

Getting Started

🚀 Choose Your Path

Local Development & Setup

Prerequisites

Quick Start (Local Python)

🧪 Verifying Your Local SSE Server (No Agent Required)

Step 1: Run the Server (Terminal Window 1)

Step 2: Open the Event Stream (Terminal Window 2)

Step 3: Perform the Handshake and Run Queries (Terminal Window 3)

Containerization & Docker (Alternative)

Production Google Cloud Run Deployment (Strict Secret Manager)

Step 1: Set Your Deployment Variables

Step 2: Authenticate and Enable Required GCP Services

Step 3: Secure your API Key in Google Secret Manager

Step 4: Grant Access to the Cloud Run Service Account

Step 5: Deploy to Cloud Run (Choose Your Path)

🚀 Option A: Direct Source-to-Cloud Deployment (No Local Docker Required)

🐳 Option B: Traditional Docker Build, Push, & Deploy

Step 6: Retrieve and Save Your Cloud Run Service URL

🧪 Verifying Your Cloud Run Stateless HTTP Server (No Agent Required)

Step 1: Start the Cloud Run Proxy (Terminal Window 1)

Step 2: Query the Tools List (Terminal Window 2)

Gemini Enterprise Integration (Optional)

Step 1: Enable Required APIs

Step 2: Define Your OAuth Endpoints

Step 3: Create an OAuth Client ID

Step 4: Create the Custom MCP Data Store (via setUpDataConnector REST API)

Step 5: Authorize the Gemini Enterprise Service Account (IAM)

Step 6: Reload and Enable Your Actions (GCP Console UI)

Step 7: Link the Custom MCP Data Store to your Gemini App (GCP Console UI)

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API