BlueNOC

Price a BlueNOC configuration

get_pricing_quote

Read-onlyIdempotent

The exact monthly price BlueNOC charges for a number of firewalls, a security analysis frequency, a log retention period and a billing cycle. At or above the enterprise threshold the answer is contact=true with no price.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "firewalls": "<firewalls>",
      "frequency": "<frequency>",
      "retention_days": "<retention_days>"
    },
    "name": "get_pricing_quote"
  }
}

Input Schema

Name	Required	Description	Default
`billing`	No		monthly
`firewalls`	Yes	Number of firewalls to monitor.
`frequency`	Yes	How often the security analysis runs.
`retention_days`	Yes	Log retention in days (30 is included).

Output Schema

Name	Required	Description
`price`	Yes	Price per month shown to the customer (discounted when billing is annual).
`billing`	Yes
`contact`	Yes	True at or above the enterprise threshold: no price, talk to sales.
`monthly`	No	Undiscounted monthly price.
`currency`	Yes
`breakdown`	Yes
`firewalls`	No	The number of firewalls priced.
`frequency`	No	The security analysis frequency priced.
`annual_total`	No	Total billed per year when billing is annual.
`retention_days`	No	The log retention priced, in days.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "annual_total": {
+      "description": "Total billed per year when billing is annual.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "billing": {
+      "enum": [
+        "monthly",
+        "annual"
+      ],
+      "type": "string"
+    },
+    "breakdown": {
+      "items": {
+        "properties": {
+          "amount": {
+            "type": "number"
+          },
+          "key": {
+            "enum": [
+              "platform",
+              "firewalls",
+              "frequency",
+              "retention"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "key",
+          "amount"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "contact": {
+      "description": "True at or above the enterprise threshold: no price, talk to sales.",
+      "type": "boolean"
+    },
+    "currency": {
+      "type": "string"
+    },
+    "firewalls": {
+      "description": "The number of firewalls priced.",
+      "type": "integer"
+    },
+    "frequency": {
+      "description": "The security analysis frequency priced.",
+      "type": "string"
+    },
+    "monthly": {
+      "description": "Undiscounted monthly price.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "price": {
+      "description": "Price per month shown to the customer (discounted when billing is annual).",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "retention_days": {
+      "description": "The log retention priced, in days.",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "contact",
+    "currency",
+    "billing",
+    "price",
+    "breakdown"
+  ],
+  "type": "object"
+}

First observedNov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the read-only, idempotent, closed-world profile, but the description adds genuinely new behavior: at or above the enterprise threshold the response is contact=true with no price. That is exactly the kind of non-obvious outcome an agent must anticipate. It stops short of noting currency, tax treatment, or that quotes are non-binding.

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, both load-bearing: the first defines the computation and its inputs, the second front-loads the exception case. No filler, no restating of the title, and the surprising behavior is placed where it will be read.

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?

The tool is a simple read-only calculation with an output schema, so return-value detail is unnecessary; the description covers inputs and the one edge case that changes the response shape. What remains missing is the relationship to the sibling pricing model tool and any note on currency or quote validity.

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 75% with three enums, so most parameters are already documented structurally, and the description adds no per-parameter meaning beyond restating them. It does incidentally tie the enterprise-threshold behavior to the firewalls input, but never clarifies why the description says 'monthly price' while billing accepts annual.

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?

States a specific outcome (exact price BlueNOC charges) and enumerates the inputs that determine it — firewalls, analysis frequency, retention, billing cycle — so an agent can tell it computes a quote rather than describing the price model. It does not explicitly contrast itself with the sibling get_pricing_model, leaving that differentiation to inference.

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 is implied: call it when you need a concrete quote for a concrete configuration. There is no explicit when-to-use/when-not guidance and no named alternative (e.g., get_pricing_model for the formula or for hypothetical/partial inputs), so routing between the two pricing tools is left to the agent.

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

All BlueNOC tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?