Skip to main content
Glama
kristianedlund

hardcover-mcp

by kristianedlund
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

set_list

Destructive

Create a list (omit id; name required) or change the name, description, or privacy of a list you own (pass id plus at least one field; only the fields you pass are overwritten). Creating twice makes two lists, so check get_list first.

Instructions

Create a list (omit id; name required) or change the name, description, or privacy of a list you own (pass id plus at least one field; only the fields you pass are overwritten). Creating twice makes two lists, so check get_list first. Returns the list's id, name, slug, description, and privacy. Does not change which books are on it: use set_list_book for that.

Input Schema

NameRequiredDescriptionDefault
idNoList ID to update. Omit to create a new list.
nameNoList name (required when creating).
privacyNoWho can see it: 'public', 'followers', or 'private' (or 1, 2, 3). Default when creating: public.
descriptionNoList description.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • changedInput schema / properties / privacy / description
      Previous value: -"'public', 'followers_only', or 'private'. Default when creating: public."New value: +"Who can see it: 'public', 'followers', or 'private' (or 1, 2, 3). Default when creating: public."
  2. Addedv0.8.0

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true. Still missing is any disclosure of permission/auth requirements or what happens to fields you omit; a 3 is warranted since the annotation set already carries part of the load and the remaining gaps are real.

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?

Every sentence earns its place: mode selection is front-loaded, then the duplicate-write warning, then the return shape, then the sibling boundary. No filler and no repetition.

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?

No output schema, and the description compensates by naming the returned fields (id, name, slug, description, privacy). For a 4-param mutation with good schema coverage, nothing an agent needs to call it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents every parameter including the privacy enum values and the create default. The description mirrors the schema's own mode rules but adds no syntax or format detail beyond what structured fields already provide, so baseline 3 applies.

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?

States precise verbs and resource: create a list or change name/description/privacy of an owned list. It also explicitly names the boundary against set_list_book ('Does not change which books are on it') and against get_list, so an agent can separate it from siblings without opening schemas.

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?

Gives explicit mode-selection rules (omit id + name to create; pass id plus at least one field to update) and an explicit prerequisite ('check get_list first' because creating twice makes two lists). It also names the alternative tool for book membership, which is a clear when-not-to-use signal.

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