Skip to main content
Glama
kevynf

AKBridge MCP Server

by kevynf

news_cctv

Read-onlyIdempotent

Fetch CCTV News Simulcast transcripts by date from 2016-02-03 onward, returning structured data for text analysis and archival research.

Instructions

新闻联播文字稿 https://tv.cctv.com/lm/xwlb :param date: 需要获取数据的日期;目前 20160203 年后 :type date: str :return: 新闻联播文字稿 :rtype: pandas.DataFrame

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo20240424

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior context — the historical coverage boundary (post-2016-02-03) and the DataFrame return type — but says nothing about rate limits, latency, or empty-result behavior for out-of-range dates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The resource name and source URL are front-loaded, which is good. However, the trailing docstring boilerplate (:type date: str, :return:, :rtype:) mostly restates what the first lines already say and adds markup noise rather than 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?

For a single-optional-parameter, read-only tool with no output schema, the description supplies source, parameter meaning, coverage window, and return type — enough for correct invocation. It stops short of noting whether the DataFrame is one row per day or per segment, but the core is complete.

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?

With 0% schema description coverage, the description must carry the parameter, and it does: it explains that date is the target date and constrains the valid range to dates after 20160203. The YYYYMMDD format is only inferable from the schema default, not stated outright, so this is not a full 5.

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 names a specific resource, 新闻联播文字稿 (CCTV News Simulcast transcript), and gives the source URL, so an agent knows exactly what data is returned. The verb (fetch/retrieve) is only implied rather than stated, and it does not explicitly distinguish itself from near-neighbors like video_tv or video_variety_show.

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

Usage Guidelines2/5

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

The only guidance is the data-coverage constraint (data available only after 20160203), which tells the agent what dates are valid. There is no when-to-use / when-not-to-use statement and no mention of any alternative tool for news or TV content.

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