chokepoint-finder-mcp

by tarhou

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct roles in the workflow, but some pairs like chokepoint_payload and chokepoint_plan (both produce outputs for a chokepoint) could be confused. Similarly, chokepoint_supply_evidence and chokepoint_preflight are closely related input/evaluation steps.
Naming Consistency4/5
All tools share the consistent 'chokepoint_' prefix, but the second part mixes verbs (ingest, setup, rank, verify) with nouns (payload, plan) and verb phrases (mark_executed, supply_evidence). This is readable but not perfectly uniform.
Tool Count5/5
10 tools is well within the ideal 3-15 range. Each tool maps to a distinct phase in the chokepoint-finding and remediation workflow, and none feel redundant or unnecessary.
Completeness5/5
The tool set covers the full lifecycle from setup and ingest to ranking, evidence gating, plan/payload generation, execution marking, and verification. The design intentionally leaves out direct execution, which is documented and consistent with the server's zero-trust posture.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, so the description does not need to restate safety. It adds some context by outlining the four-beat structure, but it does not explain what these beats actually entail or what side effects (if any) occur, such as whether state changes or outputs are produced.
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 a single, compact sentence that front-loads the core idea ('four-beat walkthrough') and then lists the beats. It is concise, but the cryptic beat names add color rather than clarity, and the sentence could be more straightforward without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, a read-only hint, and an output schema, the description is nearly sufficient. However, it does not connect the demo to the surrounding workflow (e.g., whether it should be run after setup or before verify), and the abstract language leaves the tool's actual behavior under-specified for an agent.
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?
The input schema has zero parameters, and the baseline for 0-parameter tools is 4. The description does not need to explain parameters because there are none, and the 100% schema coverage leaves no ambiguity.
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 identifies the tool as a 'four-beat walkthrough' on a 'deterministic simulated estate', which clearly distinguishes it from sibling tools like setup, ingest, or verify. The title 'Run the full demo' reinforces the action, but the metaphorical phrasing ('the wall, the collapse, the refusal') is less direct than an explicit statement like 'runs the complete demo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus the available siblings. The description implies it is for running a full demo walkthrough, but it does not state conditions, prerequisites, or alternatives, leaving the agent to infer usage from the name and title alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state non-destructive and non-read-only, adding little. The description goes beyond this by explaining the key behavioral trait: chokepoint value is marginal (what it eliminates given higher-ranked items are done) and that finding-risk and attack-path disruption are reported separately, not blended. This is valuable context for interpreting results.
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 two short sentences, front-loaded with the tool's core action and result. The second sentence adds essential algorithmic nuance without extraneous detail. Every word contributes useful information.
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?
Given the tool has only one optional parameter, an output schema, and annotations, the description provides a coherent conceptual model: greedy ranking with marginal values and separate metrics. It does not mention prerequisites such as prior ingestion or planning steps, but the sibling tool list and the phrase 'over synthesized actions' offer some context. Slightly incomplete on workflow placement.
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 100% for the single optional 'top' parameter, whose description 'How many chokepoints to select' is clear. The tool description does not add extra parameter semantics, but it is not needed given the schema already fully documents the parameter.
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 title 'Rank chokepoints' combined with 'Returns the shortlist' and the mention of chokepoints being 'ranked above it' clearly indicate the tool produces an ordered selection of chokepoints. The algorithm name 'Greedy weighted max-coverage' is specific but somewhat opaque, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus siblings like chokepoint_plan, chokepoint_payload, or chokepoint_mark_executed. The phrase 'over synthesized actions' implies it should be used after action synthesis, but the description does not state this prerequisite or any alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the types of data loaded (findings, assets, attack paths) and indicates the tool constructs an engine. Annotations already signal a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false), so the description does not contradict them, but it does not disclose deeper side effects like idempotency or data replacement.
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 a single sentence, front-loaded with the action and resources, with no redundant or filler words. It is concise and well-structured.
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?
Given the tool's simplicity (one optional parameter, output schema present), the description covers the core function adequately. It does not mention prerequisites like running setup first, but the pipeline context and sibling tools make this a minor omission.
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?
The only parameter 'source' is fully documented in the schema with allowed values and a default. The description's phrase 'from a source' aligns with the schema but adds no additional semantic detail beyond what the schema already provides.
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 uses a specific verb ('Load') and identifies the resources (findings, assets, attack paths) and the goal ('build the engine'). It clearly distinguishes the tool from siblings like chokepoint_setup or chokepoint_rank, which serve different pipeline stages.
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 the tool is the ingestion step in the chokepoint pipeline (loading data to build the engine). However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond the readOnlyHint annotation, stating the tool 'holds no write credentials by design and executes nothing itself.' It also discloses key behaviors such as requiring 'an explicit operator go quoting the plan hash' for MUTATES steps and that 'Held assets are excluded from every step,' which are not captured by annotations.
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 composed of four focused sentences, each covering distinct aspects: what the plan is, design constraints, step routing, mutation approval, and HOLD behavior. There is no filler or redundancy, and the structure front-loads the main purpose.
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 readOnlyHint annotation, the description covers essential behavioral rules, including HOLD outcomes, asset exclusion, and mutation approval. It does not describe the plan's exact JSON structure, but that is handled by the output schema, making this sufficiently complete for a planning 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?
The schema already provides complete descriptions for both parameters, including the rank source and json_output behavior. The description does not add parameter semantics beyond confirming the plan is typed and ordered, so it meets the baseline for 100% schema coverage.
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 identifies the tool as producing a 'Typed, ordered workflow for executing a chokepoint' and clarifies that it builds a plan rather than executing it, saying 'executes nothing itself.' This distinguishes it from sibling tools like preflight and verify, though the verb 'build' comes mainly from the title rather than the description itself.
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 use after a pre-flight: 'A HOLD pre-flight yields no plan, only the evidence,' and explains that MUTATES steps require operator go. However, it does not explicitly name alternative tools or state when to choose plan over payload or other siblings, so usage guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavior not present in annotations: fail-closed semantics, error/timeout/truncated/stale handling that returns UNKNOWN or ERROR, and explicit refusal to report clean. It also explains demo-mode simulation and the requirement for a non-simulated final-wave VERIFIED result. This far exceeds what the readOnlyHint/destructiveHint annotations convey.
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 compact and front-loaded with the core action, then systematically covers failure behavior and demo mode. Each sentence contributes distinct value without filler, making it easy to scan.
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?
Given the presence of an output schema and annotations, the description is strong on failure modes and demo behavior. It doesn't explicitly identify the authoritative source or pipeline prerequisites, but the canonical playbook references in the schema fill most gaps. It is complete enough for safe use in most scenarios.
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?
The schema already documents all three parameters with descriptions (plan_hash, wave, json_output), so the baseline is 3. The description adds 'final-wave' context that relates to the wave parameter and mentions demo mode, but it doesn't add new syntax or value formats beyond what the schema provides.
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 clearly states the tool re-queries the authoritative source and diffs against the baseline, which is a specific verb+resource. It does not explicitly name sibling alternatives, so it stops short of full differentiation, but the verification intent is unambiguous.
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?
The description provides clear context: this is used to verify a delta before closing a change record, with important caveats like 'fails closed' and 'only a non-simulated, final-wave VERIFIED result permits closing.' It does not explicitly say when not to use it or name alternative tools, but the when-to-use is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description reinforces this by stating 'Generates text only; it opens nothing.' This adds behavioral clarity beyond the annotation, confirming no side effects. No contradictions or missing relevant behavioral details for a simple generation tool.
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 two concise sentences, front-loaded with the tool's purpose and contents, followed by usage context and side-effect clarification. Every sentence earns its place with no redundancy.
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 a single parameter, 100% schema coverage, an output schema, and simple read-only behavior, the description fully covers what the tool does, what it produces, and how to use the result. It is complete for its complexity.
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%: the only parameter 'rank' is described as 'Chokepoint rank from chokepoint_rank'. The description does not add extra parameter semantics, but the schema fully defines the parameter, so 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 clearly states a specific action ('Generates text only') with a specific resource ('remediation payload for a chokepoint') and lists contents (summary, justification, change plan, rollback note). It distinguishes from siblings by emphasizing ticket-readiness and that it 'opens nothing.'
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?
The description gives clear context: use when a ticket-ready remediation payload is needed, to paste into Jira/ServiceNow or hand to a ticketing MCP. It does not explicitly name alternatives or exclusions, but the focus on text generation and 'opens nothing' helps disambiguate from action-oriented siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses key behaviors: missing/stale/failed evidence reads as UNKNOWN and produces HOLD, and the gate never clears what it cannot see. This adds meaningful context about how evidence is evaluated and verdicts are derived.
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 sentences, each earning its place: the first states the purpose, the second lists verdicts with a useful clarification, and the third explains the edge-case behavior. It is front-loaded and free of fluff.
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 single parameter and presence of an output schema, the description covers the essential behavioral details: gates checked, verdicts, and evidence handling. It fully explains the tool's decision logic without needing to document return values.
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% for the single 'rank' parameter, and the schema already states 'Chokepoint rank from chokepoint_rank'. The tool description adds no further parameter meaning, so the baseline score of 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 clearly states the tool evaluates evidence gates before acting, listing specific gates (EDR silence, change freeze, blast radius) and producing concrete verdicts. This distinguishes it from siblings like chokepoint_ingest or chokepoint_plan.
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?
The description implies when to use this tool: before acting, as a gating step. Verdicts like REQUIRES_STAGING and HOLD_PARTIAL clarify subsequent actions. However, it does not explicitly contrast with alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false. The description adds substantial behavioral detail: it mutates nothing outside internal accounting, requires explicit confirmation, rejects non-matching plan hashes and HOLD verdicts, and excludes pre-flight-held assets. This goes well beyond the annotations and gives the agent clear expectations for side effects and refusal conditions.
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 compact and front-loaded. The first sentence states the action, and the second paragraph lists constraints in a scannable list-like sentence. No filler words; every clause contributes meaningful information.
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?
For a 9-parameter state-changing tool, the description covers purpose, side-effect boundaries, all refusal conditions, and relationship to other servers/tools. Output schema exists, so return-value details are not the description's burden. It is complete enough for an agent to invoke safely and correctly.
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. The description adds value by explaining the meaning of key parameters: confirm must be true, plan_hash must match the current plan, and HOLD verdicts/pre-flight assets are excluded — which clarifies rank, wave, and approval fields. This lifts it 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?
The description uses a specific verb ('Record') with a clear resource ('that the plan's steps were executed') and states the downstream effect ('arming verification with expected retirements'). This distinguishes it from sibling tools like chokepoint_verify and chokepoint_plan.
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?
The description clearly implies when to use the tool: after plan steps have been executed through other MCP servers, and before verification. It also states important preconditions (explicit confirmation, matching plan hash, no HOLD verdict). It does not explicitly name alternative tools, but the context is strong enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond the annotations: it explains the demo mode makes no network calls, while live modes 'probe remote endpoints and can be slow on a captive-portal network.' It also reveals security handling ('Never asks for a secret in conversation') and idempotency ('Safe to run repeatedly'). These are valuable details not covered by readOnlyHint or openWorldHint.
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 efficiently organized into three short paragraphs: what it does, behavioral modes, and safety/repeatability. Every sentence adds value, and the opening 'First-run hand-holding' immediately conveys the purpose. No fluff or redundancy.
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?
The description covers all necessary aspects for a setup tool: purpose, usage modes, network behavior, security, and repeatability. With a schema, annotations, and output schema present, there are no significant gaps. It even explains where credentials live in the Tenable and AWS UIs, which is highly contextual and aids the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes `source` as 'Which source to check: demo | tenable | aws | all,' but the description adds significant meaning by explaining the behavioral implications of each value (e.g., 'demo' makes no network calls, 'tenable'/'aws'/'all' test live connectivity and may be slow). This goes well beyond the schema's minimal description.
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 clearly states a specific verb and resource: 'First-run hand-holding. Checks what is configured, tests connections, and gives the exact next step for anything missing.' It also differentiates itself from siblings by focusing on setup guidance and credential locations, making it distinct from tools like chokepoint_preflight or chokepoint_verify.
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?
It provides clear context: 'First-run hand-holding' implies use during initial setup, and 'run it again after each fix until everything you need says READY' specifies when to re-run. However, it does not explicitly name alternatives or state when not to use the tool, so it lacks the explicit 'vs alternatives' guidance seen in top-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![chokepoint-finder-mcp MCP server](https://glama.ai/mcp/servers/tarhou/chokepoint-finder-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tarhou/chokepoint-finder-mcp)

Score Badge

Copy to your README.md:

[![chokepoint-finder-mcp MCP server](https://glama.ai/mcp/servers/tarhou/chokepoint-finder-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tarhou/chokepoint-finder-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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