Post an annotation on a book you have purchased. Annotations become part of the book and are visible to future buyers.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| book_id | Yes | ||
| content | Yes | The annotation body | |
| language | No | en | |
| confidence | No | ||
| target_quote | No | Excerpt from the original text you're commenting on | |
| target_anchor | No | Paragraph anchor ID | |
| target_chapter | No | ||
| target_section | No | e.g. '3.2' |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the transparency burden. It discloses that annotations become part of the book and are visible to future buyers, which is a key consequence. However, it does not mention irreversibility, moderation, or that annotation visibility might be controllable via hide_my_annotation.
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?
Two concise sentences that state the purpose and a key consequence. No filler.
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?
Given 9 parameters and no output schema, this is complex. The description only covers purpose and one consequence; it lacks parameter guidance, ownership verification details, and what happens after posting. The agent would likely need to infer or ask for clarification.
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 only 44%, and the description does not compensate. It never mentions the required parameters (book_id, type, content) or explains the meaning of the type enum or targeting fields. The agent gets no help from the description in constructing arguments.
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?
Clearly states the action ('post an annotation'), the target resource ('a book you have purchased'), and the key condition (ownership). The second sentence adds that annotations are persistent and visible to future buyers, distinguishing this from transient comments or reviews.
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?
Provides a clear prerequisite (must have purchased the book), which tells the agent when this tool is appropriate. It does not explicitly name alternatives like post_review or comment_on_annotation, but the context of permanent book-bound annotations implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools have overlapping purposes. For example, list_my_books and my_books both list authored books, and author_dashboard is a superset; list_orders and my_orders are near-duplicates; check_earnings and payout_balance both report earnings. This creates confusion and risks misselection.
Naming is inconsistent. While many tools use verb_noun (list_annotations, get_book_details), others use my_* (my_books, my_orders), bare nouns (payout_balance), or compound verbs (connect_onboard). The lack of a uniform pattern makes the set feel disjointed.
49 tools is excessive for a server, especially with at least three sets of near-duplicates. The platform is complex, but many tools could be merged (e.g., my_books and list_my_books, list_orders and my_orders). This count will overwhelm agents and increase misselection risk.
The toolset covers the core domain well: discover, purchase, read, comment, review, annotate, publish, monetize, verify, and manage payouts. Minor gaps exist, such as no update/delete annotation, no delete review, and no single-item getter for annotations/reviews, but these are not critical to the main workflows.