Skip to main content
Glama

Search HKEx Filings

search_filings
Read-onlyIdempotent

Search live HKEx filings in a date window (at most 31 days).

``from_date``/``to_date`` accept YYYY-MM-DD or DD/MM/YYYY. All filters are optional and
combine with AND semantics: ``stock_code`` matches exactly (e.g. ``01461`` or ``1461``);
``title_query``, ``category`` and ``stock_name`` are case-insensitive substrings (e.g.
category ``Dividend``); ``document_type`` matches the file type exactly (e.g. ``PDF`` or
``HTML``). Filters are applied to the fetched window, so widen ``max_results`` to catch
rarer matches. ``max_results`` caps the number of filings fetched and returned (hard cap
200). Returns the matching filings — each carrying ``fileType``, ``sizeText``,
``category`` and ``newsId`` metadata — plus the HKEx-reported total for the window. Use
list_filing_facets first to see which categories, types and codes exist in a window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_dateYesYYYY-MM-DD or DD/MM/YYYY
categoryNoOptional case-insensitive substring of the headline category
from_dateYesYYYY-MM-DD or DD/MM/YYYY
stock_codeNoOptional exact HKEx stock code, e.g. 01461
stock_nameNoOptional case-insensitive substring of the stock short name
max_resultsNoMaximum filings to fetch and return (default 50, cap 200)
title_queryNoOptional case-insensitive substring of the filing title
document_typeNoOptional exact file type, e.g. PDF, HTML, XLS, DOC

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesThe filings matching the window and filters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), and the description adds genuinely non-obvious behavior: filters are applied to the fetched window rather than server-side, the 31-day window limit, and the hard cap of 200 on fetched-and-returned filings. The post-fetch filtering caveat is exactly the kind of trap an agent would otherwise fall into by concluding there are no matches.

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?

The window constraint and date formats are front-loaded, and the paragraph is dense with no filler sentences. It repeats some filter semantics already present in the schema descriptions and the backtick-heavy formatting makes it slightly heavy to scan for an otherwise compact tool.

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 an 8-parameter search with a rich output schema and full annotations, the description covers window limits, filter semantics, result cap, returned metadata fields and the sibling to consult first. Nothing needed to call it correctly is missing.

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 description coverage is 100%, so the baseline would be 3, but the description adds the AND-combination semantics across all optional filters and clarifies the stock_code example with and without leading zeros (01461 or 1461), which the schema does not. Match-type details (exact vs case-insensitive substring) largely duplicate the 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 (Search) and resource (live HKEx filings) plus a hard scope constraint (date window of at most 31 days). It distinguishes itself from siblings by routing facet discovery to list_filing_facets, so an agent can separate it from get_filing without opening either schema.

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 tells the agent to run list_filing_facets first to discover valid categories, types and codes, and advises widening max_results when matches are rare — clear positive routing. It stops short of a when-not statement (e.g. use get_filing once a newsId is known), so it is clear context rather than full alternative/exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.