Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

men_author

Fetch a Manchester Evening News author profile by slug or canonical URL to get name, job title, bio, contact details, and recent articles.

Instructions

Get a Manchester Evening News author profile. Returns a Manchester Evening News author profile, identified by slug (such as lee-swettenham) or a canonical manchestereveningnews.co.uk/authors/<slug>/ url; provide exactly one. The response has the name, job title, bio, email, twitter and one page of recent articles with title, URL and label. Contact fields are absent when unlisted.

Input Schema

NameRequiredDescriptionDefault
urlNoCanonical manchestereveningnews.co.uk/authors/<slug>/ URL; alternative to slug
slugNoAuthor slug, e.g. lee-swettenham

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4.3/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 a fair job: it names the returned fields, discloses that only 'one page of recent articles' is returned (a pagination limit), and states the conditional 'Contact fields are absent when unlisted.' It does not cover error behavior for an unknown slug/url, so it is not complete.

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?

Two sentences, no padding, and the core purpose is front-loaded before the identification mechanics. The mild restatement of 'author profile' in sentence two is the only redundancy.

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?

With no output schema, the description must explain returns, and it does: identity inputs, response fields, pagination, and the conditional omission of contact fields. Only failure modes for invalid inputs are left unspecified.

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%, so baseline is 3, but the description adds genuine meaning: the mutual-exclusivity rule ('provide exactly one'), a concrete slug example, and the canonical URL shape. That goes beyond the per-property schema text.

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 a Manchester Evening News author profile') and is unmistakable against siblings like men_article, men_news and men_sections, which cover articles rather than author profiles. The scope is further pinned down by naming the exact site and the identity inputs.

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?

Explicitly instructs 'provide exactly one' of slug or url, which is real invocation guidance. It does not, however, route the agent away from a sibling (e.g. when to prefer men_article for content vs. this for author metadata), so it stops short of full alternative 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