Registers a new superadmin account with username and password; requires confirm=true to submit the registration request.
POST /api/auth/register Register as superadmin Tags: Auth Controller
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| confirm | No | Подтверждение выполнения не-GET операции. Без confirm:true возвращается превью запроса (метод, URL, тело) и запрос не отправляется (см. MCP_CONFIRM). |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose that this creates a superadmin-level account (a privileged mutation), whether it requires prior authentication, rate limits, or that the confirm parameter must be set to actually execute rather than preview. The 'superadmin' hint is the only behavioral signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short but poorly structured: it front-loads a raw HTTP endpoint and a controller tag, both of which are low-value for an agent choosing a tool. Only 'Register as superadmin' carries real meaning, and the rest is filler that does not help the agent decide or invoke correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a privileged mutation tool with nested body parameters, a non-obvious confirm gate, and no annotations or output schema. The description fails to explain the superadmin creation implications, the confirm preview behavior (critical for correct invocation), or any auth/permission requirements. It is inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the schema documents username and confirm (with a detailed Russian description of the preview/confirm mechanism), but the password field only has a regex pattern, not a description. The description adds nothing about parameters, so it does not compensate for the coverage gap. Baseline 3 is appropriate given half the parameters are self-documenting in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Register as superadmin') plus the HTTP endpoint POST /api/auth/register. This clearly distinguishes it from sibling auth tools like auth_login and auth_oauth2_authorize, though the raw HTTP line and 'Tags: Auth Controller' add noise rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a registration context but provides no explicit when-to-use or when-not-to-use guidance versus alternatives like auth_login or auth_get_status. The 'Register as superadmin' phrasing hints at a privileged operation, but there is no stated prerequisite or condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.