Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

vox_article

Fetch a public Vox article by its canonical URL and return structured JSON with title, description, authors, section, timestamps, lead image, and body paragraphs.

Instructions

Get Vox article content. Returns one Vox article by its canonical url: title, description, authors, section, published and updated times, lead image and the body paragraphs. Only public content is returned; a subscriber-only or blocked article comes back as an upstream error rather than a partial body.

Input Schema

NameRequiredDescriptionDefault
urlYesCanonical Vox article URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.1/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 meaningful work: it discloses that only public content is returned and that subscriber-only/blocked articles surface as an upstream error rather than a partial body. It doesn't cover auth requirements or rate limits, but the error-vs-partial-body behavior is exactly the kind of trait annotations would otherwise provide.

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 tight sentences, front-loaded with the action and the identifier, followed by the return shape and the error caveat. No filler.

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 describe return values, and it does (field list). It also covers the failure mode. Nothing an agent needs to invoke this fetch-by-URL tool correctly 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?

Schema coverage is 100% and the single url parameter is already documented as the 'Canonical Vox article URL'. The description reinforces 'by its canonical url' but adds no new syntax or format detail, so baseline 3 is correct.

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 (Get) and resource (Vox article content) and enumerates the returned fields (title, description, authors, section, times, lead image, paragraphs). This distinguishes it from list-style siblings like vox_headlines or vox_news 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?

Usage is implied: fetch a single article by canonical URL. There is no explicit when-to-use vs alternatives (e.g., vox_headlines for listings, vox_author for author feeds) and no stated exclusions. Adequate but leaves routing to inference.

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