How do I use Apt MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Apt MCP Server list upgradable packages" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Apt MCP Server

by GdMacmillan

Overview Schema Related Servers Score Discussions

JavaScript

Local

Apt MCP Server

A TypeScript-based Model Context Protocol (MCP) server for controlling the apt package manager on Linux. Designed for integration with AI agents (e.g., Cursor, Claude Desktop, Windsurf) and developer tools, it exposes tools for installing, removing, updating, and querying apt packages using the system's native apt and dpkg binaries with sudo privileges.

Features

Install, remove, update, and query apt packages via MCP tools
Secure, passwordless sudo assumed for all operations
Input validation and robust error handling
Consistent, human-readable output for all tools
Designed for stdio transport (default for local AI agent integration)

Related MCP server: Systems Manager

Setup & Installation

Clone the repository:

git clone <your-repo-url>
cd popos-control-mcp

Install dependencies:
```
npm install
```
Build the project:
```
npm run build
```
Run the server (stdio transport):
```
npm run dev
# or
npm start
```

Note: The server assumes the user has passwordless sudo for apt operations.

Tools & API Endpoints

All tools are exposed via MCP and can be called by AI agents or clients. Each tool returns a plain text response with a summary, stdout, stderr, and logs (if any).

1. `installAptPackage`

Description: Install one or more apt packages.
Parameters:
- packages: array of package names (e.g., ["curl", "git"])
Example Input:
```
{ "packages": ["curl"] }
```

Example Output:

Result: SUCCESS
Summary: Apt install succeeded for: curl
[stdout]
...
[stderr]
...

2. `removeAptPackage`

Description: Remove one or more apt packages.
Parameters:
- packages: array of package names
Example Input:
```
{ "packages": ["curl"] }
```

Example Output:

Result: SUCCESS
Summary: Apt remove succeeded for: curl
[stdout]
...
[stderr]
...

3. `queryAptPackageStatus`

Description: Query if a package is installed, available, or upgradable.
Parameters:
- package: package name (string)
Example Input:
```
{ "package": "curl" }
```

Example Output:

Result: SUCCESS
Summary: Status for package curl: Installed=installed, Upgradable=false, Available=available
[stdout]
Package: curl
Installed: installed
Upgradable: no
Available: available

4. `updateAptPackages`

Description: Update the apt package list and upgrade all packages.
Parameters: none
Example Input:
```
{}
```

Example Output:

Result: SUCCESS
Summary: Apt update and upgrade completed successfully.
[stdout]
apt update stdout:
...
apt upgrade stdout:
...
[stderr]
...

5. `listUpgradableAptPackages`

Description: List all upgradable apt packages.
Parameters: none
Example Input:
```
{}
```

Example Output:

Result: SUCCESS
Summary: Listed upgradable packages successfully.
[stdout]
...
[stderr]
...

6. `upgradeSpecificAptPackage`

Description: Upgrade a specific apt package.
Parameters:
- package: package name (string)
Example Input:
```
{ "package": "curl" }
```

Example Output:

Result: SUCCESS
Summary: Apt only-upgrade succeeded for: curl
[stdout]
...
[stderr]
...

Example Usage

CLI (stdio transport)

You can test the server using the MCP CLI or by connecting with an AI agent (e.g., Cursor, Claude Desktop).

Node.js Example

const { Client } = require("@modelcontextprotocol/sdk/client");
const { StdioClientTransport } = require("@modelcontextprotocol/sdk/client/stdio");

const client = new Client({ name: "test-client", version: "1.0.0" });
const transport = new StdioClientTransport();

(async () => {
  await client.connect(transport);
  const result = await client.callTool("installAptPackage", { packages: ["curl"] });
  console.log(result);
})();

Error Handling & Troubleshooting

All errors are returned in a consistent format with Result: ERROR and a summary.
Common error causes:
- Invalid package name: check spelling and allowed characters
- Package not found: ensure the package exists in your repositories
- Permission denied: ensure passwordless sudo is configured
- Apt lock: the server retries once automatically, but if the error persists, wait and try again

Example error output:

Result: ERROR
Summary: Apt install failed: E: Unable to locate package notarealpackage
[stdout]
...
[stderr]
E: Unable to locate package notarealpackage

FAQ

