Tool reference

Secronyx exposes system state to AI clients as MCP tools. This page lists all 661 of them. It is generated by gen-tools.sh, which builds the server, starts it over stdio with --enable-sensitive and no --scopes restriction, sends initialize followed by tools/list, and renders what the server returns. Scope membership is obtained the same way, by starting the server once per scope with --scopes <scope>; the command-line flag tables are read from the source of cmd/secronyx. Tool names, descriptions and argument schemas are therefore the server's own words, and the tables are in the server's registration order. If a tool changes, rerun the script rather than editing this page.

The first sections explain how tools are listed, called, scoped and run from the shell. The scope sections that follow are the reference proper. Related pages: JSON-RPC API, Scopes and authorization, Command line, Configuration reference, and the documentation home.

How the server exposes tools

Secronyx speaks JSON-RPC 2.0 over stdio or HTTP. The protocol version it reports from initialize is 2024-11-05, and the only capability it advertises is tools. The request methods it accepts are initialize, initialized, tools/list, tools/call and ping; any other method returns error code -32601 (Method not found). A message without an id is a notification and gets no reply.

tools/list returns the whole inventory in one response. There is no cursor and no pagination, and the server answers it whether or not initialize has been sent. On the stdio transport, and on HTTP when no identity has been authenticated, the list is every registered tool. When the HTTP transport has authenticated the caller, the list is filtered to the tools whose scope the caller's grants cover.

tools/call takes {"name": "<tool>", "arguments": {...}}. Three outcomes are possible:

• Success. The result is {"content": [{"type": "text", "text": "<JSON>"}]}. Every tool on this page returns its data as one text item holding the collector's result serialised as JSON with two-space indentation.
• Collector failure. The result is still a tool result, not a JSON-RPC error. It carries "isError": true and one text item of the form Error: <message>.
• Oversized result. When the text exceeds the per-call cap it is replaced by an error result whose text is Error: result too large: <n> bytes exceeds the <cap> byte cap; narrow the query (limit, lines, filters). The cap defaults to 4 MiB (DefaultMaxResultBytes = 4 << 20) and is set with --max-result-bytes; a value below 1 KiB is raised to 1 KiB.

Two JSON-RPC errors are specific to tools:

• -32602 Tool not found, with data set to the requested name. A tool that exists in the source but was excluded at registration, for example a sensitive tool when --enable-sensitive is off, is reported exactly like a tool that never existed.
• -32003 Forbidden, with data of the form tool "<name>" requires scope "<scope>". The HTTP transport returns this when the authenticated caller's grants do not cover the tool's scope.

Every tools/call, whether it succeeds, fails, is denied or names an unknown tool, is written to the audit log with the tool name, arguments, identity, client IP, duration and outcome. See Audit logging.

The inputSchema on each tool is advisory. The server hands arguments to the handler without validating them against the schema; handlers read the arguments they need, take integers from JSON numbers, and fall back to their own defaults when an argument is absent. get_capabilities, for example, inspects PID 1 when pid is omitted even though its schema marks pid as required. Read the Required column below as "the tool is meaningless without it", not as "the server rejects the call without it".

A complete exchange over stdio, one JSON object per line:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"example","version":"0"}}}
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"get_uptime","arguments":{}}}

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{}},"serverInfo":{"name":"secronyx","version":"dev"}}}
{"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"{\n  \"boot_time\": \"2026-08-27T23:55:58.640118524+01:00\",\n  \"uptime\": 1761127750000000,\n  \"uptime_str\": \"20 days, 9 hours, 12 minutes, 7 seconds\",\n  \"timestamp\": \"2026-09-17T09:08:06.390121094+01:00\"\n}"}]}}

Scopes and registration

Every tool belongs to exactly one scope, fixed at registration in internal/mcp/tools*.go. The scope decides two things: whether the tool is registered at all, and which identities may call it over HTTP.

Registration is controlled by two settings, read once at startup before any tool is registered:

