Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

phonearena_article

Fetch PhoneArena article or review content from a canonical URL and return public metadata plus body paragraphs; note Cloudflare challenges may cause a 503 error.

Instructions

Get PhoneArena article or review content. Returns public PhoneArena news or review metadata and body paragraphs from a canonical article URL. PhoneArena serves pages behind a Cloudflare challenge; when the challenge is not cleared the endpoint returns a 503 error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesCanonical PhoneArena article URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses a key runtime behavior: PhoneArena pages sit behind Cloudflare and return 503 when the challenge is not cleared. It also notes the content is public, implying no auth requirement, though rate limits and retry behavior are not covered.

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 short sentences: what the tool does, what it returns, and the main error condition. The description is front-loaded and contains no filler.

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 one-parameter fetch tool with no output schema, the description provides enough context: scope, return contents, and a significant failure mode. It could add response structure or retry guidance, but nothing essential is missing.

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?

The schema already documents the single url parameter with 100% coverage. The description mostly restates that a canonical PhoneArena article URL is expected and adds little beyond emphasizing the canonical-URL requirement.

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?

The description names the resource precisely: PhoneArena article or review content fetched from a canonical URL, returning metadata and body paragraphs. It is distinguishable from headline/news/list siblings, though it does not explicitly name those alternatives.

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 canonical-URL condition implies when to use this tool—when full article/review content is needed—but it does not mention alternative tools or exclusions. The guidance is adequate but implicit.

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