Q: Does the server require passwordless sudo? A: Yes, all apt/dpkg commands are run with sudo and assume no password prompt.

Q: What transport does the server use? A: Stdio by default, for easy integration with local AI agents and tools.

Q: Can I use this server remotely? A: You can adapt it to use HTTP/SSE transport, but stdio is recommended for local/agent use.

Q: How do I add new tools? A: Add a new server.addTool block in src/index.ts following the existing pattern.

License

MIT

Available Tools

10 tools

autoremoveAptPackagesA

Remove packages that were automatically installed to satisfy dependencies for other packages and are now no longer needed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that packages are removed, but it does not mention side effects (e.g., whether packages are uninstalled permanently), prerequisites (e.g., need to run 'updateAptPackages' or 'removeAptPackage' first), or the outcome when no such packages exist. This is minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and directly states the tool's purpose. There is no extraneous information, and the structure is front-loaded with the action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description adequately covers what the tool does. However, it could be slightly improved by noting that it only affects automatically installed packages and is typically safe to run. Overall, it is sufficiently complete for a no-parameter utility 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?

The tool has zero parameters, and the description covers the absence of parameters implicitly. According to the guidelines, a baseline of 4 applies when there are 0 parameters, as no parameter documentation is needed.

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 clearly states that the tool removes packages which were automatically installed as dependencies and are now no longer needed. It distinguishes itself from siblings like 'removeAptPackage' which targets specific packages, and 'installAptPackage' which installs packages. The verb 'remove' and resource 'automatically installed packages' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when packages installed as dependencies are no longer needed, but it does not explicitly state when to use this tool versus alternatives like 'removeAptPackage' or 'holdAptPackage'. It lacks guidance on prerequisites or common scenarios, though the condition 'no longer needed' provides some context.

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

holdAptPackageB

Hold one or more apt packages to prevent them from being upgraded.

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as required permissions, side effects, or whether the action is reversible. For a system modification tool, this is insufficient.

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?

The description is extremely concise (one sentence, 12 words) and front-loaded. No redundant information, but could be improved by adding essential details without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description fails to cover prerequisites, error handling, or return values. It is incomplete for safe autonomous agent execution.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate but only minimally restates that packages are held. No examples, format guidance, or constraints beyond schema regex.

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 clearly states the action ('Hold') and resource ('apt packages'), and specifies the purpose ('to prevent them from being upgraded'). It effectively distinguishes from siblings like unholdAptPackage and installAptPackage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when preventing upgrades but does not explicitly state when to use this tool vs alternatives (e.g., unholdAptPackage for reversal). No context on prerequisites or consequences.

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

installAptPackageB

Install one or more apt packages using sudo.

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided. The description only mentions 'using sudo' to imply elevated privileges, but it omits behavioral details like error handling, partial install behavior, or whether it runs apt-get or apt.

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?

The description is a single sentence that is front-loaded and contains no filler. However, it could be slightly expanded without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool modifies system state, yet the description provides no information about output, error messages, or return values. Given no output schema, this is a significant gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not elaborate on the 'packages' parameter beyond the schema. With 0% schema description coverage, the tool fails to add meaning such as package name format or that multiple packages can be listed.

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 clearly states the action (install), the resource (apt packages), and the method (using sudo). It effectively distinguishes from sibling tools like remove or update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for installing packages but provides no explicit guidance on when to use versus alternatives such as upgradeSpecificAptPackage. No exclusions or prerequisites are mentioned.

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

listUpgradableAptPackagesA

List all upgradable apt packages.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description bears full burden. It does not disclose potential side effects, prerequisites (e.g., need to run update first), or behavior like requiring root privileges. For a read-only operation, the description is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with verb and resource. No wasted words; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no output schema, and simple purpose, the description is reasonably complete. It could mention return format or whether it requires an updated package list, but the context of sibling tools like updateAptPackages fills that gap.

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?

Input schema has zero parameters, and schema description coverage is 100% (trivially). Baseline score of 4 for no parameters, and description adds no further semantics needed.

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?

Description clearly states the verb 'List' and the resource 'upgradable apt packages'. It is distinct from sibling tools like installAptPackage or removeAptPackage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The context of sibling names implies its purpose, but the description lacks when-not or comparison details.

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

pingA