• --scopes <list>, or the SECRONYX_SCOPES environment variable: a comma-separated list of scopes to register. Empty, the default, means every scope except sensitive.
• --enable-sensitive, or SECRONYX_ENABLE_SENSITIVE=1: permits registration of the sensitive scope. It is required even when sensitive appears in --scopes; --scopes sensitive on its own registers nothing.

A tool outside the policy is never registered, so it is absent from tools/list and returns Tool not found from tools/call on every transport. At startup the server logs what it dropped, for example Scope policy: 644 tools not registered (sensitive=false, scopes="core,logs"), and logs WARNING: sensitive-scope tools are enabled when the sensitive scope is on. With the defaults the inventory is 630 tools; with --enable-sensitive it is 661.

On the HTTP transport an identity's grants are matched against the tool's scope as the bare scope name, as mcp:tools:<scope>, or as the wildcard *; the bare mcp:tools grants nothing. The scopes that are actually registered are advertised as scopes_supported in the protected-resource metadata served at /.well-known/oauth-protected-resource. How identities obtain grants is covered in Authentication and Scopes and authorization.

The 19 scopes are:

Platform support

Secronyx is built for Linux, macOS and Windows, and every tool is registered on every platform. The Platform column in the tables records only what the tool's own description states: Windows, Linux, macOS, a combination, or a slow on macOS warning. A blank entry means the description does not restrict the tool; it does not promise data on every platform.

On a platform a tool does not support, the call still succeeds. The collector returns an empty result, usually with an error field saying why, and tools/call reports it as an ordinary result without isError. Two examples captured on a Linux host, from get_iis_sites and get_macos_applications:

{"sites": [], "count": 0, "error": "IIS is only available on Windows", "timestamp": "2026-09-17T09:06:05.932723298+01:00"}

{"applications": [], "count": 0, "timestamp": "2026-09-17T09:08:09.932945802+01:00"}

The slow on macOS marker repeats a warning that the description itself carries: those tools call log show. The descriptions use three phrasings, kept verbatim in the Description column: Note: May be slow on macOS (uses log show), WARNING: High latency on macOS (1+ minutes, uses log show) and, for get_incident_triage_snapshot and get_security_posture_snapshot, WARNING: High latency on macOS (may take 1-5 minutes due to log queries). A few Windows tools state requires admin in their description; that phrase is kept verbatim too.

Calling a tool from the command line

secronyx --query <name> runs one tool's collector and prints the result, bypassing MCP entirely. It is the quickest way to see what a tool returns on a particular host:

secronyx --query get_cpu_info --json
secronyx --query get_capabilities --pid 1 --json
secronyx --query get_service_log_view --service nginx --lines 200 --json
secronyx --query get_registry_key --hive HKLM --regpath 'SOFTWARE\Microsoft\Windows NT\CurrentVersion' --json

How this differs from a tools/call:

• No scope policy. --query builds its own in-process registry with every scope enabled, sensitive included, so sensitive tools run without --enable-sensitive and --scopes has no effect. It runs the same handler, with the same schema, that tools/call runs. Anyone who can run the binary as a user with the relevant file permissions can read what those tools read; see Security model.
• No audit event. Audit logging is initialised exactly as for the server (pass --no-audit to skip that), but the tool-call event is written by the MCP tools/call handler, which --query does not pass through. Redaction, by contrast, is applied inside the collectors, so --redact (on by default) and --no-redact govern --query output as they govern MCP results; see Redaction.
• Output format. With --json the result is printed as indented JSON and nothing else. Without it, a line === <name> === and a blank line precede the same JSON. An unknown name prints Error: unknown query '<name>' and Use --help to see available queries. to stderr and exits with status 1; a collector error prints Error: <message> and exits 1. Startup warnings such as WARNING: audit logging is DISABLED go to stderr.
• Arguments come from --args, a JSON object in the same shape as the arguments of a tools/call, and from shorthand flags that each set one argument. A shorthand flag is passed only when it is given on the command line, and it overrides the same argument in --args; --args that is not a JSON object prints an error beginning Error: --args must be a JSON object and exits 1. The first table lists the flags; the second lists the tools whose schema declares the argument each shorthand flag sets. Any argument without a shorthand flag is passed through --args, for example secronyx --query get_processes --args '{"limit":25}' --json.

