Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

brisbanetimes_article

Fetch a Brisbane Times article's metadata and body paragraphs from a public URL, including paywall and truncation flags, without bypassing paywalls.

Instructions

Get Brisbane Times article content. Returns one Brisbane Times article's metadata and the exact body paragraphs served by one anonymous page request, with the publisher's is_accessible_for_free, paywalled, and is_truncated flags. No paywall is bypassed or hidden content fetched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesCanonical Brisbane Times article URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A3.6/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 well: it discloses that content is "the exact body paragraphs served by one anonymous page request," surfaces the publisher flags (is_accessible_for_free, paywalled, is_truncated), and explicitly states no paywall is bypassed or hidden content fetched. This sets accurate expectations about partial/truncated content and anonymous (no-auth) fetching, though it omits error/rate-limit behavior.

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 purpose, followed by return details and then the no-bypass disclaimer. Every sentence earns its place with no redundancy.

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?

With no output schema, the description correctly explains what is returned (metadata, body paragraphs, and the three publisher flags), which is the main thing an agent needs. It is nearly complete; only edge-case behavior (e.g., what happens on a non-article or invalid URL) is absent.

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?

There is a single parameter with 100% schema description coverage ("Canonical Brisbane Times article URL"), so the schema already documents it. The description adds only the implicit 'anonymous page request' framing and does not clarify URL format beyond what the schema states — the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Get Brisbane Times article content") and scopes it to a single article's metadata plus body paragraphs. It is distinguishable from the sibling headlines/news tools by being a per-URL article fetch, but it never explicitly contrasts itself with brisbanetimes_headlines, brisbanetimes_news, or the many other publisher `*_article` tools.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no mention of when not to use it, and no named alternative among the many sibling article/headlines/news tools. The reader must infer that a canonical article URL is the entry condition.

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