Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

time_article

Fetch a TIME article by canonical HTTPS URL to get title, authors, section, publication and update times, lead image, body paragraphs, and paywall status.

Instructions

Get TIME article content. Returns one TIME article by url, which must be a canonical HTTPS dated time.com article link. The response has the title, description, section, authors, publication and update times, lead image URL, body paragraphs and a paywalled flag.

Input Schema

NameRequiredDescriptionDefault
urlYesCanonical TIME article URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it enumerates the returned fields and, most usefully, discloses a `paywalled` flag so the agent knows content may be gated. It omits auth, rate-limit, and error behavior, which keeps it from a 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?

Two sentences, front-loaded with purpose followed by input constraint and return shape. Nothing is redundant; the return-field enumeration earns its place because there is no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param article fetcher with no annotations or output schema, the description covers purpose, valid input, and the full response shape including the paywall caveat. It stops short of explaining error/edge behavior (e.g., invalid or non-canonical URLs), so it is strong but not exhaustive.

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 the baseline is 3, but the description adds specifics beyond the schema's 'Canonical TIME article URL' — elaborating HTTPS, 'dated', and time.com as the required format. That extra constraint meaningfully improves correct invocation.

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 opens with a specific verb+resource ('Get TIME article content') and immediately scopes it to 'one TIME article by url'. The singular 'article' cleanly distinguishes it from the plural feed siblings (time_headlines, time_news, time_sections) without needing to name them.

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?

It implies usage by stating the url 'must be a canonical HTTPS dated time.com article link', which tells the agent this is a fetch-by-known-URL tool. However, it gives no when-to-use/when-not context and never routes the agent between this tool and time_headlines/time_news or other *_article siblings.

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