Skip to main content
Glama
Sign In
SkillTotal

SkillTotal

by pezhik
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Scan a component

scan_component
Read-only

Statically scans an AI component (skill, MCP server, package, repo, path or archive) for supply-chain risks, dangerous capabilities, prompt injection, and exfiltration before you install or trust it.

Instructions

Statically scan an AI component (agent skill, MCP server, npm/PyPI package, repository, local path or archive) for supply-chain risks, dangerous capabilities, prompt-injection surfaces, and exfiltration paths. Use this BEFORE installing or trusting a component. The scan is local, deterministic, and never executes the component's code. A local path is read in place; a git URL or npm:/pypi:/vscode:/openvsx: source is downloaded to a temp folder that is removed afterwards. A source over the size limit is refused with an error naming the setting that raises it. Decide on the verdict (level, headline, has_malicious_indicators), not on the number of findings: a finding whose threat_class is "capability" is something the component can do (run commands, read files, reach the network) and adds no risk; malicious_indicator and risky_construct findings are what the verdict and score rest on. Not checked: the code of the component's dependencies, known vulnerabilities (CVEs), and runtime behaviour. The default summary is a JSON object: component, verdict {level, headline, has_malicious_indicators}, decision (one line), risk_score, risk_level, why [{rule, threat_class, severity, title, evidence ["file:line snippet"]}] (risk findings first), capabilities [names], counts {findings_by_threat_class, needs_review}, check_manually [notes to read], not_checked [what this scan does not cover], engine {version, ruleset}. Pass detail="full" for the complete report.

Input Schema

NameRequiredDescriptionDefault
detailNosummary (default): the verdict, why (findings with up to 3 locations each), capabilities, counts, what to check by hand and what was not checked. full: the complete SkillTotal report JSON (every finding, all evidence, traits, needs_review).
sourceYesWhat to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], pypi:<name>[==version], or an editor extension as vscode:<publisher>.<name>[@version] (Visual Studio Marketplace) or openvsx:<namespace>.<name>[@version] (Open VSX).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.90.0
    • changedInput schema / properties / source / description
      Previous value: -"What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], or pypi:<name>[==version]."New value: +"What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], pypi:<name>[==version], or an editor extension as vscode:<publisher>.<name>[@version] (Visual Studio Marketplace) or openvsx:<namespace>.<name>[@version] (Open VSX)."
  2. Changed1 schema field changedv0.79.1
    • changedInput schema / properties / source / examples
      Previous value: -[
-  "npm:mcp-remote"
-]New value: +[
+  "npm:mcp-remote",
+  "pypi:mcp-server-fetch",
+  "https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem",
+  "/home/user/skills/pdf-tool"
+]
  3. Changed4 schema fields changedv0.75.0
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "summary (default): the verdict, why (findings with up to 3 locations each), capabilities, counts, what to check by hand and what was not checked. full: the complete SkillTotal report JSON (every finding, all evidence, traits, needs_review).",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "examples": [
+    "summary"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / source / description
      Previous value: -"What to scan: a local directory/file/archive path, a git URL, npm:<name>[@version], or pypi:<name>[==version]."New value: +"What to scan: an absolute path to a local folder, file or archive, a git URL (a subfolder as https://github.com/<owner>/<repo>/tree/<ref>/<path>), npm:<name>[@version], or pypi:<name>[==version]."
    • addedInput schema / properties / source / examples
      Added value: +[
+  "npm:mcp-remote"
+]
    • addedInput schema / properties / source / minLength
      Added value: +1
  4. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive; the description goes far beyond them by stating the scan is local and deterministic, never executes the component's code, downloads remote sources to a temp folder that is cleaned up, and refuses oversized sources with an error naming the relevant setting. It also lists what is NOT covered (dependency code, CVEs, runtime behaviour), which is exactly the kind of disclosure an agent needs.

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?

Dense but front-loaded: purpose and the before-you-install rule come first, then mechanics, then verdict interpretation, then the return shape. Every sentence carries information, though the middle section packs several distinct ideas (temp folders, size limits, threat classes, exclusions) into a single long block that could be split for easier scanning.

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 no output schema and only two parameters, the description carries the full burden and does so: it enumerates the summary JSON fields (verdict, decision, risk_score, why, capabilities, counts, check_manually, not_checked, engine) and points to detail="full" for the complete report. An agent has enough to call it correctly and interpret the result without further tooling.

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, and the description earns extra by explaining the semantics of the report the parameters select: threat_class 'capability' findings add no risk while malicious_indicator and risky_construct findings drive the verdict and score. That interpretive layer meaningfully helps an agent interpret and choose detail levels, though it leans toward output semantics rather than parameter syntax.

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 ('Statically scan') plus the resource ('an AI component') and enumerates exactly which source types qualify (skill, MCP server, npm/PyPI package, repo, local path, archive). The scanning scope is spelled out (supply-chain risks, dangerous capabilities, prompt-injection surfaces, exfiltration paths), which makes it unmistakable against diff_components or list_rules.

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 an explicit timing rule ('Use this BEFORE installing or trusting a component') and adds interpretive guidance on how to decide once you have results. It does not name a sibling alternative (e.g., when to reach for diff_components versus a fresh scan), so it falls short of full when/when-not/alternatives coverage.

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