Skip to main content
Glama

read_works

Get structured reader reports for AO3 fanfics by providing work IDs and a query. The AI reads up to 20 fics at once, answering questions about plot, characters, and style, with comparisons for multiple works.

Instructions

Have the mini reader (a separate AI) read full fics and report on each.

Works for a single fic or up to 20 at once. You never receive fic text — only structured reader reports, one per work. The reader answers your query directly (anything works: "is the ending happy?", "how explicit is it?", "which of these should I read first?") plus gives a general digest of plot, characters, style, and content notes. When given several fics, it ends with a comparison section ranking them against your query.

This is the ONLY approved way to read a fic. A separate model does the reading so a whole novel never touches your context. You MUST send fics here before you recommend, rank, summarize, or judge them — search blurbs are not enough, and reading raw text yourself defeats the entire point of this server. Shortlist from blurbs, read here, then recommend.

Reading depth: a single-fic call sends the reader up to ~150k words (whole novels fit); in a batch each fic is capped at ~100k characters. If a long fic's report matters, read it alone. Batches that exceed the token budget are split internally, then a final reduce pass still produces ONE global comparison across the whole batch.

Content refusals: the reader is Gemini, which has a non-configurable safety filter that occasionally refuses explicit or extreme fics — that fic's report comes back as "(mini reader returned no text …)". The server already retries once on the backup model, but the block is intermittent, so if a fic you care about is refused: read it ALONE (a single fic isn't dragged down by an extreme one sharing its batch), or just retry. In a mixed batch, one refused fic does not sink the others — their reports still return.

Args: work_ids: 1-20 numeric AO3 work ids (from search results or URLs). query: the question to answer about each fic.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
work_idsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that a separate model does the reading, never returns raw text, handles batch splitting, retries on safety blocks, and explains refusal behavior. It could be slightly more concise but adds substantial context beyond the tool's name.

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?

The description is front-loaded with purpose and usage but runs long with repeated points about not receiving raw text. Every section earns its place, but some redundancy could be trimmed without losing value.

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?

Given the tool's complexity (batch reading, safety filters, comparison reports) and the presence of an output schema, the description covers all necessary context: depth, cap limits, refusal handling, and batching behavior.

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 0% (no description of parameters in schema), but the description explains that work_ids are numeric AO3 IDs and query is a free-form question. This adds meaning beyond the bare schema, though a structured breakdown would improve clarity.

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?

The description clearly states that this tool reads full fics via a separate AI and produces structured reports. It distinguishes itself from siblings like get_work, get_work_text, and search_works by emphasizing that it is the only approved way to read fic content.

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?

Explicitly provides when-to-use and when-not-to-use guidance, stating it is the ONLY approved way to read a fic and must be used before recommending or judging. It also explains alternatives (reading alone for long fics) and retry strategies for refusals.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArturLys/ao3-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server