Skip to main content
Glama
kristianedlund

hardcover-mcp

by kristianedlund
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_user

Read-only

Get a Hardcover user's profile. With no arguments, returns your own profile (the owner of the API token) including your user id; otherwise look someone up by id, username, or name (name resolves to the top search match). Read-only.

Instructions

Get a Hardcover user's profile. With no arguments, returns your own profile (the owner of the API token) including your user id; otherwise look someone up by id, username, or name (name resolves to the top search match). Read-only. Returns bio, book/follower counts, and privacy. Optional sections: include_library (recent library entries, each with the book's community 'rating' and the user's own 'user_rating'; a private user's comes back empty unless you follow them), include_following / include_followers (who they follow / who follows them, newest first), and include_stats (your own profile only: totals per status, average rating, books read in stats_year, default this year). For activity use get_activity_feed; to follow someone use set_following. Fails if the token is missing or invalid.

Input Schema

NameRequiredDescriptionDefault
idNoHardcover user ID.
nameNoDisplay name to search for (resolves to the top match).
usernameNoHardcover username (e.g. 'adam').
stats_yearNoYear for books_read_this_year (default: current year).
follow_limitNoMax people per follow list (default 25, max 100).
include_statsNoYour own profile only: include reading statistics (default false).
library_limitNoMax library entries to return (default 10, max 50).
library_statusNoOnly library entries with this status.
include_libraryNoIf true, include recent library entries (default false).
include_followersNoInclude who follows the user (default false).
include_followingNoInclude who the user follows (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.0
    • changedInput schema / properties / library_status / description
      Previous value: -"Filter library entries by status (e.g. 'Read', 'Currently Reading')."New value: +"Only library entries with this status."
    • addedInput schema / properties / library_status / enum
      Added value: +[
+  "Want to Read",
+  "Currently Reading",
+  "Read",
+  "Paused",
+  "Did Not Finish",
+  "Ignored"
+]
  2. Changed5 schema fields changedv0.9.0
    • addedInput schema / properties / follow_limit
      Added value: +{
+  "description": "Max people per follow list (default 25, max 100).",
+  "type": "integer"
+}
    • addedInput schema / properties / include_followers
      Added value: +{
+  "description": "Include who follows the user (default false).",
+  "type": "boolean"
+}
    • addedInput schema / properties / include_following
      Added value: +{
+  "description": "Include who the user follows (default false).",
+  "type": "boolean"
+}
    • addedInput schema / properties / include_stats
      Added value: +{
+  "description": "Your own profile only: include reading statistics (default false).",
+  "type": "boolean"
+}
    • addedInput schema / properties / stats_year
      Added value: +{
+  "description": "Year for books_read_this_year (default: current year).",
+  "type": "integer"
+}
  3. Addedv0.7.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint; the description adds substantive traits beyond that: private users' libraries return empty unless followed, stats are restricted to your own profile, follow lists are newest-first, name lookups resolve to the top match, and the call fails on a missing/invalid token. These are real behavioral constraints an agent could not infer from 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.

Conciseness4/5

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

Front-loaded with the core behavior, then optional sections, then sibling routing, so it reads in priority order. It is a single dense paragraph with heavy parentheticals that could be broken into bullets, but no sentence is filler.

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?

For an 11-parameter, no-output-schema tool, the description covers return contents (bio, book/follower counts, privacy), each optional section's payload, ordering, and failure conditions. An agent has everything needed to call it correctly and interpret the result.

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%, so baseline is 3, but the description adds semantics the schema lacks: include_library explains what each entry contains (community rating vs user_rating) and the privacy caveat, include_stats is scoped to own profile only, and stats_year defaults to the current year. It leaves the limit parameters (follow_limit, library_limit) to 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?

States a specific verb and resource ('Get a Hardcover user's profile') plus the scope rule (no args = token owner, otherwise by id/username/name). It explicitly names the adjacent tools it is not (get_activity_feed, set_following), so an agent can distinguish it from siblings without opening a schema.

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 routing: default to self with no arguments, look up others by id/username/name, and 'For activity use get_activity_feed; to follow someone use set_following.' Both when-to-use and when-to-use-something-else are stated.

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