Skip to main content
Glama
tarhou
by tarhou

Supply evidence from another MCP server

chokepoint_supply_evidence

Relay evidence from connected MCP telemetry servers into Chokepoint Finder's safety gates; stale or partial data blocks the gate, and human confirmation is required for coverage changes.

Instructions

Feed a pre-flight gate from an MCP server you already have connected.

Chokepoint Finder holds no EDR, SIEM or ITSM credentials and never will. This is how it sees that telemetry anyway: your agent queries whatever server provides it -- CrowdStrike, SentinelOne, Splunk, Sentinel, ServiceNow, a CTI platform -- and relays the answer here with its provenance. The same composition the execution path uses, applied to evidence intake.

The trust rules do not soften for relayed data. Stale, partial or truncated input still reads UNKNOWN and still holds the gate, and every verdict built on it prints the source, the collection time and the fact that it was relayed rather than pulled directly.

Calls that establish, refresh, replace, or extend coverage require confirm=true after the agent presents the evidence to a human. The only unconfirmed update accepted is an additive detection or freeze inside already-covered scope; that path preserves the established coverage and freshness, so it can only make a decision more cautious. Never self-attest.

Send an empty items list ONLY when the source genuinely returned nothing. If the query failed, say so by omitting this call entirely: an unsupplied channel reads UNKNOWN and holds, which is the safe answer. Reporting a failed query as "nothing found" is the one input that could widen what the agent is willing to do.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesEDR: [{asset_id, severity, rule, age_hours}]. change_freeze: [{asset_id, reason}]. An empty list means the source was queried and found nothing -- do not send [] if the query failed.
scopeYesWhat was actually queried, e.g. 'all Windows servers, last 24h'. Under-scoped evidence is worse than none, so be specific.
sourceYesThe MCP server or system the data came from, e.g. 'crowdstrike-mcp', 'splunk-mcp', 'servicenow-mcp'. Recorded verbatim.
channelYesWhich gate to feed: edr | change_freeze
confirmNoHuman confirmation that the relayed evidence may establish, refresh, replace, or extend gate coverage. Not needed for caution-only detections/freezes added inside existing coverage.
completeYesFalse if the query was partial, paged out or capped. A partial answer holds the gate.
collected_atYesWhen the SOURCE collected this, ISO 8601 UTC, e.g. 2026-08-05T09:00:00Z. Not the time you are calling this tool.
confirmed_atNoUTC time of the human confirmation, ISO 8601.
confirmed_byNoOperator identity recorded on the approval receipt.
confirmation_idNoUnique human approval receipt ID; one-time use.
evidence_digestNoExact SHA-256 digest printed by the refused preview call.
covered_asset_idsYesExact asset IDs the source query covered. Scope prose is audit context only and cannot widen this set.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses important behavioral traits: Chokepoint Finder holds no EDR/SIEM/ITSM credentials; stale/partial/truncated input reads UNKNOWN and holds the gate; every verdict prints source, collection time, and relayed status; calls that establish/refresh/replace/extend coverage require confirm=true; never self-attest. This is rich, safety-critical context that the annotations alone do not provide.

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 long (four paragraphs) but well-structured: it starts with the core purpose, then explains trust rules, confirmation requirements, and empty-items semantics. Every paragraph earns its place given the safety-critical nature of the tool. It is not as concise as a two-sentence description, but the length is justified by the complexity, and the front-loaded opening sentence immediately clarifies the action.

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 (12 parameters, 7 required, safety implications), the description is exceptionally complete. It covers the tool's role, the provenance model, trust rules, confirmation workflow, and edge cases like failed queries and empty results. An output schema exists, so return values need no explanation. The description leaves no significant gaps for an agent to misuse the tool.

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 12 parameters with detailed descriptions (e.g., items, scope, confirm, complete). The tool description adds some nuance on the items parameter ('Send an empty items list ONLY when the source genuinely returned nothing' and the failed-query rule), but most parameter semantics are already in the schema. The description provides marginal added value beyond the schema, so a baseline 3 is appropriate.

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 opens with a specific action: 'Feed a pre-flight gate from an MCP server you already have connected.' It clearly distinguishes this tool from siblings like chokepoint_ingest by explaining it relays evidence from external MCP servers (CrowdStrike, Splunk, etc.) rather than pulling directly or holding its own credentials. The purpose is unmistakable and differentiated.

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?

The description provides explicit when-to-use and when-not-to-use guidance. It states the tool is for relaying evidence from other MCP servers, and explicitly says 'If the query failed, say so by omitting this call entirely' while also explaining that an empty items list should only be sent when the source genuinely returned nothing. It also details the confirm=true requirement for coverage changes and permits unconfirmed additive detections/freezes, giving clear operational rules.

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

Install Server

Other Tools

Latest Blog Posts

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/tarhou/chokepoint-finder-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server