Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

barrons_headlines

Pass a Barron's topic slug to retrieve a page of headlines with each story's title, URL, summary, publication time, authors, and lead image.

Instructions

Get the latest stories in a Barron's topic. Returns one page of a Barron's topic's headlines: each story's title, canonical URL, summary, publication time, authors, and lead image. Section must be a slug returned by /barrons/topics.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoResults page
sectionYesBarron's topic slug from /barrons/topics

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

B3.4/5.0
Behavior2/5

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

No annotations exist, so the description carries full burden of behavioral disclosure. It clarifies it returns one page and names the slug source, but doesn't state whether results are sorted, whether pagination is supported despite a page parameter, whether section values are case-sensitive, or whether the call is read-only. The schema already includes page, so the 'Returns one page' is partially schema-redundant.

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 the verb and resource, then return fields, then the slug prerequisite. No fluff or repetition of schema content beyond necessary clarification.

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

Completeness3/5

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

There is no output schema and no annotations, so the description helps by listing returned fields, but it omits whether the page parameter is optional, what happens with an invalid slug, sort order, and response size. For a simple list tool this is acceptable but not complete.

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 description coverage is 100%, so baseline is 3; the description adds a usage condition for section (must be a slug from /barrons/topics) and clarifies the page's role by saying 'Returns one page'. This raises it above baseline, though it doesn't define page bounds or default behavior.

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 clearly states the tool 'Get the latest stories in a Barron's topic' and enumerates the return fields (title, URL, summary, time, authors, lead image), which distinguishes it from article/news/topics siblings. It doesn't explicitly contrast with barrons_article or barrons_news, but the returned headline page structure is specific enough.

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 states the section must be a slug from /barrons/topics, giving a prerequisite for correct usage. It does not explicitly say when to choose this over barrons_headlines alternatives, when to use barrons_news, or mention pagination behavior, so it is adequate but not action-guiding.

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