Skip to main content
Glama
Sign In
Cybersec Toolkit

Cybersec Toolkit

by 26zl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_tools

Read-onlyIdempotent

Discover and filter 670+ cybersecurity tools by module, install method, or installed status; page through results to identify tools before checking installation or details.

Instructions

List and filter the 670+ cybersecurity tools in the registry.

Returns the tools drawn from tools_config.json — the same registry the installer and the advisors share — with the total count, the filters still available to narrow the results, and one entry per tool. Combine the filters to scope the list: module="web" for web tools, method="pipx" for Python-packaged tools, installed_only=True for only what is on this host. Start here to discover what exists before check_installed or get_tool_info.

The full list is large (~670 entries). Pass limit/offset to page through it and keep the response small; omit them to get every matching tool.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_tools"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of tools to return. Omit for all matches.
methodNoFilter by install method. One of apt, pipx, go, cargo, gem, git, binary, docker, snap, special, source, npm.
moduleNoFilter by module (e.g. "web", "pwn", "forensics"). 18 modules available.
offsetNoNumber of matching tools to skip before returning (for paging).
installed_onlyNoIf true, only return tools that are currently installed.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.0
    • addedInput schema / properties / limit
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Maximum number of tools to return. Omit for all matches."
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Number of matching tools to skip before returning (for paging).",
+  "type": "integer"
+}
  2. Changed2 schema fields changedv1.2.1
    • changedInput schema / properties / method / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "apt",
+      "pipx",
+      "go",
+      "cargo",
+      "gem",
+      "git",
+      "binary",
+      "docker",
+      "snap",
+      "special",
+      "source",
+      "npm"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / method / description
      Previous value: -"Filter by install method (apt, pipx, go, cargo, gem, git, binary, docker, snap, special, source, npm)."New value: +"Filter by install method. One of apt, pipx, go, cargo, gem, git,\nbinary, docker, snap, special, source, npm."
  3. First observedv1.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds real value on top: the registry provenance, the response shape (total count, remaining filter options, one entry per tool), the ~670-row size warning, and the paging remedy. That is behavioral context an agent cannot get from the structured fields.

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 with purpose, then provenance, then filtering, then paging — a logical order. There is mild redundancy between the opening '670+' count and the later 'The full list is large (~670 entries)' sentence, but each paragraph still carries distinct 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?

Five optional params, no required args, an output schema already present, and full annotation coverage — the description fills in the remaining gaps (provenance, paging strategy, sibling routing). An agent has everything needed to call this correctly on the first attempt.

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 schema already documents all five parameters; the description goes beyond it by showing usage patterns for module, method, and installed_only and by explaining why limit/offset matter (keeping responses small on a ~670-entry list). It does not add syntax detail the schema lacks, so it sits just above the baseline rather than at the top.

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 with scale ('List and filter the 670+ cybersecurity tools in the registry') and names the backing source (tools_config.json shared with installer and advisors). It also distinguishes itself from siblings by positioning itself as the discovery entry point before check_installed or get_tool_info.

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?

Explicitly says when to use it ('Start here to discover what exists before check_installed or get_tool_info') and names the alternatives. It gives concrete filter recipes (module="web", method="pipx", installed_only=True) so an agent can scope without guessing.

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