Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

inews_author

Fetch an inews.co.uk author profile from a canonical author URL, returning name, bio, image, social links, and recent articles.

Instructions

Get an i author profile. Returns an author profile from i (inews.co.uk) by url, a canonical https://inews.co.uk/author/<slug> link. The response has name, bio, image_url, same_as social profiles and up to about 30 recent articles, each with title, URL, summary, section and published_at. Paginated or non-author URLs return 400, and an unknown author returns 404.

Input Schema

NameRequiredDescriptionDefault
urlYesCanonical i author URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.9/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. It discloses the response fields (name, bio, image_url, same_as, recent articles with metadata) and error behavior (400 for paginated/non-author URLs, 404 for unknown authors). It does not mention authentication, rate limits, or whether the operation is strictly read-only, though 'Get' implies it.

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?

Front-loaded with the core action, then details on input format, response shape, and errors. The first sentence ('Get an i author profile') is somewhat redundant with the second, but overall the description is tight and well-organized.

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?

For a simple one-parameter lookup with no annotations and no output schema, the description provides everything needed: the exact input URL format, the full response structure, and edge-case error behavior. No critical gaps remain for an agent to call and interpret the tool.

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 coverage is 100% for the single `url` parameter, so baseline is 3. The description adds value by specifying the exact canonical URL format (`https://inews.co.uk/author/<slug>`) and noting that non-matching URLs yield a 400, which clarifies the parameter's expected syntax.

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 and resource ('Get an i author profile') and clarifies the domain (inews.co.uk). However, it does not explicitly differentiate from sibling tools like inews_article or other author endpoints; the distinction is left to the tool name and URL pattern.

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 by the required canonical `https://inews.co.uk/author/<slug>` URL and the note that non-author URLs return 400, but there is no explicit when-to-use guidance or comparison to alternative tools (e.g., inews_article).

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