Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

liverpoolecho_author

Get a Liverpool Echo author's profile: name, job title, bio, email, Twitter handle, and recent articles using author slug or URL.

Instructions

Get a Liverpool Echo author profile. Returns one Liverpool Echo author's public profile: name, job title, bio, email, X/Twitter handle, and one page of their recent articles.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoCanonical liverpoolecho.co.uk/authors/<slug>/ URL; alternative to slug
pageNo1-based page number of the author's article list (1 to 100); overrides any pageNumber in url
slugNoAuthor slug, e.g. wesley-holmes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.6/5.0
Behavior3/5

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

Annotations are absent, so the description carries the full burden. It does disclose that it returns a public profile with specific fields and one page of recent articles, indicating a read-only operation, but it does not mention error conditions, rate limits, or what happens if the author is not found. It is adequate but not rich.

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?

The description is two sentences, front-loaded with the verb and resource, and lists the returned fields without excess verbiage. Every word contributes to understanding what the tool does.

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

Completeness2/5

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

The description does not state that at least one of `slug` or `url` must be provided, despite zero required parameters in the schema. There is no output schema, so the description should clarify how to identify an author and what happens with missing input. This is a significant gap for a tool with optional-looking parameters.

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 description coverage is 100% for all three parameters (url, page, slug). The description adds the context that the result includes 'one page of recent articles', which aligns with the page parameter, but otherwise does not add meaning beyond the schema. Baseline 3 applies.

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?

The description clearly states the verb 'Get' and the resource 'Liverpool Echo author profile', and enumerates the returned fields (name, job title, bio, email, X/Twitter handle, one page of recent articles). This is specific enough to distinguish it from sibling tools like liverpoolecho_article or other publication author tools.

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?

No explicit guidance on when to use this vs alternatives. The description implies its use for author profiles, but does not mention when not to use it or how it relates to liverpoolecho_article or other tools. It does not provide exclusions or alternative routing.

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