Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

physorg_headlines

Fetch current Phys.org section headlines by feed slug, including topics, breaking news, and editorials. Use it to pull recent stories from a selected Phys.org feed.

Instructions

Get Phys.org section headlines. Returns current stories from one Phys.org feed. The accepted values are the seven Topics menu feeds plus the Breaking and Editorials feeds. Search and tag feeds are not included.

Input Schema

NameRequiredDescriptionDefault
sectionYesPhys.org RSS feed slug from physorg-sections

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description must carry behavioral disclosure. It implies a read-only, single-feed retrieval of 'current stories' and clarifies the feed scope (no search/tag feeds), but says nothing about rate limits, auth, pagination, or how many stories are returned.

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 short sentences with the purpose front-loaded and the scoping constraint last. No filler; each sentence carries information, though the phrasing is slightly repetitive ('feed' appears twice).

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 single-enum-parameter read tool with no output schema, the description covers what is returned and the valid feed scope adequately. Return-structure detail is unnecessary given the simplicity, though output shape is left entirely implicit.

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 enum fully lists the slugs, so the schema does the heavy lifting. The description adds marginal value by explaining the slugs map to the seven Topics menu feeds plus Breaking and Editorials, but no format or usage nuance beyond that.

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 states a specific verb and resource ('Get Phys.org section headlines', 'returns current stories from one Phys.org feed'), so an agent knows exactly what it retrieves. It does not explicitly name or differentiate from siblings like physorg_sections or physorg_article, so it stops short of a 5.

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?

It defines scope by listing which feeds are accepted and excluding search and tag feeds, which implicitly guides use. However, it never states when to choose this over physorg_sections or physorg_article, leaving the selection 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