Check if the Apt MCP server is running.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided. The description is minimal but sufficient for a ping tool: it checks server health. It doesn't add behavioral details beyond the name, but also doesn't contradict any annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence conveying the core function with no extraneous content. Front-loaded and efficient.

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?

For a simple ping tool with no parameters, no output schema, and a straightforward purpose, the description is fully adequate. The agent can infer it returns a success or error indicating server status.

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?

The tool has zero parameters, so the description doesn't need to explain parameter meanings. Baseline of 4 applies as no additional parameter information is required.

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 'Check if the Apt MCP server is running' clearly states the verb 'check' and the resource 'Apt MCP server', distinguishing it from sibling tools focused on package management operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use versus alternatives, but it's implied that this is a connectivity test, separate from package operations. Lacks explicit when/when-not statements.

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

queryAptPackageStatusC

Query if a package is installed, available, or upgradable.

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'Query', which implies a read operation but does not explicitly confirm it is non-destructive, mention required permissions, or describe any side effects. This is insufficient for a tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise at one sentence, which is appropriate for a simple tool, but it sacrifices completeness. It does not include parameter details or usage context, making it marginally adequate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks critical context such as what the output looks like (no output schema), how to interpret the statuses, and when to use this tool versus sibling tools. For a simple tool it is incomplete, leaving the agent with insufficient information to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0% for the single 'package' parameter, and the description adds no extra information about the parameter's format, constraints, or allowed values beyond what the schema provides. The description does not compensate for the lack of schema documentation.

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 uses a specific verb 'Query' and clearly states the resource 'package status' (installed, available, upgradable). It distinguishes the tool from sibling tools that perform actions like install, remove, or hold packages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking package status but does not provide explicit when-to-use guidance, exclusions, or mention of alternative tools like listing upgradable packages. The usage context is implied by the verb 'query'.

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

removeAptPackageB

Remove one or more apt packages using sudo.

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose all behavioral traits. It mentions 'using sudo' (privilege escalation), but omits other details like whether it prompts for confirmation, handles missing packages, or removes dependencies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It efficiently conveys the core action and usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple removal tool with one parameter and no output schema, the description is adequate but lacks necessary context like how to safely use it or differentiate from autoremoveAptPackages.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description should add meaning to the 'packages' parameter. It only restates 'one or more apt packages' from the schema, without explaining naming conventions or validation beyond the pattern.

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 clearly states the action (remove), resource (apt packages), and method (using sudo), distinguishing it from sibling tools like installAptPackage or queryAptPackageStatus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives (e.g., autoremoveAptPackages, unholdAptPackage) or any prerequisites. No exclusions or contexts are mentioned.

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

unholdAptPackageB

Unhold one or more apt packages to allow them to be upgraded again.

ParametersJSON Schema

Name	Required	Description	Default
`packages`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states the primary effect (unhold) without disclosing prerequisites (e.g., root permissions), reversibility, error behavior, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no extraneous information. It is appropriately concise and front-loaded with the key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the basic purpose. However, it lacks behavioral context (e.g., permissions, idempotency) that would be helpful for a complete picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not add meaning beyond the schema. It repeats 'one or more apt packages' which is already evident from the schema's array type and required field.

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 clearly states the action ('Unhold'), resource ('apt packages'), and purpose ('allow them to be upgraded again'). It effectively distinguishes from sibling tools like holdAptPackage and upgradeSpecificAptPackage by specifying the opposite action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when packages are held and need to be upgraded, but it does not explicitly state when to use this tool versus alternatives like holdAptPackage or when not to use it (e.g., if packages are not held).

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

updateAptPackagesB

Update the apt package list and upgrade all packages using sudo.

ParametersJSON Schema

Name	Required	Description	Default
`allowDowngrades`	No	Allow package downgrades during upgrade (e.g., when kernel transitions require it). Default: false.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations; description mentions sudo but fails to disclose risks of full upgrade, potential downtime, or error behavior for a destructive operation.

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?

Single, efficient sentence directly stating the action; no wasted words but lacks structure such as warnings or usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, the description is mostly complete but missing behavioral context like operation duration and success/failure reporting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the sole parameter; description adds no additional meaning beyond the schema's description.

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?

Clearly states the tool updates package list and upgrades all packages with sudo, distinguishing it from sibling tools like upgradeSpecificAptPackage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings like upgradeSpecificAptPackage or autoremoveAptPackages; no prerequisites or warnings.

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