Every one of the 661 tools can be run with --query, under its tool name.

Reading the tables

Each scope below has a tools table and, where any tool takes arguments, an arguments table.

• Tool: the name to pass in tools/call and to --query.
• Description: the description string the server returns, verbatim.
• Platform: the restriction stated in that description, if any (see above).
• Argument, Type, Required, Default: taken from inputSchema.properties and inputSchema.required. Where a property carries an enum, or a minimum or maximum, the permitted values or bounds are appended to the description in parentheses. A range that appears only in the description text is enforced, if at all, by the handler.

Scope: core

Core metrics: CPU, memory, disk, network interfaces, processes (instant and sampled), uptime and temperature. 8 tools. Over HTTP an identity needs the grant core, mcp:tools:core or * to list or call them; --scopes core registers only this scope.

Arguments

Scope: logs

Log access: systemd journal, syslog, kernel log, application logs, the Windows Event Log, PowerShell script blocks, AppArmor, SELinux and seccomp audit events and macOS unified log faults. 9 tools. Over HTTP an identity needs the grant logs, mcp:tools:logs or * to list or call them; --scopes logs registers only this scope.

Arguments

Scope: hooks

System hooks: scheduled tasks and cron, startup items, systemd services, kernel modules and drivers, DNS, routes, firewall rules, listening ports, ARP, network statistics, mounts, disk I/O, open files and inodes, plus event history (socket, file and hardware events, the event monitor and the NTFS USN journal). 20 tools. Over HTTP an identity needs the grant hooks, mcp:tools:hooks or * to list or call them; --scopes hooks registers only this scope.

Arguments

Scope: hardware

Hardware: platform summary, USB, PCI and block devices, batteries, fans, firmware, serial ports, CPU vulnerabilities and topology, PCIe, Thunderbolt, IOMMU, EDAC, sensors and GPU compute processes, SMBIOS, chassis, memory layout, ACPI tables, CPU features, device firmware, Intel ME, security MSRs and macOS IOKit, T2 and displays. 38 tools. Over HTTP an identity needs the grant hardware, mcp:tools:hardware or * to list or call them; --scopes hardware registers only this scope.

Arguments

Scope: resources

Process and resource detail: IPC, namespaces, cgroups, capabilities, the process tree, zombie, blocked and orphan processes, file descriptors, threads and priorities, pipes and the physical memory map. 13 tools. Over HTTP an identity needs the grant resources, mcp:tools:resources or * to list or call them; --scopes resources registers only this scope.

Arguments

Scope: state

System state: virtualisation, time zone and NTP, core dumps, power, NUMA, login sessions and history, groups and password policy, kernel parameters, fstab, locale, systemd deep-dive, macOS administration, crash and panic reports, CUPS, container detail, LXD/Incus and cloud instance metadata. 57 tools. Over HTTP an identity needs the grant state, mcp:tools:state or * to list or call them; --scopes state registers only this scope.

Arguments

Scope: software

Software inventory: system and language package managers, lock files, SBOM output, vulnerability lookups, containers, developer tools, language runtimes, web servers and database servers, browser and editor extensions, macOS package receipts, Portage and RPM file lists. 124 tools. Over HTTP an identity needs the grant software, mcp:tools:software or * to list or call them; --scopes software registers only this scope.

Arguments

Scope: triage

Triage and summary queries: OS profile, service manager, cloud environment, recent reboots, failures and critical events, security basics and combined incident and posture snapshots. 25 tools. Over HTTP an identity needs the grant triage, mcp:tools:triage or * to list or call them; --scopes triage registers only this scope.

Arguments

Scope: windows

Windows enterprise features: registry, DCOM, IIS (sites, pools, modules, ASP.NET, FTP, ARR and request filtering), Active Directory, VSS, WMI, W32Time, reliability, system identity and boot. 127 tools. Over HTTP an identity needs the grant windows, mcp:tools:windows or * to list or call them; --scopes windows registers only this scope.

