Skip to main content
Glama
gxxHuang
by gxxHuang

Add Pppoe Account

add_pppoe_account

Create a PPPoE account on an iKuai router by specifying username and password, with optional bandwidth limits and comments.

Instructions

添加 PPPoE 账号

Input Schema

NameRequiredDescriptionDefault
commentNo
ip_typeNoauto
passwordYes
usernameYes
upload_kbpsNo
download_kbpsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

D1.5/5.0
Behavior1/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure, and it discloses nothing. For a mutation tool it never states that it creates persistent state, what happens on duplicate usernames, or any auth/permission requirement.

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

Conciseness2/5

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

It is short with no filler, but this is under-specification rather than conciseness — a five-character phrase cannot be considered well-structured for a six-parameter creation tool.

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

Completeness1/5

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

With no annotations, 0% parameter coverage, and a mutation that creates an account, the description omits everything an agent needs beyond the name. The existence of an output schema excuses it from explaining return values, but nothing else is covered.

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?

Six parameters with 0% schema description coverage: username, password, comment, ip_type, upload_kbps, download_kbps. The description explains none of them, leaving the agent with no idea what ip_type values (e.g. 'auto') mean or what the kbps fields control.

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

Purpose2/5

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

The description '添加 PPPoE 账号' is a direct Chinese restatement of the tool name and English title 'Add Pppoe Account', adding no information an agent doesn't already have from the identifier. It does convey verb+resource, but that is pure tautology rather than added clarity.

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 add a PPPoE account versus using siblings such as add_vpn_account, add_admin_account, or checking list_pppoe_accounts first. No mention of prerequisites (e.g. that the PPPoE server must be enabled via toggle_pppoe_server) or how this differs from list_pppoe_accounts / delete_pppoe_account.

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

Deploy Server

Other Tools