Skip to main content
Glama
StanimirTenev

qrp-mcp

by StanimirTenev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

scan_repo

Read-onlyIdempotent

Inventory cryptography across code and config files in a local directory tree, returning each algorithm's file, line, post-quantum status, and coverage count.

Instructions

Inventory the cryptography inside one local directory tree, file by file.

Reads source, configuration (nginx.conf, sshd_config, .ini, .toml), CI pipelines, Terraform and Kubernetes manifests under path. Returns each algorithm found with its file and line, the mathematical family and standing of every post-quantum scheme, and a coverage count.

Use this to answer what a specific project on this machine actually uses. Do not use it to ask whether this server knows a given algorithm, or to explain how one is classified without scanning anything -- list_algorithms answers that from the same table and reads no files. It is also the wrong tool for a network endpoint, a running host or a certificate store: it opens files on disk and nothing else.

Coverage is reported as a fraction with a base. files_scanned + unreadable_files + files_skipped_by_type + the linked files in symlinks_not_followed == files_present; a link is not followed and is named, not read. A file that could not be opened is listed, never counted as scanned, because no findings in a file nobody read is not the same as a file that is clean. Files skipped because this tool does not claim their type are counted by extension, so the reader can judge the boundary rather than assume past it.

Cost scales with the size of the tree, so a large monorepo takes proportionally longer; there is no cache and no partial mode.

Quoted lines are masked by default. Reading happens on this machine, but this result does not stay on it: it is returned to a model, which is a place the scanned line has not been before. A secret sharing a line with a finding -- a token in the call that names the cipher -- would travel with it. Masking keeps what a reader needs (the algorithm, the file, the line number, the shape of the call) and removes what nobody asked for. Pass level="full" when the line itself is the thing being examined.

Input Schema

NameRequiredDescriptionDefault
pathYesDirectory to scan, absolute or relative to the working directory: a checked-out repository, a service directory, a config tree. Vendored, build and cache directories (.git, node_modules, vendor, venv, .venv, dist, build, target, .tox, __pycache__, .pytest_cache, .mypy_cache, .ruff_cache) are excluded and do not count toward files_present; the verdict names how many files each one held, .git excepted.
levelNoHow much of each matched line to return. `masked` (the default) keeps the characters that spell the algorithm and stars every other letter and digit; `full` returns the line as written; `trimmed` returns no line at all. File and line number are the same at every level.masked
profileNoWhose rules each `replacement` follows. `nist` (the default) is FIPS 203/204/205. The others read one national document each and say whom it addresses: us-cnsa2 (NSA, US National Security Systems), uk-ncsc, au-ism, ca-cccs, de-bsi, fr-anssi, nl-ncsc, eu-eccg (EU product certification), bg (no Bulgarian guidance found; EU roadmap dates). Detection is identical under every profile.nist

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.35.0
    • changedInput schema / properties / path / description
      Previous value: -"Directory to scan, absolute or relative to the working directory: a checked-out repository, a service directory, a config tree. Vendored and build directories (.git, node_modules, vendor, dist, build, target) are excluded and do not count toward files_present."New value: +"Directory to scan, absolute or relative to the working directory: a checked-out repository, a service directory, a config tree. Vendored, build and cache directories (.git, node_modules, vendor, venv, .venv, dist, build, target, .tox, __pycache__, .pytest_cache, .mypy_cache, .ruff_cache) are excluded and do not count toward files_present; the verdict names how many files each one held, .git excepted."
  2. Changed1 schema field changedv0.27.0
    • addedInput schema / properties / profile
      Added value: +{
+  "default": "nist",
+  "description": "Whose rules each `replacement` follows. `nist` (the default) is FIPS 203/204/205. The others read one national document each and say whom it addresses: us-cnsa2 (NSA, US National Security Systems), uk-ncsc, au-ism, ca-cccs, de-bsi, fr-anssi, nl-ncsc, eu-eccg (EU product certification), bg (no Bulgarian guidance found; EU roadmap dates). Detection is identical under every profile.",
+  "enum": [
+    "nist",
+    "us-cnsa2",
+    "uk-ncsc",
+    "au-ism",
+    "ca-cccs",
+    "de-bsi",
+    "fr-anssi",
+    "nl-ncsc",
+    "eu-eccg",
+    "bg"
+  ],
+  "title": "Profile",
+  "type": "string"
+}
  3. Changed1 schema field changedv0.17.0
    • addedInput schema / properties / level
      Added value: +{
+  "default": "masked",
+  "description": "How much of each matched line to return. `masked` (the default) keeps the characters that spell the algorithm and stars every other letter and digit; `full` returns the line as written; `trimmed` returns no line at all. File and line number are the same at every level.",
+  "enum": [
+    "full",
+    "masked",
+    "trimmed"
+  ],
+  "title": "Level",
+  "type": "string"
+}
  4. Changed1 schema field changedv0.6.0
    • addedInput schema / properties / path / description
      Added value: +"Directory to scan, absolute or relative to the working directory: a checked-out repository, a service directory, a config tree. Vendored and build directories (.git, node_modules, vendor, dist, build, target) are excluded and do not count toward files_present."
  5. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already carry readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description adds substantial context beyond them: cost scales with tree size with no cache and no partial mode, symlinks are named but never followed, unreadable files are listed but not counted as scanned, and masked lines still leave the machine to a model — a real disclosure about where the data travels. It also states precisely what masking preserves and removes, which is exactly the kind of thing annotations cannot express.

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?

Front-loaded: purpose in the first line, siblings and exclusions next, then cost and privacy. A few sentences editorialize rather than inform ('no findings in a file nobody read is not the same as a file that is clean') and the coverage-accounting paragraph is dense, but almost every line carries operational weight.

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?

An output schema exists, so return values are covered elsewhere, and the description fills the remaining gaps an agent needs: how coverage fractions reconcile with `files_present`, why skipped extensions are surfaced, why unreadable files are never silently treated as clean, and what the privacy posture of the result is. Nothing material is missing for a read-only scan tool.

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 nevertheless adds a decision rule the schema lacks — pass `level="full"` when the line itself is the thing being examined — and frames `profile` as changing only whose `replacement` rules apply while detection stays identical. It does not add anything for `path` beyond the schema's own exclusion list.

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 — inventory cryptography in one local directory tree, file by file — and enumerates the file classes it reads (source, nginx.conf, CI pipelines, Terraform, Kubernetes manifests). It explicitly distinguishes itself from `list_algorithms` (same table, reads no files), so an agent can separate the two without opening either schema.

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?

Gives positive guidance ('answer what a specific project on this machine actually uses') and multiple explicit exclusions: not for asking whether the server knows an algorithm, not for explaining classification, not for network endpoints, running hosts or certificate stores — 'it opens files on disk and nothing else.' The alternative (`list_algorithms`) is named by name, plus a direct routing rule for `level="full"`.

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

Deploy Server

Other Tools