Skip to main content
Glama
robyroro

mcp-latchpoint

by robyroro
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mcp-latchpoint

mcp-latchpoint audits MCP client configuration files without running the configured servers. It works offline, reads only local files you select, and produces text, JSON, or SARIF results.

This is an early defensive tool. Review findings in context before changing a working configuration.

What it checks

The v0.1 rules cover:

  • plain HTTP for non-loopback remote endpoints

  • shell wrappers and inline shell control syntax

  • identifiable npx and uvx packages without exact versions

  • literal credentials in environment values, headers, arguments, or URLs

  • filesystem roots and home roots passed as recognizable access scopes

  • wildcard hosts and recognizable wildcard scopes

  • conflicting, missing, invalid, or unsupported transport settings

Every finding has a stable rule ID, severity, location, remediation, redacted evidence, and a confidence note when interpretation depends on the launched server.

Related MCP server: mcpharden

Install

Python 3.11 or newer is required.

python -m venv .venv
# Linux or macOS
. .venv/bin/activate
# Windows PowerShell
.venv\Scripts\Activate.ps1
python -m pip install .

For development:

python -m pip install -e ".[dev]"
pytest
ruff check .
mypy

The MCP server uses the official Python SDK v2 and the dependency is constrained to mcp>=2.3,<3.

CLI

Scan one or more explicit files:

mcp-latchpoint scan ~/.config/Code/User/mcp.json
mcp-latchpoint scan examples/risky.json --format json
mcp-latchpoint scan examples/risky.json --format sarif --fail-on high > results.sarif

Restrict every explicit path to an approved directory:

mcp-latchpoint scan ./configs --allowed-root ./configs

Directories are searched only for recognized MCP config filenames, up to 256 files. A file is limited to 1 MiB by default. Change these bounds with --max-files and --max-bytes.

Exit codes are 0 for a completed scan below the chosen threshold, 1 when a finding meets --fail-on, and 2 for input, containment, or parse errors. The default --fail-on none reports findings without failing a build.

List and explain rules:

mcp-latchpoint rules
mcp-latchpoint explain MCP004

Recognized layouts

Explicit files may use these structures:

Client layout

Container

Accepted file syntax

Claude Desktop, Cursor, portable .mcp.json, generic MCP JSON

top-level mcpServers object

JSON

Claude Code user/local settings

top-level mcpServers, plus projects.<path>.mcpServers in ~/.claude.json

JSON

VS Code

top-level servers object

JSONC for .vscode/mcp.json

Codex

[mcp_servers.<name>] tables

TOML

Files ending in .jsonc are also parsed as JSONC. Other .json files remain strict JSON so malformed input is not silently accepted.

--discover checks only the following paths when they exist. It does not search the rest of the home directory.

  • All systems: ~/.claude.json, ~/.cursor/mcp.json, ~/.codex/config.toml, $COPILOT_HOME/mcp-config.json with ~/.copilot/mcp-config.json as the fallback

  • Current project: .mcp.json, .codex/config.toml, .cursor/mcp.json, .vscode/mcp.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json, %APPDATA%\Code\User\mcp.json

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json, ~/Library/Application Support/Code/User/mcp.json

  • Linux: $XDG_CONFIG_HOME/Code/User/mcp.json, falling back to ~/.config/Code/User/mcp.json

Read-only MCP server

The stdio server exposes two tools: list_rules and scan. It requires an allowed root at startup. Relative scan paths are resolved below that root; absolute paths, .. traversal, and symlinks cannot escape it.

mcp-latchpoint-server --root /absolute/path/to/reviewed-configs

Example client entry:

{
  "mcpServers": {
    "latchpoint": {
      "command": "/absolute/path/to/mcp-latchpoint-server",
      "args": ["--root", "/absolute/path/to/reviewed-configs"]
    }
  }
}

The server returns findings and scan metadata, never raw configuration content. Stdio is the only server transport exposed by the entry point, and stdout is reserved for MCP protocol messages.

Glama build

The Glama listing builds a container from the repository. In its Dockerfile configuration, use Python 3.13, these build steps and command arguments:

["uv sync --no-dev"]
["mcp-proxy", "--", "/app/.venv/bin/mcp-latchpoint-server", "--root", "/app/examples"]

The root is an existing directory with synthetic sample configurations. It lets Glama start and inspect the tools without giving the server access to a user's files. The command uses the executable inside the virtual environment created by uv sync. For this demo, the environment-variable schema can be {"type":"object","properties":{}} and placeholder parameters can be {}.

