Huntertech.io

Get Vendor Incidents

get_vendor_incidents

Read-onlyIdempotent

Read-only incidents for one monitored vendor. Guest and Free: ongoing plus monitoring only, max 5 (default when status is omitted). Optional status narrows to ongoing, monitoring, or resolved; resolved history requires Standard or higher (use includeResolved, timePeriod, or status=resolved). After sign-in, tools/list also exposes get_incident for a single record by id.

Input Schema

Name	Required	Description
`limit`	No	Maximum incidents to return. Guest and Free maximum is 5. Standard and above maximum is 50.
`status`	No	Lifecycle bucket: ongoing (active impact), monitoring (watching or fix-pending), resolved (closed). investigating is an alias for ongoing. resolved requires Standard or higher.
`vendor`	Yes	Vendor ID, for example zscaler, cloudflare, github, openai.
`timePeriod`	No	History window such as 7d, 30d, 90d, or all when allowed by plan. Requires Standard or higher.
`includeResolved`	No	Include resolved incidents in the fetch. Requires Standard or higher.

Output Schema

Name	Required	Description	Default
`total`	Yes
`success`	Yes
`vendorId`	No
`checkedAt`	No
`incidents`	Yes
`dataWindow`	No
`nextAction`	No
`vendorName`	No
`accessLevel`	Yes
`lastUpdated`	No
`vendorIncidentsUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 26, 2026

changedInput schema / properties / includeResolved / description

Previous value: -"Include resolved incidents. Requires Standard or higher."New value: +"Include resolved incidents in the fetch. Requires Standard or higher."

addedInput schema / properties / status

Added value: +{
+  "description": "Lifecycle bucket: ongoing (active impact), monitoring (watching or fix-pending), resolved (closed). investigating is an alias for ongoing. resolved requires Standard or higher.",
+  "enum": [
+    "ongoing",
+    "monitoring",
+    "resolved",
+    "investigating"
+  ],
+  "type": "string"
+}

changedInput schema / properties / timePeriod / description

Previous value: -"Authenticated history window such as 7d, 30d, 90d, or all when allowed by plan."New value: +"History window such as 7d, 30d, 90d, or all when allowed by plan. Requires Standard or higher."

First observedOct 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered; the description adds real value beyond that with plan-based quota caps (5 vs 50), the default behavior when status is omitted, and tier gating on resolved/history. It omits pagination and truncation signaling, which matters for a capped list 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?

Purpose is front-loaded in the first sentence and the rest is dense plan-gating detail. The parenthetical 'max 5 (default when status is omitted)' is slightly ambiguous about whether it caps results or describes the default status bucket.

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?

With a full output schema, 100% parameter coverage, and read-only annotations, the remaining burden is plan gating and defaults — both covered. An agent has everything needed to call it correctly and interpret a short result as a tier cap rather than an outage lull.

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 100%, so the baseline is 3, but the description clarifies the default result set when status is omitted and ties includeResolved/timePeriod/status=resolved to the same Standard-tier gate, adding meaning the per-parameter text doesn't fully connect. Some tier wording is repeated from the schema, so it isn't a full step above baseline.

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?

States a specific verb and resource with explicit scope: read-only incidents for ONE monitored vendor, which implicitly but clearly separates it from get_all_vendor_incidents. An agent can determine what this returns without opening the schema.

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?

Gives concrete use context: Guest/Free get ongoing+monitoring capped at 5, and resolved history requires Standard or higher via includeResolved, timePeriod, or status=resolved. It also routes to get_incident for a single record, though it never explicitly names get_all_vendor_incidents as the multi-vendor alternative.

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

All Huntertech.io 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?