de en es ja ko ru zh

AgentLadle MCP CNINFO

Name: AgentLadle MCP CNINFO
Author: agentladle

by agentladle

Overview Schema Source Related Servers Discussions Admin

Python

Local

AgentLadle MCP CNINFO

Englisch | 中文

🇨🇳/🇭🇰 Cloud-gehosteter MCP für A-Aktien- und HK-notierte Unternehmen (Jahresberichte der letzten 3 Jahre und aktuelle Zwischenberichte). Mehr erfahren | API-Schlüssel erhalten

Ein MCP (Model Context Protocol)-Server, der Werkzeuge zum Entdecken, Herunterladen, Parsen und Durchsuchen von chinesischen A-Aktien-Ankündigungen von CNINFO (巨潮资讯网) bereitstellt.

Er ermöglicht KI-Assistenten (Claude, Cursor usw.) den Zugriff auf CNINFO-Ankündigungsdaten über 6 strukturierte Werkzeuge – vom Entdecken verfügbarer Ankündigungen bis zur Stichwortsuche in deren Seiten.

Umfang (v0.1): Nur Ankündigungen. Periodische Berichte (年报 / 半年报 / 一季报 / 三季报) sind nicht enthalten.

Funktionen

6 MCP-Werkzeuge für CNINFO-Ankündigungsdaten: zustandsgesteuerter Abruf (direkt suchen, nur bei Bedarf auf Download/Parse zurückgreifen)
PDF-Dokumentanalyse mit PyMuPDF – physische Seitenextraktion in seitenaufgeteiltes JSON
Lokale Stichwortsuche mit TF- und Positions-Boost-Bewertung, keine externen Suchabhängigkeiten
Idempotent – bereits heruntergeladene/geparste Dateien werden automatisch übersprungen
Null-Konfiguration-Installation – eine Zeile zum MCP-Client hinzufügen, kein Klonen oder manuelles Setup erforderlich
Reines Python, plattformübergreifend (Windows / macOS / Linux)

Related MCP server: Chinese Stock MCP

Voraussetzungen

Python 3.10+ — Python herunterladen
uv — uv installieren

Hinweis: Starten Sie nach der Installation von uv Ihr Terminal und den MCP-Client (z. B. Cherry Studio) neu, um sicherzustellen, dass der Befehl uv erkannt wird.

Schnellstart

Fügen Sie Ihrem MCP-Client (Claude Desktop, Cursor usw.) Folgendes hinzu:

{
  "mcpServers": {
    "mcp-cninfo": {
      "command": "uvx",
      "args": ["agentladle-mcp-cninfo"]
    }
  }
}

Das war's. uvx lädt das Paket und seine Abhängigkeiten automatisch von PyPI herunter – kein Klonen, keine manuelle Installation, keine Pfadkonfiguration.

Alternative: pip install

Wenn Sie die Umgebung lieber selbst verwalten:

pip install agentladle-mcp-cninfo

Dann konfigurieren Sie:

{
  "mcpServers": {
    "mcp-cninfo": {
      "command": "agentladle-mcp-cninfo"
    }
  }
}

Alternative: Aus dem Quellcode ausführen (lokale Entwicklung)

Klonen Sie das Repository und führen Sie es direkt aus:

git clone https://github.com/agentladle/mcp-cninfo.git

Dann konfigurieren Sie Ihren MCP-Client:

{
  "mcpServers": {
    "mcp-cninfo": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/mcp-cninfo", "agentladle-mcp-cninfo"]
    }
  }
}

Ersetzen Sie /path/to/mcp-cninfo durch den tatsächlichen Pfad zum geklonten Repository.

Datenfluss

CNINFO API                        Local Files (~/.agentladle/mcp-cninfo/data/)
──────────────                    ──────────────────────────────
szse_stock.json        ──→       companies.json               (stock_code→orgId mapping)
                                     │
hisAnnouncement/query  ──→        pdf/{LOCAL_KEY}/            (Tool 2: primary PDF/HTML + manifest)
                                     │
