Skip to main content
Glama

wattpad_story

Read-only

Get one Wattpad story by id and return its title, description, author, votes, reads, comments, chapter count, completed flag, language, category ids, tags, last published date and paywall flag. Use this after finding a story id with wattpad_search or wattpad_user_stories to size its audience or check whether it is still updating; an unknown id returns not found and no chapter text is returned.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "story_id": "<story_id>"
    },
    "name": "wattpad_story"
  }
}

Input Schema

NameRequiredDescriptionDefault
story_idYesNumeric Wattpad story id, such as 344352588; a wattpad.com/story link is also accepted

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them — an unknown id returns 'not found', and no chapter text is returned, which sets expectations about the response. It doesn't cover auth, rate limits, or pagination, but for a read-only single-record fetch those are minor.

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?

Two sentences, front-loaded with the action and its outputs, then the usage rule and caveats. The long enumeration of return fields is partly redundant given an output schema exists, which is the only waste.

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?

With a single fully documented parameter, an output schema, and read-only annotations, nothing an agent needs is missing: purpose, upstream dependency, error case, and the deliberate absence of chapter text are all stated.

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% and the schema already explains that a numeric id or a wattpad.com/story link is accepted. The description only repeats 'by id' and adds no format, validation, or fallback detail, 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 a specific verb and resource ('Get one Wattpad story by id') and immediately enumerates the returned attributes, making the scope unmistakable. Among the wattpad_* siblings it is clearly distinct from wattpad_story_parts (chapters) and wattpad_search (discovery).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call this 'after finding a story id with wattpad_search or wattpad_user_stories', naming two concrete upstream tools and two motivating goals (size its audience, check whether it is still updating). It stops short of naming wattpad_story_parts as the alternative when chapter text is needed, leaving that inference to the reader.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.