Google Threat Intelligence MCP Server

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

With no annotations provided, the description carries the full burden. It discloses some behavioral traits: it explains the collection modeling, the order_by options with syntax details (+/- for ascending/descending), and default values. However, it doesn't cover important aspects like rate limits, authentication needs (though api_key is in schema), or error conditions.

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

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

The description is appropriately sized and front-loaded: it starts with the core purpose, then provides usage context, parameter details, and return information. The Args/Returns sections are clearly structured, though some sentences could be more concise.

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

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

Given the tool's moderate complexity, no annotations, and an output schema (which handles return values), the description is reasonably complete. It covers purpose, usage workflow, parameter semantics, and behavioral details like ordering. The main gap is not explaining the api_key parameter or authentication requirements.

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

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

With 0% schema description coverage, the description compensates well by explaining all parameters: query is for 'search query to find threats', limit controls 'number of threats to retrieve', and order_by details sorting options and syntax. The api_key parameter isn't mentioned, but the other three are clearly documented.

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

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

The description clearly states the tool searches for vulnerabilities (CVEs) in the Google Threat Intelligence platform, specifying the verb 'search' and resource 'vulnerabilities'. It distinguishes from some siblings like 'search_threats' or 'search_campaigns' by focusing on vulnerabilities, though not all sibling distinctions are explicit.

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

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

The description provides clear context for usage: it explains that vulnerabilities are modeled as collections and that results from this tool can be used with 'get_collection_report' for full reports. It doesn't explicitly state when not to use it or name all alternatives, but the workflow guidance is helpful.

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