PyMuPDF parsing        ──→        json/*.json                 (Tool 3: parse, page-split)
                                     │
Local TF search        ──→        search results              (Tool 4: keyword search)
Page range read        ──→        page content                (Tool 5: read pages)

Werkzeuge

#	Werkzeug	Beschreibung
1	`list_cninfo_announcements`	Verfügbare CNINFO-Ankündigungen für ein Unternehmen entdecken
2	`download_cninfo_announcement`	Ankündigungs-PDF herunterladen (HTML-Fallback); idempotent
3	`parse_cninfo_announcement`	PDF/HTML in seitenaufgeteiltes JSON mit PyMuPDF parsen
4	`keyword_search`	Volltext-Stichwortsuche mit TF-Relevanzbewertung
5	`get_announcement_pages`	Ankündigungsinhalt nach Seitennummernbereich lesen
6	`lookup_stock_code`	Diagnose: stock_code→orgId-Zuordnung nachschlagen, wenn die Auflösung fehlschlägt

Werkzeug 1: `list_cninfo_announcements`

Listet verfügbare CNINFO-Ankündigungen für ein Unternehmen auf. Verwenden Sie dieses Werkzeug NUR, wenn das genaue Datum/der genaue Titel vom Benutzer nicht angegeben ist oder wenn ein Download-Versuch aufgrund einer mehrdeutigen Übereinstimmung fehlschlägt. Standardkategorien schließen periodische Berichte (年报 / 半年报 / 一季报 / 三季报) aus.

Parameter	Typ	Erforderlich	Beschreibung
`stock_code`	string	✅	6-stelliger Aktiencode, z. B. `"000001"`
`category`	string	❌	Kategorieschlüssel, Kurzcode oder chinesische Bezeichnung, z. B. `"董事会"`, `"DSH"`, `"category_dshgg_szsh"`. Weglassen, um Standard-Ankündigungskategorien zu listen
`start_date`	string	❌	Startdatum `YYYY-MM-DD`
`end_date`	string	❌	Enddatum `YYYY-MM-DD`
`title_keyword`	string	❌	Titelschlüsselwortfilter
`limit`	int	❌	Maximale Anzahl zurückzugebender Ankündigungen, Standard 10, Maximum 50

Werkzeug 2: `download_cninfo_announcement`

Lädt eine bestimmte CNINFO-Ankündigung von static.cninfo.com.cn herunter. Bevorzugen Sie local_key aus list_cninfo_announcements, wenn verfügbar. Idempotent.

Parameter	Typ	Erforderlich	Beschreibung
`stock_code`	string	✅	6-stelliger Aktiencode, z. B. `"000001"`
`announce_date`	string	❌	Ankündigungsdatum `YYYY-MM-DD` (optional, wenn `local_key` angegeben)
`title_keyword`	string	❌	Titelsubstring zur Disambiguierung gleichzeitiger Ankündigungen
`category`	string	❌	Optionaler Kategoriefilter
`announcement_id`	string	❌	CNINFO-Ankündigungs-ID, falls bekannt
`local_key`	string	❌	Exakter lokaler Bundle-Schlüssel aus Listenergebnissen

Werkzeug 3: `parse_cninfo_announcement`

Parst eine heruntergeladene Ankündigungs-PDF/HTML in seitenaufgeteiltes JSON. Verwendet PyMuPDF für die physische Seitentextextraktion von PDFs.

Parameter	Typ	Erforderlich	Beschreibung
`local_key`	string	✅	Bundle-Schlüssel, der von Liste/Download zurückgegeben wird, z. B. `"000001_DSH_2026-07-02_8b1ad607"`

Werkzeug 4: `keyword_search`

Volltext-Stichwortsuche über alle Seiten. Ergebnisse nach TF- und Positions-Boost-Score sortiert.

Parameter	Typ	Erforderlich	Beschreibung
`local_key`	string	✅	Bundle-Schlüssel
`keywords`	string[]	✅	1–5 Suchschlüsselwörter
`match_mode`	string	❌	`"ANY"` (Standard, jedes Schlüsselwort passt) / `"ALL"` (alle müssen passen)
`max_results`	int	❌	Maximale Anzahl zurückzugebender Ergebnisse, Standard 5, Maximum 50

Werkzeug 5: `get_announcement_pages`

Liest den vollständigen Seiteninhalt nach Seitennummernbereich.

Parameter	Typ	Erforderlich	Beschreibung
`local_key`	string	✅	Bundle-Schlüssel
`start_page`	int	✅	Startseitennummer (1-basiert)
`page_count`	int	❌	Anzahl der zurückzugebenden Seiten, Standard 3, Maximum 5

Werkzeug 6: `lookup_stock_code`

Diagnosewerkzeug: stock_code→orgId-Zuordnung nachschlagen. Nur verwenden, wenn download_cninfo_announcement / list_cninfo_announcements Stock code not found zurückgibt. Umgeht den Cache für fehlgeschlagene Codes der Sitzung.

Parameter	Typ	Erforderlich	Beschreibung
`stock_code`	string	✅	6-stelliger Aktiencode, z. B. `"000001"`
`refresh`	bool	❌	Erzwingt das erneute Herunterladen von `szse_stock.json` von CNINFO (Standard: `false`)

Konfiguration

Beim ersten Start wird eine Standardkonfigurationsdatei unter ~/.agentladle/mcp-cninfo/config.yaml erstellt:

paths:
  data_dir: "~/.agentladle/mcp-cninfo/data"
  pdf_dir: "~/.agentladle/mcp-cninfo/data/pdf"
  json_dir: "~/.agentladle/mcp-cninfo/data/json"

download:
  delay_between_requests: 0.3
  min_file_size: 500
  list_page_size: 30
  list_max_pages: 5

company:
  cache_ttl_days: 7

Datenverzeichnisstruktur

~/.agentladle/mcp-cninfo/
├── config.yaml                        # Configuration (auto-created)
└── data/
    ├── companies.json                 # stock_code→orgId mapping (auto-downloaded & cached)
    ├── pdf/                           # Downloaded announcement bundles
    │   ├── 000001_DSH_2026-07-02_8b1ad607/
    │   │   ├── primary.pdf
    │   │   └── manifest.json
    │   └── ...
    └── json/                          # Parsed page-split JSON
        ├── 000001_DSH_2026-07-02_8b1ad607.json
        └── ...

Dateibenennungskonvention: {STOCK_CODE}_{CAT_SHORT}_{ANNOUNCE_DATE}_{ID_HASH}

Beispielverwendung

Die Werkzeuge sind mit einem EAFP-Ansatz (Easier to Ask for Forgiveness than Permission) konzipiert. KI-Assistenten sollten versuchen, Daten direkt abzurufen und sich auf Fehler verlassen, um Downloads auszulösen.

Szenario A: Datei bereits lokal vorhanden (kürzester Weg)

User: "Search 000001 board resolution for 回购"

1. keyword_search(local_key="000001_DSH_2026-07-02_8b1ad607", keywords=["回购", "决议"])
   → Returns page snippets matching the keywords immediately.

Szenario B: Datei fehlt (Fallback ausgelöst)

User: "What did Ping An Bank announce in its latest board notice?"

1. list_cninfo_announcements(stock_code="000001", category="董事会", limit=3)
   → Returns local_key / announce_date / title.

2. keyword_search(local_key="...", keywords=["董事会", "决议"])
   → Error: File not found.

3. download_cninfo_announcement(stock_code="000001", local_key="...")
   → Downloads PDF to ~/.agentladle/mcp-cninfo/data/pdf/

4. parse_cninfo_announcement(local_key="...")
   → Parses into JSON.

5. keyword_search(local_key="...", keywords=["董事会", "决议"])
   → Retries search and returns data.

Technologie-Stack

Komponente	Wahl	Zweck
MCP-Framework	`mcp` (FastMCP)	MCP-Server mit stdio-Transport
HTTP-Client	`httpx`	CNINFO-API-Anfragen und Dateidownloads
PDF-Analyse	`pymupdf` + `beautifulsoup4`	PDF-Seitentextextraktion; HTML-Fallback
Suche	Python-Built-in	TF- und Positions-Boost-Bewertung
Konfiguration	`pyyaml`	YAML-Konfigurationsdatei

Projektstruktur

src/mcp_cninfo/
├── __init__.py
├── server.py                 # MCP Server entry point
├── config.py                 # Config loading (~/.agentladle/mcp-cninfo/config.yaml, singleton cached)
├── models.py                 # Data models
├── categories.py             # Announcement category whitelist / blacklist
├── response.py               # Unified JSON responses
├── instances.py              # Service singletons
├── tools/
│   ├── list_announcements.py # Tool 1: list_cninfo_announcements
│   ├── download.py           # Tool 2: download_cninfo_announcement
│   ├── parse.py              # Tool 3: parse_cninfo_announcement
│   ├── search.py             # Tool 4: keyword_search
│   ├── page.py               # Tool 5: get_announcement_pages
│   └── lookup.py             # Tool 6: lookup_stock_code
└── services/
    ├── company.py            # CNINFO szse_stock.json + stock_code→orgId
    ├── downloader.py         # CNINFO query + PDF download
    ├── parser.py             # PDF/HTML→JSON parsing (PyMuPDF)
    ├── searcher.py           # Local JSON search + TF scoring
    └── keys.py               # local_key helpers

Lizenz

MIT

Available Tools

6 tools

download_cninfo_announcementA

Download a CNINFO announcement PDF (or HTML fallback) to local storage.

<critical_rules>

Prefer local_key from list_cninfo_announcements when available.
After success, immediately call parse_cninfo_announcement with the returned local_key.
Periodic reports (年报/半年报/一季报/三季报) are out of scope. </critical_rules>

Args: stock_code: 6-digit stock code announce_date: YYYY-MM-DD (optional if local_key provided) title_keyword: Title substring to disambiguate same-day announcements category: Optional category filter announcement_id: CNINFO announcement id if known local_key: Exact local bundle key from list results

Name	Required	Description	Default
`category`	No
`local_key`	No
`stock_code`	Yes
`announce_date`	No
`title_keyword`	No
`announcement_id`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: downloads to local storage, may fallback to HTML, and that periodic reports are out of scope. Also directs to call parse_cninfo_announcement after success. Lacks details on file storage location or overwrite behavior, but overall transparent.

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?

Description is well-structured with labeled sections (<strategy>, <critical_rules>, Args). Front-loaded with core purpose. Every sentence contributes value. Slightly long but efficient for the complexity.

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?

Given no annotations and an output schema present, the description covers usage conditions, parameter details, relationship to siblings, and exclusions. It tells the agent when to invoke and what to do after success, making it fully contextualized.

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 0%, so the description compensates by listing each parameter with brief but useful semantics: stock_code is 6-digit, announce_date is YYYY-MM-DD (optional if local_key), title_keyword disambiguates, etc. Adds meaning beyond schema names and types, though not extremely detailed.

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 it downloads a CNINFO announcement PDF (or HTML fallback) to local storage. It specifies the resource (CNINFO announcement) and action (download). Distinguishes from siblings by being a fallback tool and having explicit conditions for invocation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Invoke ONLY as a fallback when keyword_search / get_announcement_pages returns file not found, or after list when you have a concrete local_key / announcement_id.' Also provides critical rules about preferring local_key and that periodic reports are out of scope, giving clear guidance on alternatives.

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

get_announcement_pagesA

Retrieve full page content for a range of pages from a parsed announcement.

<critical_rules>

page_count default 3, max 5.
Prefer keyword_search for specific facts. </critical_rules>

Args: local_key: Bundle key start_page: 1-based start page page_count: Number of pages, default 3, max 5

Name	Required	Description	Default
`local_key`	Yes
`page_count`	No
`start_page`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It mentions that `page_count` defaults to 3 and max 5, and that `start_page` is 1-based. However, it does not disclose behaviors like what happens on invalid parameters, error handling, or the structure of the returned page content. The instruction 'Do not pre-check file existence' hints at potential failure but lacks depth.

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 well-structured with a main sentence, followed by a clear strategy section, critical rules, and an args list. It is concise (few lines) and front-loaded, with every sentence providing useful information.

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?

Given the presence of an output schema (as indicated by context signals), the description does not need to detail return values. However, it lacks information on edge cases (e.g., page out of range) and the implication of 'Do not pre-check file existence' suggests potential failure scenarios that are not elaborated. Overall, it is mostly complete for the tool's moderate complexity.

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 0%, so the description must add meaning. It explains each parameter: `local_key` as 'Bundle key', `start_page` as '1-based start page', and `page_count` with its default and max. This adds value beyond the schema's property titles, though it assumes knowledge of what a 'bundle key' is.

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 starts with a clear, specific verb+resource: 'Retrieve full page content for a range of pages from a parsed announcement.' This distinguishes the tool from siblings like `keyword_search` or `download_hkexnews_announcement` which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a dedicated <strategy> section that explicitly states when to use this tool ('Directly invoke after keyword_search provides a start_page') and what not to do ('Do not pre-check file existence'). The <critical_rules> further clarifies that `page_count` has a default and max, and prefers using `keyword_search` for facts.

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

keyword_searchA

Search a parsed announcement by keywords. Results sorted by relevance.

<critical_rules>

Pass 1-5 keywords, not full sentences.
Expand synonyms when useful (e.g. ["回购", "股份回购"]). </critical_rules>

Args: local_key: Bundle key from list/download keywords: 1-5 search keywords match_mode: "ANY" or "ALL", default ANY max_results: Max snippets, default 5, max 50

Name	Required	Default
`keywords`	Yes
`local_key`	Yes
`match_mode`	No	ANY
`max_results`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description bears full burden. It discloses sorting by relevance, match modes, default values, and max results limit. It also hints at error handling (prompt download/parse on missing file) but lacks details on edge cases like zero results.

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?

Well-structured with strategy and rules sections. Each sentence adds value. The Args list is clear. The use of HTML-like tags adds structure but could be considered nonstandard; however, it aids readability and does not waste space.

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?

Covers purpose, usage, parameters, and error handling. Given the existence of an output schema, lack of return format description is acceptable. However, it could mention snippet highlighting or result ordering more explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully explains all four parameters: local_key ('Bundle key from list/download'), keywords ('1-5 search keywords'), match_mode ('ANY or ALL, default ANY'), and max_results ('Max snippets, default 5, max 50'). This adds critical constraints and context beyond the schema.

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 'Search a parsed announcement by keywords' with specific verb and resource. It distinguishes from sibling tools like download, list, parse, etc., by focusing on searching within an already-parsed announcement.

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?

Provides explicit strategy: 'Directly invoke this tool. Do not pre-check file existence' and suggests using Chinese financial terms. Critical rules specify passing 1-5 keywords and expanding synonyms. Though it doesn't explicitly state when not to use, the guidance is clear and actionable.

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

list_cninfo_announcementsA

List available CNINFO A-share announcements for a company (excludes periodic reports).

<critical_rules>

Default categories exclude 年报/半年报/一季报/三季报.
limit max 50. </critical_rules>

Args: stock_code: 6-digit stock code, e.g. "000001" category: Optional CNINFO category key, short code, or Chinese label (e.g. "董事会", "DSH", "category_dshgg_szsh") start_date: YYYY-MM-DD inclusive end_date: YYYY-MM-DD inclusive title_keyword: Optional title search keyword limit: Max announcements to return, default 10, max 50

Name	Required	Description	Default
`limit`	No
`category`	No
`end_date`	No
`start_date`	No
`stock_code`	Yes
`title_keyword`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that default categories exclude periodic reports and limit max is 50, which is good context. Could mention response format or pagination, but adequate.

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?

Well-structured with sections: purpose, strategy tag, critical rules, and args. Concise, front-loaded, every sentence valuable.

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?

Covers purpose, usage, parameters, and constraints. Has output schema, so return values are documented elsewhere. Complete for a list tool with clear guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description provides detailed parameter explanations: stock_code format, category examples, date format, title_keyword, limit defaults and max. Adds significant value beyond schema.

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?

Description clearly states it lists CNINFO A-share announcements (excluding periodic reports), and provides guidance to skip if user already has specific date and title, differentiating from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (to discover announce_date/local_key/title before download) and when to skip (if user provides specific date and title, go to keyword_search or download_cninfo_announcement).

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

lookup_stock_codeA

Look up CNINFO orgId mapping for a 6-digit A-share stock code. Diagnostic tool.

<critical_rules>

Prefer refresh=false first (local cache). Use refresh=true only if cache is empty or the code is still missing. </critical_rules>

Args: stock_code: 6-digit stock code, e.g. "000001" or "600519" refresh: Force re-download of szse_stock.json from CNINFO (default: false)

Name	Required	Description	Default
`refresh`	No
`stock_code`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

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

No annotations are provided, so the description must convey behavioral traits. It explains the tool is a diagnostic tool, describes the behavior of the refresh parameter (local cache vs re-download), and implies it is read-only by nature. However, it does not explicitly state that it is non-destructive, but the context suggests it is safe. The description adds sufficient behavioral context beyond the schema.

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 concise and well-structured, with clear sections: main description, strategy, critical rules, and args. Every sentence is useful. It is front-loaded with the core purpose and quickly provides actionable guidance.

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?

Given the tool's simplicity (2 parameters, output schema exists), the description covers all necessary aspects: purpose, usage guidelines, parameter details, and behavioral rules. It is complete for an agent to correctly select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description provides all parameter semantics. It explains stock_code as '6-digit stock code, e.g. "000001" or "600519"' and refresh as 'Force re-download of szse_stock.json from CNINFO (default: false)'. This adds meaningful examples and behavior beyond the schema's type/title fields.

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 tool's purpose: 'Look up CNINFO orgId mapping for a 6-digit A-share stock code. Diagnostic tool.' The verb 'look up' and resource 'CNINFO orgId mapping' are specific. It is distinguished from sibling tools (e.g., download_cninfo_announcement) which deal with announcements, not code mappings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a <strategy> section explicitly stating when to invoke: 'Invoke ONLY when download/list returns "Stock code not found". After success, retry the original list/download call.' It also provides critical rules about preferring refresh=false first. This gives clear when-to-use and when-not-to-use guidance.

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

parse_cninfo_announcementA

Parse a downloaded announcement PDF/HTML into page-split JSON.

Args: local_key: Bundle key returned by list/download, e.g. "000001_DSH_2024-04-30_a1b2c3d4"

Name	Required	Description	Default
`local_key`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It describes the transformation but does not disclose potential side effects, error behavior, or safety (e.g., idempotency, permissions). Adequate but not detailed.

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 concise with a main sentence, a strategy block, and argument explanation. No unnecessary words; front-loaded with purpose.

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 tool with one parameter and an output schema, the description provides enough context for usage and timing. Minor gaps on failure behavior, but overall complete given the simple interface.

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?

The schema coverage is 0%, but the description explains the parameter local_key as a bundle key with an example. This adds significant meaning beyond the schema's bare type and title.

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 tool parses downloaded announcement PDF/HTML into page-split JSON. It uses a specific verb and resource, and the strategy section distinguishes it from sibling tools like download_cninfo_announcement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The strategy explicitly says to call after a successful download or when JSON is missing. This provides clear when-to-use and when-not-to-use guidance, differentiating from other tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Jul 10, 2026
- First observeddownload_cninfo_announcement
- First observedget_announcement_pages
- First observedkeyword_search
- First observedlist_cninfo_announcements
- First observedlookup_stock_code
- First observedparse_cninfo_announcement

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored 2026-07-10 05:20 across 6 tools

Disambiguation5/5

Each tool has a distinct role: listing, downloading, parsing, searching, page retrieval, and stock code lookup. No overlap in functionality, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_cninfo_announcements, download_cninfo_announcement, lookup_stock_code). Minor variation in verb choice ('lookup' vs 'list') is negligible.

Tool Count5/5

With 6 tools covering the core workflow of discovering, downloading, parsing, and searching announcements, the count is well-scoped and avoids bloat. Each tool serves a necessary step in the process.

Completeness4/5

The tool set covers the primary lifecycle: list, download, parse, keyword search within a document, and page retrieval. Missing a cross-announcement search or category listing, but these are minor gaps that do not break the workflow.

Resources

Related MCP Connectors

Wudao A-Share Stock Data MCP A
io.github.jcdreamjc
China A-share data for AI agents: 57 read-only tools plus 6 tools for your own watchlist.
Finance Research & Data
63211
https://stock.quicktiny.cn/api/mcp
QuantSonar B
io.github.QuantSonar
China A-share market data for research, backtesting and AI agents via MCP.
Finance Research & Data
451
https://quantsonar.com/mcp
A股数据 API (A-Share Data API)A
com.ashareapi
China A-share market data over MCP: 22 tools for quotes, K-line, financials, money flow, top-trader boards, sectors, macro, convertible bonds and factor screening. Five tools need no API key, so you can connect and try it immediately.
Finance Open Data
911
https://api.ashareapi.com/mcp
zwldarren-akshare-one-mcp B
ai.smithery
Provide access to Chinese stock market data including historical prices, real-time data, news, and…
Finance Search Open Data
93240
https://server.smithery.ai/@zwldarren/akshare-one-mcp/mcp

Related MCP Servers

AgentSkills MCP
Finance Web Scraping Search
zouyingcao
A
license
B
quality
D
maintenance
Provides comprehensive financial research tools including A-share stock analysis, web scraping, entity extraction, and multi-source search capabilities for building intelligent financial research agents.
Updated a year ago (2025-12-16 13:22 UTC)
4
22 PyPI
27
Apache 2.0
Chinese Stock MCP
Finance Search Research & Data
hwibalyu
F
license
Not graded
quality
D
maintenance
Provides real-time quotes, fund flows, and corporate announcements for Chinese A-share stocks. It enables users to search for stocks, analyze financial indicators, and summarize quarterly reports through natural language.
Updated 8 months ago (2026-03-18 05:16 UTC)
-
AgentLadle MCP AKShare
Finance Data Platforms
agentladle
A
license
A
quality
C
maintenance
Provides 46 financial data tools for AI assistants covering A-share, HK, US markets, macroeconomics, funds, and derivatives, powered by AKShare.
Updated 4 months ago (2026-07-08 14:55 UTC)
54
20 PyPI
MIT
DeepFusion MCP Server
Finance Cryptocurrency
chestnutsheep
A
license
C
quality
B
maintenance
Enables AI agents to access Chinese financial market data and investment research through 177 tools, covering stocks, industries, macroeconomics, economic cycles, commodities, crypto, funds, and asset allocation.
Updated 2 months ago (2026-09-12 12:45 UTC)
181
MIT

AgentLadle MCP CNINFO

Funktionen

Voraussetzungen

Schnellstart

Alternative: pip install

Alternative: Aus dem Quellcode ausführen (lokale Entwicklung)

Datenfluss

Werkzeuge

Werkzeug 1: list_cninfo_announcements

Werkzeug 2: download_cninfo_announcement

Werkzeug 3: parse_cninfo_announcement

Werkzeug 4: keyword_search

Werkzeug 5: get_announcement_pages

Werkzeug 6: lookup_stock_code

Konfiguration

Datenverzeichnisstruktur

Beispielverwendung

Technologie-Stack

Projektstruktur

Lizenz

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Resources

Related MCP Connectors

Related MCP Servers

Werkzeug 1: `list_cninfo_announcements`

Werkzeug 2: `download_cninfo_announcement`

Werkzeug 3: `parse_cninfo_announcement`

Werkzeug 4: `keyword_search`

Werkzeug 5: `get_announcement_pages`

Werkzeug 6: `lookup_stock_code`