WeRead Assistant

Problem

WeRead data is split across store search, shelves, chapters, highlights, thoughts, and public reviews. When an agent receives a request like “check my notes in this book,” it may be unclear which endpoint to call, how to flatten parameters, and what a returned field actually means. This skill wraps WeRead assistant workflows around api_name-based POST calls for retrieval, disambiguation, and interpretation.

How it works

• Capability map: organized around book search, book details, shelf, reading stats, notes and highlights, popular chapter highlights, book reviews, and recommendations. For a book title, it typically calls /store/search first to obtain bookId, then continues with related endpoints.
• Call convention: use POST with application/json; keep api_name, skill_version, and business parameters at the same top level instead of nesting them under params.
• Field handling: the skill expects the relevant documentation to be read before interpreting responses; Unix timestamps are shown as YYYY-MM-DD, reading duration is converted from seconds to hours and minutes, and lists emphasize title, author, and rating where available.
• Deep links: when bookId, chapterUid, and range are available, it can construct WeRead App links to open the book, chapter, highlight, or thought in context.

Boundaries

It depends on WEREAD_API_KEY and returns data for the authenticated user; if the key is missing, the agent should ask the user to configure it. It is intended for querying WeRead data within an authorized account, not for modifying book content, publishing new reviews, or replacing a local knowledge base. Pagination, shelf counting, and highlight statistics should follow the field definitions in the relevant documentation rather than guesses based on names.