Skip to main content
Glama

save_article

Idempotent

Save a web page by URL to the user's Saved list: fetches it, extracts the article with Readability and stores it. For content you already have, use upload_article instead. A URL that's already saved is returned unchanged unless you pass refetch, which replaces the stored copy. Returns the article's id, metadata, an excerpt and outcome (created, updated or existing), not the content (use get_entry for that). Errors carry an app code in their data, e.g. when the site rate limits us or the user's fetch quota is used up. Private Google Docs work once the user has granted Google Docs access in the web app; otherwise the error says how.

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": {
      "url": "<url>"
    },
    "name": "save_article"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL to save
forceNoWith refetch, update even if the new content looks much shorter than the saved copy (by default that refetch is rejected, since it usually means an error or access-denied page).
titleNoOptional title override (useful if page title is poor). Plain text (NOT Markdown or HTML). Do NOT HTML-escape it — write & not &amp;, since it is rendered as literal text and an entity like &amp; would show up verbatim.
authorNoOptional author/byline override (useful if you already know it better than the page). Plain text (NOT Markdown or HTML). Do NOT HTML-escape it — write & not &amp;, since it is rendered as literal text.
refetchNoIf the URL is already saved, fetch it again and update the article in place, keeping its ID, starred state and collections (it is marked unread). Title, author and summary come from the new fetch, so pass any overrides again. Without this, an already-saved article is returned unchanged.
summaryNoOptional summary/excerpt override (e.g. an abstract you already have). Plain text (NOT Markdown or HTML). Do NOT HTML-escape it — write & not &amp;, since it is rendered as literal text. Clipped to ~300 characters.
collectionIdsNoOptional collection IDs to also add the article to (see create_collection)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses fetching and Readability extraction, that already-saved URLs are returned unchanged unless refetch is used, that refetch replaces the stored copy, and what the response contains versus omits. It also explains error behavior around site rate limits, fetch quota exhaustion, and Google Docs authorization, which materially helps an agent interpret failures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is front-loaded with the core action and then adds only high-value routing, refetch, return-value, error, and auth details. Despite its density, every sentence carries useful information and there is no redundant restatement of the title or annotations.

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 a write tool with no output schema, it sufficiently explains what is returned (id, metadata, excerpt, outcome), what is not returned, and how to retrieve content via get_entry. It also covers important behavioral edge cases such as existing URLs, refetch replacement, quota/rate-limit errors, and Google Docs access, leaving little an agent needs to infer.

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 description coverage is 100%, so the schema already documents all seven parameters in detail, including force, title, author, summary, refetch, and collectionIds. The description reinforces refetch behavior and outcome values but does not add substantial parameter-level meaning beyond the schema, making the baseline 3 appropriate.

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 states a specific verb and resource: saving a web page by URL to the user's Saved list, with fetching, Readability extraction, and storage. It explicitly distinguishes this from upload_article for content the user already has, so an agent can route correctly without inspecting schemas.

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?

It names the alternative for already-held content (upload_article), explains the refetch path for already-saved URLs, and directs the agent to get_entry when article content is needed rather than metadata. It also covers the Google Docs access prerequisite, giving clear when-to-use and when-not-to-use context.

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.