greynoise-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

Create Blocklist

create-blocklist

Build a dynamic IP blocklist from a GNQL query; matching IPs auto-populate the list. Requires a blocklist-entitled plan.

Instructions

Create a dynamic blocklist from a GNQL query. The blocklist auto-populates with IPs matching the query. Requires a plan entitled to blocklists.

Input Schema

Name	Required	Description
`name`	No	Human-friendly blocklist name
`query`	Yes	GNQL query whose matching IPs populate the blocklist
`enabled`	No	Whether the blocklist is active (default: true)
`ip_limit`	No	Max IPs to include
`workspace_id`	No	Workspace ID (UUID). Defaults to the workspace the API key is bound to.

Output Schema

Name	Required	Description	Default
`id`	Yes
`name`	No
`query`	No
`token`	No
`enabled`	No
`ip_limit`	No
`created_at`	No
`updated_at`	No
`workspace_id`	No
`last_ip_count`	No
`entitlement_level`	No
`query_workspace_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.5.5Nov 2, 2026

removedOutput schema / properties / ip_limit / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / ip_limit / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / name / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / name / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Addedv0.5.4Jul 23, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish that this is a non-read-only, non-idempotent, open-world operation. The description adds useful behavior beyond the annotations by explaining that the blocklist is dynamic, auto-populates from matching IPs, and requires a plan entitlement.

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 three short sentences with no wasted text. It is front-loaded with the core action and then adds the auto-population behavior and entitlement requirement.

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 and annotations covering safety and idempotency, the description provides enough context to understand the tool's purpose and key requirement. It could be slightly more complete by referencing related update/delete tools, but nothing essential is missing for correct invocation.

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 description coverage is 100%, so the schema already documents all five parameters, including the GNQL query and optional fields. The description reinforces that the query drives IP population but does not add parameter-specific syntax, defaults, or constraints 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 states a specific verb and resource: create a dynamic blocklist from a GNQL query. It clearly explains that matching IPs auto-populate the blocklist, but it does not explicitly distinguish this from sibling tools such as update-blocklist or list-blocklists.

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 when to use it by saying it creates a dynamic blocklist from a GNQL query, and it notes the plan entitlement requirement. However, it does not state when not to use it or explicitly compare it with alternatives like update-blocklist or create-alert.

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

Deploy Server