Arguments

Scope: enhanced

Enhanced diagnostics: GPU, container runtimes and workloads, Kubernetes node info, WSL, and kernel performance counters (scheduler, softirq, memory compression, PSI, hugepages, OOM, clock sources). 27 tools. Over HTTP an identity needs the grant enhanced, mcp:tools:enhanced or * to list or call them; --scopes enhanced registers only this scope.

Arguments

Scope: report

System reports: parallel collection of many tools into a single report document. 2 tools. Over HTTP an identity needs the grant report, mcp:tools:report or * to list or call them; --scopes report registers only this scope.

Arguments

Scope: storage

Storage deep dive: SMART, I/O latency, volumes, LVM, ZFS, RAID, Btrfs, XFS, LUKS, quotas, TRIM, schedulers, NFS, Samba, autofs, file locks and log directory usage. 25 tools. Over HTTP an identity needs the grant storage, mcp:tools:storage or * to list or call them; --scopes storage registers only this scope.

Scope: security

Platform security controls: Windows (Defender, firewall, BitLocker, AppLocker, WDAC, Credential Guard, UAC, audit policy), macOS (FileVault, Gatekeeper, SIP, XProtect, pf, MDM) and Linux (auditd, lockdown, sysctl, MAC, PAM, polkit, setuid, fail2ban); Windows persistence, autoruns, security products and EDR sensors; file, process and launch-binary integrity and signatures; trusted roots; macOS security controls; and container and Docker daemon security. 87 tools. Over HTTP an identity needs the grant security, mcp:tools:security or * to list or call them; --scopes security registers only this scope.

Arguments

Scope: network

Network intelligence: connection tracking, DNS, firewall detail, Wi-Fi, connectivity probes, proxy and hosts configuration, IPv6, bonding, DHCP, NetworkManager and netplan, offload and error statistics, LLDP and traffic control, the protocols and services databases and the Wi-Fi scan cache. 29 tools. Over HTTP an identity needs the grant network, mcp:tools:network or * to list or call them; --scopes network registers only this scope.

Arguments

Scope: analytics

Analytics and trends: historical metrics, anomaly detection, capacity forecasting and trend analysis. 4 tools. Over HTTP an identity needs the grant analytics, mcp:tools:analytics or * to list or call them; --scopes analytics registers only this scope.

Arguments

Scope: alerts

Automation and alerting: alert status, remediation suggestions and runbook recommendations. 3 tools. Over HTTP an identity needs the grant alerts, mcp:tools:alerts or * to list or call them; --scopes alerts registers only this scope.

Scope: compliance

Security and compliance: security scan, framework compliance checks, forensic snapshot, audit trail and hardening recommendations. 5 tools. Over HTTP an identity needs the grant compliance, mcp:tools:compliance or * to list or call them; --scopes compliance registers only this scope.

Arguments

Scope: consumer

Consumer and workstation diagnostics: Bluetooth, audio, printers, displays, Windows Update and Defender status, crashes and minidumps, boot timing, VPN, activation, System Restore, Appx packages, power plans, startup impact, fonts, Internet Explorer extensions, browser plug-ins and URL scheme handlers. 27 tools. Over HTTP an identity needs the grant consumer, mcp:tools:consumer or * to list or call them; --scopes consumer registers only this scope.

Scope: sensitive

Sensitive data: authentication logs, environment variables (system and per-process), user accounts, sudo and SSH configuration, MAC status, certificates and macOS TCC permissions, execution evidence (prefetch, BAM, ShimCache, UserAssist, ShellBags, Office MRU), logon sessions, process events, SSH keys and known hosts, shell history, password status, kernel keys, DNS cache, container environments and print jobs. Opt-in at registration. 31 tools. Over HTTP an identity needs the grant sensitive, mcp:tools:sensitive or * to list or call them; --scopes sensitive together with --enable-sensitive registers only this scope.

Arguments