Skip to main content
Glama
rollecode

Audiobookshelf MCP server

by rollecode

delete_users_by_id

DestructiveIdempotent

Delete a user from Audiobookshelf by providing their unique ID, removing their access to the server.

Instructions

Delete api users.

DELETE /api/users/{id}

Args: id: Path parameter. body: Request payload. Read the matching GET or the /schema endpoint first to see the fields this resource expects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
bodyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare `destructiveHint: true`, so the destructive nature is known. The description states 'Delete' which matches. It adds an operational hint about reading the GET/schema endpoint for body fields, which is more about parameter prep than behavior. It doesn't disclose side effects (e.g., whether associated data is removed, if the operation is irreversible, or auth requirements). With annotations covering the main safety profile, the description provides minimal extra behavioral context but does not contradict the 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 concise: a one-line action, the endpoint, and two bulleted args. The core purpose is front-loaded, and each sentence serves a clear function. No filler or redundant content. It's efficient and well-structured for an agent to parse quickly.

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?

For a simple delete operation with an output schema (present) and annotations, the description is nearly complete. It covers what the tool does, the endpoint, and how to handle parameters (including where to find body field details). It doesn't explain error handling or return values, but the output schema covers those. With annotations declaring destructive and idempotent, the description is sufficient for an agent to call it correctly, though it could add a note about irreversibility or auth requirements.

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 description coverage is 0%, so the description must compensate. It explains `id` as a path parameter, and `body` as a request payload, advising to read the GET or /schema endpoint for field details. This adds meaning beyond the raw schema (which only gives type and defaults). It does not explicitly mention that `id` is required (though the schema marks it required) or that `body` is optional, but those are in the schema. The guidance to consult the schema is practical and helpful.

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 clearly states the action ('Delete') and the resource ('api users'), and the endpoint `/api/users/{id}` specifies a single user. It distinguishes from siblings like `delete_authors_by_id` or `delete_api_keys_by_id` by targeting users, though it doesn't explicitly say 'delete a single user by ID' — that's implied by the path parameter. Clear enough for an agent to identify its purpose.

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 other delete tools (e.g., `delete_authors_by_id`). There is no mention of preconditions, exclusions, or when to prefer alternatives. The only instruction relates to preparing the `body` parameter (read GET or /schema), which is about parameter usage, not usage context. The description does not state 'use this to delete a user' or any conditions around it.

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