Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

livescience_sections

Lists the 14 top-level Live Science sections accepted by headlines, returning each section's slug, display name, and URL for targeted news retrieval.

Instructions

Get Live Science sections. Lists the 14 top-level Live Science sections accepted by livescience-headlines, including animals, archaeology, human-behavior, physics-mathematics, planet-earth and space. Each entry has a slug, display name and section url.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the return shape (a `slug`, display `name`, and section `url` per entry) and the fixed size (14 sections), which is helpful structural context. It does not mention auth, caching, or read-only semantics explicitly, but for a parameterless enumeration tool the disclosed behavior is adequate.

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 core purpose and followed by concrete examples and the return shape. Every sentence adds useful information with no filler or repetition.

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?

The tool is simple, has no input schema and no output schema. The description covers what the tool returns (fields per entry) and the count, and it links the result to the sibling tool that consumes it. Nothing needed to call it correctly is missing.

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 are no parameter semantics to explain. Per the rubric, a parameterless definition gets a baseline of 4, and the description does not need to compensate for any schema gaps.

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 and resource ('Get Live Science sections'), gives an exact count, concrete examples, and explicitly names the sibling it feeds into ('accepted by `livescience-headlines`'). An agent can distinguish this from livescience_article, livescience_news, and livescience_headlines without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the primary use case clear by tying the output to `livescience-headlines` – the agent knows these slugs are valid inputs for that tool. It does not explicitly say 'use this to discover section values before calling headlines' or state exclusions, but the context is strong and leaves little ambiguity.

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