Extract Sky News article metadata and body text from a canonical URL. Retrieve public article content for reading, parsing, or analysis via Crawlora MCP.
Get Sky News article content. Returns public Sky News article metadata and body paragraphs from a canonical article URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical Sky News article URL |
Changes observed during successful MCP inspections.
v1.17.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the tool returns 'public Sky News article metadata and body paragraphs,' which gives some sense of the output, but it does not mention read-only nature, any required permissions, error conditions, or rate limits. It is a simple fetch operation, but the description lacks detail on behavioral traits beyond the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action. It efficiently communicates the tool's purpose without extraneous detail. It could be slightly more structured with separate clauses for metadata vs body, but it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is minimally adequate. It tells the agent what is returned (metadata and body paragraphs) but does not elaborate on the format or structure of that output. Given the simplicity, it is sufficient, but it could be more complete by clarifying what 'metadata' includes or whether the response is JSON.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'url' with description 'Canonical Sky News article URL,' and the description repeats 'from a canonical article URL.' Since schema coverage is 100%, the description adds no new meaning beyond reinforcing the term 'canonical.' Baseline 3 is appropriate as the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get Sky News article content' and specifies it returns 'metadata and body paragraphs from a canonical article URL.' The verb+resource structure is clear, and the name skynews_article reinforces the domain. However, it does not explicitly differentiate from sibling article tools for other outlets, but the brand specificity is sufficient for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like skynews_headlines, skynews_news, or skynews_author. It does not state that this tool is for fetching a specific article given a URL, nor does it exclude other uses. The agent must infer usage from the name and description alone, with no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.