Skip to main content
Glama
Apache AIops

Apache AIops

apache_modules

Read-only

Lists loaded Apache modules to inspect enabled capabilities and diagnose missing-module or configuration issues.

Instructions

[READ] List Apache's loaded modules.

Input Schema

NameRequiredDescriptionDefault
targetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.7/5.0
Behavior2/5

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

readOnlyHint=true already tells the agent this is a safe read, and the "[READ]" prefix merely restates that annotation. Beyond it, the description discloses nothing about what a module entry looks like, whether output is per-target, or how the result is scoped.

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?

A single short sentence, front-loaded with the verb and resource, with no filler. It is efficient but the brevity borders on under-specification given the undocumented target parameter.

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?

There is no output schema and no annotation coverage beyond readOnlyHint, so the description carries the burden of explaining the single target parameter and the shape of the module list. Neither is addressed, leaving an agent unable to call it correctly beyond guessing.

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?

The schema has one optional parameter, target, at 0% description coverage, and the description says nothing about it — not whether it names a host, a config file, or a server instance. With low coverage the description is expected to compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (List) and resource (Apache's loaded modules), so the operation is unambiguous. The word "loaded" implicitly distinguishes it from sibling apache_compiled_modules, but the description never names that sibling to make the contrast explicit.

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?

There is no when-to-use guidance, no prerequisites, and no mention of when an agent should prefer apache_compiled_modules or apache_static_directives instead. Usage is only inferable from the resource name, not stated.

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