Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

ew_article

Fetch structured Entertainment Weekly article content from a canonical URL, including title, authors, body paragraphs, and paywall status.

Instructions

Get Entertainment Weekly article content. Returns one Entertainment Weekly article by its canonical url in the form ew.com/<slug>-<id>. The response has the title, description, publish and update times, section, authors, lead image, body paragraphs and a paywalled flag. Blocked or malformed pages return an upstream error.

Input Schema

NameRequiredDescriptionDefault
urlYesCanonical Entertainment Weekly article URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries full behavioral burden and does well: it discloses the `paywalled` flag and that blocked or malformed pages return an upstream error. Auth/rate-limit behavior is not mentioned, so not a full 5.

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?

Three tight sentences, front-loaded with the action and input format, followed by return fields and error behavior. No filler; every sentence carries information an agent needs.

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?

No output schema exists, so the description must carry return-value context, and it does by enumerating title, description, publish/update times, section, authors, lead image, paragraphs, and the paywalled flag, plus error behavior. Complete for a single-parameter fetch tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds the concrete URL format `ew.com/<slug>-<id>`, which is genuinely useful detail beyond the schema's 'Canonical Entertainment Weekly article URL'.

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 Entertainment Weekly article content') and the exact input needed (canonical url). It is clearly distinguishable from siblings like ew_headlines, ew_news, and ew_sections, which return lists rather than a single article.

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

Usage Guidelines3/5

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

The description implies usage (supply a canonical url to fetch one article) but never states when to prefer this tool over the related ew_* list/section tools, nor any prerequisites. Usage is inferable but not explicit.

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

Deploy Server

Other Tools