To scan your own configurations, run the server locally with --root pointing to a directory you explicitly trust. Glama's demo root is only for the sample files in examples/.

Safety and limitations

The scanner never executes commands, installs packages, resolves referenced environment variables, or connects to endpoints. It does not follow configuration includes or inspect an MCP server's code or runtime behavior. Argument-based rules are intentionally limited to recognizable patterns, so custom flags can be missed. A clean report is not proof that a server is safe.

Secret detection is designed to emit field names and <redacted> markers rather than values. If you find a leak or a path-containment problem, follow SECURITY.md and do not attach a real configuration to a public issue.

License

MIT. See LICENSE.

Available Tools

2 tools
list_rulesA

List stable audit rule IDs, severity, descriptions, and remediation.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. The word 'stable' is a genuine behavioral hint that unstable/deprecated rules are excluded, but nothing is said about pagination, result size, or whether the call is side-effect free (implied by 'List').

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?

A single front-loaded sentence with no filler; the verb and the returned fields appear immediately.

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?

An output schema exists, so explaining return values is redundant (and mildly duplicative here). For a zero-parameter catalog listing, the definition is largely sufficient, though it omits how the output connects to 'scan'.

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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for on the input side.

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 verb ('List') and resource ('audit rule') and enumerates the fields returned (IDs, severity, descriptions, remediation). It is clearly distinguishable from the sibling 'scan', though it never explicitly says so.

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 statement of when to call this versus 'scan', nor any workflow context (e.g., use this first to obtain rule IDs). The agent must infer the relationship from the tool names alone.

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

scanC

Scan a config file or directory inside the server's allowed root.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the allowed-root boundary and does not explain side effects, permissions, whether the operation is read-only, or what scanning entails.

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 front-loaded sentence with no wasted words. It is efficient, though arguably too terse given the tool's security-sensitive scope and lack of annotation coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, but the description still misses key behavioral context. With no annotations and 0% parameter coverage, it should say more about what scanning does and any operational constraints beyond the allowed root.

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 0%, so the description must compensate for the undocumented 'path' parameter. It adds meaning by saying the path is a config file or directory inside the allowed root, but it omits format details such as absolute vs. relative paths or expected syntax.

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 names a specific verb ('Scan') and resource ('config file or directory') and adds a scoping constraint ('inside the server's allowed root'). It is clear enough to distinguish from a generic operation, but it does not differentiate this tool from the sibling 'list_rules' or explain what 'scan' actually produces.

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?

The description provides no explicit guidance on when to use this tool versus alternatives. It implies a context (config file or directory) but never states when a caller should choose 'scan' over 'list_rules' or any other sibling.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedlist_rules
    • First observedscan
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.3/5.0

Scored across 2 tools

Disambiguation5/5

list_rules enumerates audit rules while scan analyzes a config file or directory—two clearly distinct purposes targeting different objects (rule metadata vs. actual files). No overlap or confusion.

Naming Consistency4/5

list_rules follows a clean verb_noun pattern, but scan is a bare verb without a noun target, a minor deviation from the convention. Still readable and predictable overall.

Tool Count3/5

Two tools is borderline thin for an audit/lint server; listing rules and running a scan are essential, but the surface feels minimal for the apparent scanning domain.

Completeness3/5

The core discover-then-scan workflow exists, but there's no way to fetch a single rule's detail, filter by severity, or apply/view remediation beyond what list_rules returns. Notable gaps limit deeper audit workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • meok-mcp-injection-scan-mcp

    CSOAI-ORG
    A
    license
    A
    quality
    D
    maintenance
    Scans MCP servers for prompt-injection, tool-poisoning, and SSRF vulnerabilities using 30+ canonical rules across 5 severity tiers, with optional signed safety reports for procurement.
    5
    MIT

  • aster-guard

    Aster-Works
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables scanning MCP server configurations for security risks like prompt injection, hardcoded secrets, and dangerous commands, providing risk scores and detailed reports before connecting to an AI coding assistant.
    11 npm
    MIT

  • mcp-security-scanner

    badchars
    A
    license
    A
    quality
    C
    maintenance
    Security scanning for MCP servers from the inside out. Provides runtime inspection, AST-based static analysis, config audit, dependency analysis, and OWASP MCP Top 10 compliance in a single MCP server.
    55
    189 npm
    6
    MIT