Skip to main content
Glama
Sign In

Termalin

by in.termal
OverviewDiscussionsAdmin

updates_list

Read-onlyIdempotent

What is waiting to be installed on the user's servers, from Termalin's hourly check (nothing is run or installed): how many updates and security updates, the security packages by name and target version, whether the server asks for a reboot, a newer kernel installed but not yet running, and how old the package lists are. Without arguments: every server; 'host' for one, or 'tag' for a group (from hosts_list, e.g. "distro:ubuntu" or "prod"). Also the known vulnerabilities (CVEs) in what is installed, matched daily: severity, the fixed version, and whether it is known to be exploited (CISA KEV); 'cve' answers "which servers have CVE-...". Linux servers (apt, dnf, apk). Use it before planning updates; installing is a separate step the user agrees to.

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": "updates_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
cveNoOnly the servers with this vulnerability, e.g. "CVE-2024-6387"
tagNoInstead of 'host': every server with all of these tags or groups
hostNoServer id or exact name from hosts_list (default: all servers)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds real context beyond them: data provenance (hourly check, daily CVE matching), the fact that nothing is executed, coverage limited to Linux package managers, and the full set of reportable fields including CISA KEV exploitation status. No contradictions with the annotations.

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?

It is front-loaded with what the tool reports before drilling into filtering modes, and nearly every clause carries information. The middle section is a dense run-on, though the parentheticals and quoted examples keep it navigable.

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?

There is no output schema, so the description carries the burden of describing results, which it does thoroughly (counts, package names and target versions, reboot/kernel state, list age, CVE severity, fixed version, KEV flag). Platform limits and the non-mutating nature are also covered, so an agent can call it correctly.

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 adds value by explaining the default when no arguments are given, the meaning of the 'cve' mode ('which servers have CVE-...'), and that 'tag' matches all of the given tags/groups drawn from hosts_list. It does not clarify precedence if host and tag or cve are combined.

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?

The description names a specific resource and scope: pending updates, security packages with target versions, reboot flags, pending kernels, package-list age, and matched CVEs. It also states the platforms (apt, dnf, apk) and explicitly says nothing is run or installed, which separates it from ssh_exec / job_start siblings.

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?

It states when to use it ('Use it before planning updates') and where its responsibility ends ('installing is a separate step the user agrees to'). It also gives the call patterns: no arguments = every server, 'host' for one, 'tag' for a group, and the advice to get tags from hosts_list with concrete examples.

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

All Termalin toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources