genieacs-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.3
Disambiguation5/5
Each tool targets a distinct operation: device wake-up, reboot, firmware download, parameter set/refresh/read, device search/tag, preset/provision management, and task delete/retry. No overlapping purposes, clear differentiation.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., delete_task, set_parameter, tag_device). No mixing of styles or ambiguous verbs.
Tool Count5/5
12 tools cover the core operations for TR-069 device management: device interaction, parameter handling, task management, device discovery, and configuration management. Well-scoped without being excessive.
Completeness4/5
Covers essential CRUD and lifecycle operations for devices, parameters, tasks, presets, and provisions. Minor gap: no dedicated tool to list all queued tasks, but task management tools (delete, retry) and reference to task resources partially compensate.
Average 4.5/5 across 12 of 12 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on June 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool is read-only ('without contacting the CPE', 'reads last-known values'), but the annotations set destructiveHint=true, which implies a destructive or modifying action. This is a direct contradiction between the description and the annotation, severely impacting transparency.
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?
Description is moderately concise and well-structured with clear sections. Some slight redundancy ('quickly retrieve') but overall efficient. Front-loaded with purpose.
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?
Covers purpose, usage, limitations, return format, and edge case (unread parameters not appearing). No output schema, but description sufficiently explains return. Could mention error handling or missing device, but overall complete for the tool's complexity.
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%, baseline 3. The description adds extra value by explaining comma-separated lists for parameter_path, providing concrete examples, and detailing the device_id format. This goes beyond the schema.
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 'Read specific TR-069 parameter values from the GenieACS cache for a device without contacting the CPE.' The verb 'read' and resource 'TR-069 parameter values' are specific, and the mention of 'without contacting CPE' distinguishes it from refresh_parameter.
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 states when to use (quickly retrieve known values) and when not (if fresh value needed, use refresh_parameter). Provides practical examples and limitations, guiding the agent on appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it mentions the 404 error for invalid device, case-sensitivity of tags, and lack of built-in tag listing. Aligns with destructiveHint=true and readOnlyHint=false, but lacks details on idempotency or duplicate tag behavior.
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 a single dense paragraph. While not overly long, it could benefit from bullet points or clearer separation of sections to improve scannability.
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?
The description lacks information about the tool's return value or success response. It only mentions a 404 error. For a mutating tool with no output schema, this is a notable gap in completeness.
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%, but the description enriches each parameter: explains action values ('add'/'remove'), gives device_id format and example, and provides tag string examples. Includes a full example call, adding substantial value beyond the schema.
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 tool's purpose: add or remove a tag on a CPE device in GenieACS. It distinguishes between the two actions and explains tags are used for grouping devices, differentiating from sibling tools like search_devices and manage_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use action='add' and action='remove', provides an example, and suggests using search_devices for verification. It mentions the device must exist and limitations, but does not explicitly list when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, but description focuses on search and returns, not mentioning any destructive potential. It does not contradict annotations but fails to add context about why the tool is considered destructive. Adds useful behavioral details like query syntax and default limit.
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?
Description is reasonably concise given the complexity of MongoDB query syntax, with well-organized examples and limitations. Could tighten some phrases, but overall 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?
Given no output schema, description explains return format ('JSON array of matching device documents'), covers query syntax, limit behavior, and limitations. For a search tool with 2 parameters, this is complete and actionable.
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%, baseline 3. Description adds value beyond schema with query examples, explanation of ._value auto-append, default limit behavior, and limitations. This enriches understanding of both parameters.
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 verb ('Search'), resource ('CPE devices'), and scope ('using MongoDB-style query filters'). It distinguishes from sibling tools like get_parameter or reboot_device by specifying the search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use: 'find devices by tag, manufacturer, model, firmware version, last inform time, or any other TR-069 parameter.' Provides examples and mentions limitations (no complex aggregation). Does not explicitly exclude use cases, but implicitly guides via examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and readOnlyHint=false, which the description confirms by stating it can delete presets. The description adds valuable context: changes take effect on next CPE inform, not immediately. No contradiction with 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?
The description is a single paragraph, but it is well-organized and front-loads the purpose. Every sentence contributes useful information; however, it could be slightly more concise by removing some redundancy.
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 no output schema and three parameters (two required), the description covers usage, constraints (name cannot contain dots), example, and limitations (deferred effect). It is complete for an agent to use the tool 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%, but the description enriches parameter understanding by detailing the body structure (weight, precondition, configurations) and providing a concrete example. This adds meaning beyond the schema alone.
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 tool's purpose: 'Create, update, or delete a GenieACS preset.' It explains what presets are and distinguishes itself from sibling tools (e.g., connection_request, delete_task). The verb 'manage' combined with resource 'preset' is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines when to use action='put' vs 'delete', provides an example body, and recommends viewing existing presets via genieacs://presets/list. It does not explicitly state when not to use the tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous behavior, queuing of task, and CPE contact dependency. Annotations indicate destructiveHint=true, but description does not elaborate on destruction; still, the mutation nature is clear.
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?
Well-structured with sections for purpose, usage, limitations, and example. Slightly verbose but every sentence adds value. Could be more concise.
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?
Complete for a tool with two simple parameters. Includes return value description (raw JSON), important limitations, and an example. No output schema needed; this covers the agent's needs fully.
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%, but description adds valuable context: device_id format (OUI-ProductClass-SerialNumber), where to obtain valid IDs, and multiple parameter path examples. Enhances understanding beyond schema.
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 tool requests a CPE device to report a specific TR-069 parameter via GenieACS, distinguishing it from siblings like get_parameter, set_parameter, and reboot_device. The verb 'refresh' and target 'parameter' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (need up-to-date reading) and includes limitations (asynchronous, one parameter per call, full dotted path). Does not explicitly contrast with alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: mentions syntax validation (400 error on syntax error), server-side execution sandbox with limited API, and limitations (no HTTP calls or filesystem access). This fully complements the destructiveHint annotation.
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?
Well-structured with clear sections and an example, but slightly verbose. Every sentence is informative, but could be tightened without loss of meaning.
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?
Despite lacking an output schema, the description sufficiently covers return behavior (400 error for syntax issues), side effects (storing script), and prerequisites. Provides limitations and an example, making it complete for a destructive 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?
Schema coverage is 100%, and the description adds value by clarifying that script must be raw JavaScript (not JSON) and that validation occurs on upload. Action parameter meanings are also elaborated beyond the schema.
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 creates, updates, or deletes a GenieACS provision script. The verb 'manage' is generic, but the description specifies the exact operations and resource, differentiating it from sibling tools like manage_preset which targets presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use action='put' vs action='delete', and suggests viewing existing scripts via genieacs://provisions/list before changes. However, it does not explicitly state when not to use the tool or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and non-idempotent behavior. Description adds detail on mechanism (HTTP connection request), return codes (200/504), and that it triggers a CWMP session without queuing. No contradiction with 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?
Description is multi-sentence but well-structured: purpose, usage, mechanism, returns, example, limitations. Each sentence adds value, though slight verbosity could be trimmed.
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?
Despite no output schema, description explains return values and behavior. Covers example, limitations, and what the tool does not do (queuing). Adequate for the tool's simplicity.
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 provides 100% coverage for device_id with format description. Description adds value by giving an explicit example and source for valid IDs, enhancing schema meaning.
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 'Send a connection request to wake a CPE device' and specifies context like executing pending tasks, applying presets, or forcing parameter refresh. Distinguishes from sibling tools like reboot_device or refresh_parameter by focusing on immediate contact trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (immediate contact needed). Mentions limitations (NAT, reachability) and that it does not queue a task. Could improve by explicitly stating when not to use and listing alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-idempotent behavior. Description adds specific error condition (503 during CWMP session) and limitation to pending tasks, providing valuable context beyond 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?
Concise multi-sentence structure with front-loaded purpose, followed by usage, example, and limitations. No unnecessary words.
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?
Covers all necessary aspects: purpose, usage, error handling, example, and limitations. Sufficient for an agent to use 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?
Single 'task_id' parameter is fully described in both schema and description. Description adds example and source for obtaining task IDs, enhancing usability.
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 deletes pending tasks from GenieACS queue, distinguishing it from siblings like retry_task.
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 describes when to use (cancel queued tasks), when not (completed/in-progress), and alternatives (retry_task for faulted tasks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and no readOnly, but the description adds rich behavioral context: asynchronous download, queued task, CPE fetches on next session, large files take minutes, and return value is raw JSON confirmation. This far exceeds what annotations provide.
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 detailed but front-loaded with purpose, then actionable steps, then limitations, and ends with an example. Every sentence is valuable, though it could be slightly tighter without losing 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?
Given the absence of an output schema, the description explains the return value (raw JSON confirming task queued) and provides verification guidance. It covers async behavior, file prerequisites, and includes a concrete example. Completely adequate for a 3-parameter 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?
All three parameters are fully described in the input schema (100% coverage). The description adds extra meaning: device_id format and source, file_id verification via genieacs://file/, and default behavior for filename. This adds beyond the schema.
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 states a specific verb ('push') and resource ('firmware image or configuration file to a CPE device'), and the mechanism ('GenieACS TR-069 download'). It clearly distinguishes from sibling tools like reboot_device or set_parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for OTA firmware upgrades or pushing any file) and prerequisites (file must already be uploaded to GenieACS). It also provides context on async behavior and verification. However, it does not explicitly list when NOT to use it, but that is minor given the clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description reveals that retrying clears the fault and re-queues the task on next CPE inform, adding context beyond annotations (which indicate destructive and non-idempotent). No contradiction with 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?
Description is concise with clear sentences, includes an example and limitations, but could be slightly shorter by removing redundant phrases. Still well-structured.
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?
Given single parameter, no output schema, and annotations covering safety, the description fully covers purpose, usage, parameter semantics, and limitations. No gaps.
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?
Parameter schema has 100% coverage, but description adds value by explaining task_id is the _id field, how to obtain it, and includes an example. Schema alone doesn't provide this context.
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 'Retry a faulted task in GenieACS' with specific verb and resource, and distinguishes from sibling tools like delete_task and connection_request.
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 (after a faulted task), when not to (non-faulted tasks), and provides context to obtain task_id and check fault information via genieacs://faults/{id}.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive intent. The description adds crucial behavioral details: the reboot is asynchronous, queued on ACS, no confirmation of actual reboot, and returns raw JSON. This goes beyond what annotations provide.
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?
Description is well-structured: purpose first, then usage, then limitations, then example. Every sentence is informative and necessary.
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?
Given the tool's complexity (async reboot, no output schema), the description covers all essential aspects: purpose, prerequisites, return value, and limitations. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The one parameter (device_id) is fully described in the schema with format and examples. The description reinforces this with a concrete example and instructions to obtain valid IDs.
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 ('Reboot a CPE device') through a specific system (GenieACS TR-069 ACS). It distinguishes from sibling tools like connection_request or get_parameter by specifying the ACS context and the device scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage scenarios (after config change, firmware update, recovery) and instructs to discover valid IDs via another resource. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations lack behavioral details, but the description fully explains: task queuing, immediate execution via connection request, queuing if unreachable, and fault behavior for read-only parameters. No contradiction with 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?
The description is a single paragraph of 8 sentences, each sentence adds unique value. It is front-loaded with the main purpose, followed by examples, types, limitations, and alternatives. No wasted words.
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?
Given no output schema, the description explains the return value ('raw ACS JSON response confirming the task'). It covers limitations, prerequisites, and error scenarios. Everything an agent needs is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds critical meaning: JSON array of tuples format, example, list of valid xsd types, and inference if type omitted. This goes beyond the schema's parameter descriptions.
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 tool's purpose: 'Set one or more TR-069 parameter values on a CPE device through GenieACS.' It specifies the verb (set), resource (parameter values on CPE), and distinguishes it from sibling tools like get_parameter or reboot_device.
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 states when to use (change device configuration like WiFi SSID) and provides warnings: CPE must be reachable, read-only parameters will fault. Suggests alternatives: 'Use refresh_parameter or genieacs://device/{id} first to discover valid parameter paths.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![genieacs-mcp MCP server](https://glama.ai/mcp/servers/GeiserX/genieacs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/GeiserX/genieacs-mcp)

Score Badge

Copy to your README.md:

[![genieacs-mcp MCP server](https://glama.ai/mcp/servers/GeiserX/genieacs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/GeiserX/genieacs-mcp)

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/GeiserX/genieacs-mcp'

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