Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

ft_search

Search Financial Times articles by keyword, with filters for date range and sorting by relevance or date. Returns titles, URLs, summaries, section tags, publication times, and lead images.

Instructions

Search Financial Times articles. Returns one page of Financial Times search results: each story's title, canonical URL, summary, section tag, publication time, and lead image. Results can be ordered by relevance or date and filtered by publication window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSearch keywords
pageNoResults page
sortNoResult ordering
date_rangeNoPublication-window filter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that only one page of results is returned, lists the exact output fields, and mentions ordering and filtering options. It does not cover default sort order, pagination bounds, or rate limits, but for a read-only search tool this is substantive.

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 with no filler. The core action is front-loaded, and the return fields plus available options are summarized efficiently.

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?

For a 4-parameter search tool with no output schema, the description covers purpose, output fields, ordering, and filtering. Minor gaps such as default sort order and page bounds are left to the schema, but nothing essential is missing for correct invocation.

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%, so the schema already documents q, page, sort, and date_range. The description adds only a restatement of ordering and publication-window filtering, which adds no meaning beyond what the schema already provides.

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?

The description uses a specific verb ('Search') and resource ('Financial Times articles'), and clearly states that it returns a page of search results with named fields. It is clearly distinguishable as a search tool among the FT siblings, though it does not explicitly name alternative tools like ft_headlines or ft_news.

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 clearly implies when to use it: when an agent needs keyword search over Financial Times articles rather than browsing headlines or sections. It does not explicitly state exclusions or name alternative tools, so it falls short of full when/when-not 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