Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

startribune_news

Fetch Minnesota Star Tribune stories as structured RSS data, including titles, canonical URLs, summaries, and dates for news monitoring or republishing.

Instructions

Get Minnesota Star Tribune top stories. Returns the public Star Tribune RSS feed with current story titles and canonical URLs; publisher summaries and publication dates are included when supplied by the feed. Optional bylines and images are returned only when present. Summaries are publisher teasers, not full article text. This feed-only route does not claim a complete section taxonomy or retrieve article bodies; use attribution when republishing feed content.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.7

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 burden and does well: it discloses that results are feed-sourced, summaries are publisher teasers not full text, optional bylines/images appear only when present, and adds an attribution obligation. It stops short of stating freshness, rate limits, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose and then caveats. Every clause adds information; the only slight drag is the attribution sentence, which is relevant but arguably belongs in general usage notes.

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 no-param, no-annotation, no-output-schema tool, the description covers what it returns, what it omits, and the content-usage constraint. It doesn't describe return shape or ordering, but that is a minor gap given the narrow, feed-only scope.

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?

The tool takes zero parameters, so there is no parameter semantics to convey. Baseline for a parameterless tool is 4, and the description correctly implies a no-argument fetch.

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 ('Get') and resource ('Minnesota Star Tribune top stories') and clarifies the mechanism (public RSS feed). This distinguishes it from article-level siblings like seattletimes_article, though it doesn't name a direct Star Tribune sibling (there isn't one), leaving it slightly less connected to the surrounding tool family.

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?

The description says it is a 'feed-only route' that doesn't retrieve bodies or claim a complete taxonomy, which implicitly scopes usage. However, it names no alternative tool for full article text or broader section coverage, so an agent has no explicit routing guidance.

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