upgradeSpecificAptPackageC

Upgrade a specific apt package using sudo.

ParametersJSON Schema

Name	Required	Description	Default
`package`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'sudo', implying privilege escalation, but does not detail other important behaviors such as whether the upgrade is non-interactive, what happens if the package is not installed, or if dependencies are updated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (6 words), which is good for readability. However, it sacrifices necessary detail, making it under-specified. A slightly longer description with key behavioral notes would be more effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool, the description should cover basic behavior like error conditions and return values. It does not mention output or potential issues, leaving the agent uninformed. The absence of output schema increases the need for description completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 1 parameter with 0% coverage in the description. The description adds no meaning beyond what the schema provides (package name). It does not explain the format, constraints, or purpose of the parameter.

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 clearly states the action ('upgrade'), the target ('specific apt package'), and the method ('using sudo'). It distinguishes this tool from siblings like installAptPackage or removeAptPackage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives or when not to use it. Siblings like installAptPackage or updateAptPackages are not mentioned, leaving the agent without context for appropriate invocation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv1.0.0May 26, 2026
- First observedautoremoveAptPackages
- First observedholdAptPackage
- First observedinstallAptPackage
- First observedlistUpgradableAptPackages
- First observedping
- First observedqueryAptPackageStatus
- First observedremoveAptPackage
- First observedunholdAptPackage
- First observedupdateAptPackages
- First observedupgradeSpecificAptPackage

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool addresses a distinct apt operation—install, remove, update, upgrade, hold, unhold, autoremove, list upgradable, query status, and server ping—with no functional overlap.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern (e.g., installAptPackage, removeAptPackage), but 'ping' breaks the convention by lacking a noun component.

Tool Count5/5

10 tools cover the essential apt lifecycle operations without superfluous extras, fitting the scope of an apt package management server perfectly.

Completeness4/5

Core operations like install, remove, upgrade, update, hold/unhold, autoremove, and status query are present; only minor gaps like 'purge' or 'search' are missing, which are not critical for typical workflows.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

DepScope A
dev.depscope
Package intelligence MCP for AI agents — 22 tools, 19 ecosystems, AGPL SDK, free.
Security Developer Tools
222
IFTTT MCP serverOAuth
com.ifttt
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
App Automation
1
CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
SuperlistOAuth
io.github.superlistapp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Project Management Workplace & Productivity
2

Related MCP Servers

mcp-remote-agent
File Systems Shell Access Command Line
knownothing20
A
license
Not graded
quality
B
maintenance
Enables AI agents to remotely read/write files and execute commands on Linux servers via MCP protocol.
Updated a month ago (2026-08-02 01:39 UTC)
4
MIT
Systems Manager
OS Automation Shell Access
Knuckles-Team
A
license
Not graded
quality
A
maintenance
Enables AI agents to manage system updates, application installations, and remote host orchestration through MCP tools.
Updated 9 days ago (2026-08-28 18:39 UTC)
3
MIT
linux-mcp-server
Shell Access Command Line OS Automation
szoran53
F
license
Not graded
quality
D
maintenance
An MCP server for managing Ubuntu/Linux systems, enabling AI assistants to execute commands, manage services, files, logs, and packages via local or SSH connection.
Updated 5 months ago (2026-04-02 15:45 UTC)
-
Linux System MCP Server
Shell Access OS Automation File Systems
dgpl-mcps
A
license
A
quality
B
maintenance
Enables AI agents to interact with the Linux desktop through desktop notifications, interactive dialogs, shell command execution, and privileged command execution.
Updated a month ago (2026-08-10 09:53 UTC)
1
21
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GdMacmillan/apt-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Apt MCP Server

Features

Setup & Installation

Tools & API Endpoints

1. installAptPackage

2. removeAptPackage

3. queryAptPackageStatus

4. updateAptPackages

5. listUpgradableAptPackages

6. upgradeSpecificAptPackage

Example Usage

CLI (stdio transport)

Node.js Example

Error Handling & Troubleshooting

FAQ

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `installAptPackage`

2. `removeAptPackage`

3. `queryAptPackageStatus`

4. `updateAptPackages`

5. `listUpgradableAptPackages`

6. `upgradeSpecificAptPackage`