Skip to main content
Glama
deenesjakoruzh
ww11-max

CSMAR MCP Server

by ww11-max
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Servidor MCP de CSMAR

License MCP Protocol Node.js Python

Servidor del Protocolo de Contexto de Modelo (MCP) para la base de datos financiera Guotai'an (CSMAR), que permite el acceso directo a los datos financieros de CSMAR en Claude Code.

✨ Características

  • Acceso completo a datos de CSMAR: Admite más de 240 bases de datos, incluyendo estados financieros, datos de negociación bursátil, información corporativa, etc.

  • Gestión inteligente de inicio de sesión: Admite inicio de sesión automático mediante variables de entorno y almacenamiento en caché de tokens.

  • 11 herramientas MCP: Cubre funciones completas como exploración de bases de datos, consulta de datos y vista previa.

  • Procesos de Python persistentes: Reutiliza sesiones de Python, mejorando significativamente el rendimiento.

  • Mecanismo de reintento de solicitudes: Reintento automático cuando la red es inestable.

  • Cierre elegante: Admite señales SIGTERM/SIGINT.

  • Comprobación de estado: Consulta el estado del servicio en cualquier momento.

  • Capa intermedia de Python: Encapsulación estable basada en el SDK de CSMAR-PYTHON.

  • Configuración sencilla: Configuración con un solo clic, compatible con la integración nativa de Claude Code.

Related MCP server: cn-financial-mcp

📋 Requisitos previos

  1. Cuenta de CSMAR: Cuenta institucional de CSMAR (Guotai'an) válida (se aceptan cuentas personales o institucionales).

  2. Python 3.8+: Se requiere instalar el SDK de CSMAR-PYTHON y sus dependencias.

    • Instalar dependencias de Python: pip install urllib3 websocket websocket_client pandas prettytable

    • Descargar e instalar el SDK de CSMAR-PYTHON (obtenerlo del sitio web oficial o contactando a CSMAR).

  3. Node.js 18+: Para ejecutar el servidor MCP.

  4. Claude Code: La versión más reciente del editor Claude Code.

🚀 Inicio rápido

1. Clonar el proyecto

git clone https://github.com/ww11-max/Csmar-MCP-server.git
cd Csmar-MCP-server

2. Instalar dependencias

# 安装Node.js依赖
npm install

# 安装Python依赖（CSMAR SDK所需）
pip install urllib3 websocket websocket_client pandas prettytable

# 安装CSMAR-PYTHON SDK
# 从CSMAR官网下载SDK压缩包，解压到Python的site-packages目录
# 或者按照官方文档安装：https://www.gtadata.com/products/csmar-api

3. Configurar variables de entorno

Cree un archivo .env en el directorio raíz del proyecto:

# CSMAR 配置
CSMAR_API_BASE=https://api.gtarsc.com
CSMAR_USERNAME=你的CSMAR用户名
CSMAR_PASSWORD=你的CSMAR密码
CSMAR_LANG=0  # 0=中文, 1=英文

⚠️ Aviso de seguridad: ¡No suba el archivo .env a Git! Ya está configurado en .gitignore para ser ignorado automáticamente.

4. Configurar Claude Code (incluye configuración para cliente Claude y extensión de VS Code)

Agregue la configuración del servidor MCP en el archivo de configuración de Claude Code:

Windows (%APPDATA%/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "csmar": {
      "command": "node",
      "args": ["C:\\path\\to\\Csmar-MCP-server\\src\\index.js"],
      "env": {
        "CSMAR_API_BASE": "https://api.gtarsc.com",
        "CSMAR_USERNAME": "你的CSMAR用户名",
        "CSMAR_PASSWORD": "你的CSMAR密码",
        "CSMAR_LANG": "0"
      }
    }
  }
}

macOS/Linux (~/.config/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "csmar": {
      "command": "node",
      "args": ["/path/to/Csmar-MCP-server/src/index.js"],
      "env": {
        "CSMAR_API_BASE": "https://api.gtarsc.com",
        "CSMAR_USERNAME": "你的CSMAR用户名",
        "CSMAR_PASSWORD": "你的CSMAR密码",
        "CSMAR_LANG": "0"
      }
    }
  }
}

Si el usuario utiliza la extensión de Claude Code en VS Code, la configuración es la siguiente:

Después de configurar el archivo env, modifique la configuración MCP de Claude Code. El archivo de configuración MCP de Claude Code en VSCode se encuentra en:

%APPDATA%/Code/User/globalStorage/saoudval.claude-code/mcp.json

O busque MCP en la configuración de VSCode, encuentre la entrada de configuración de MCP Servers. Agregue la configuración:

{
  "mcpServers": {
    "csmar": {
      "command": "node",
      "args": ["C:\\path\\to\\Csmar-MCP-server\\src\\index.js"],
      "env": {
        "CSMAR_API_BASE": "https://api.gtarsc.com",
        "CSMAR_USERNAME": "你的CSMAR用户名",
        "CSMAR_PASSWORD": "你的CSMAR密码",
        "CSMAR_LANG": "0"
      }
    }
  }
}

⚠️ La ruta debe reemplazarse por la ruta real del proyecto clonado, por ejemplo: D:\Projects\Csmar-MCP-server\src\index.js

5. Reiniciar Claude Code

Reinicie Claude Code para cargar el servidor MCP.

🔧 Método de uso

Verificar la instalación

mcp__csmar__csmar_health_check()

Exploración básica de datos

# 列出所有可用数据库（约240个）
mcp__csmar__csmar_list_databases()

# 查看"财务报表"数据库中的表
mcp__csmar__csmar_list_tables(database_name="财务报表")

# 查看"FS_Combas"表的字段
mcp__csmar__csmar_list_fields(table_name="FS_Combas")

# 预览表数据（前几行）
mcp__csmar__csmar_preview(table_name="FS_Combas")

Ejemplo de consulta de datos

# 查询财务报表数据
mcp__csmar__csmar_query(
    table_name="FS_Combas",
    columns=["Stkcd", "ShortName", "Accper", "Typrep", "A001000000"],
    condition="Stkcd like '3%' and Typrep='A'",
    start_time="2020-01-01",
    end_time="2021-12-31",
    limit=5
)

# 查询记录数量
mcp__csmar__csmar_query_count(
    table_name="FS_Combas",
    condition="Stkcd like '3%'",
    start_time="2020-01-01",
    end_time="2021-12-31"
)

# 获取股票数据
mcp__csmar__get_stock_data(
    stock_code="000001",
    start_date="2024-01-01",
    end_date="2024-12-31",
    frequency="daily"
)

# 获取财务数据
mcp__csmar__get_financial_data(
    stock_code="000001",
    start_date="2020-01-01",
    end_date="2024-12-31",
    indicators=["A001000000", "A002000000"]
)

# 获取公司信息
mcp__csmar__get_company_info(stock_code="000001")

🛠️ Herramientas disponibles

Nombre de la herramienta

Descripción

Parámetros

csmar_health_check

Comprobar el estado de salud del servicio

Ninguno

csmar_login

Iniciar sesión en la cuenta de CSMAR

account, pwd, lang

csmar_list_databases

Listar bases de datos accesibles

Ninguno

csmar_list_tables

Listar tablas en la base de datos

database_name

csmar_list_fields

Listar campos en la tabla

table_name

csmar_query

Consulta de datos general

table_name, columns, condition, start_time, end_time, limit, format

csmar_preview

Vista previa de datos de la tabla

table_name

csmar_query_count

Consultar número de registros

table_name, columns, condition, start_time, end_time

get_stock_data

Obtener datos de negociación bursátil

stock_code, start_date, end_date, frequency

get_financial_data

Obtener datos financieros

stock_code, start_date, end_date, indicators

get_company_info

Obtener información básica de la empresa

stock_code

📁 Estructura del proyecto

csmar-mcp-server/
├── src/
│   ├── index.js              # MCP 服务器主文件
│   └── python_client.py      # Python 客户端
├── config/
│   ├── .env.example          # 环境变量示例
│   └── .mcp.json             # MCP 配置示例
├── docs/
│   ├── CSMAR_MCP_配置完成报告.md
│   ├── 快速开始指南.md
│   └── CSMAR机构账号配置指南.md
├── examples/
│   └── test_input.json       # 测试输入示例
├── package.json              # Node.js 依赖
├── README.md                 # 本文件
└── .gitignore               # Git 忽略文件

🔍 Recomendaciones de bases de datos

Bases de datos comunes

  • Estados financieros: 财务报表, FS_Combas, FS_Comins, FS_Comscfd

  • Negociación bursátil: 股票市场交易数据, 股票日行情

  • Información corporativa: 公司基本信息, 上市公司基本信息

  • Macroeconomía: 宏观经济数据库

Rango de tiempo de los datos

  • Estados financieros: 2018-2022

  • Datos relacionados con IA: 2024-2025

  • Negociación bursátil: Actualización en tiempo real

⚠️ Notas importantes

Limitaciones de consulta

  • Máximo 200,000 registros por vez: Los conjuntos de datos grandes requieren consultas paginadas.

  • Límite de tasa de 30 minutos para la misma condición: Evite consultas frecuentes con las mismas condiciones.

  • Formato de tiempo: Debe utilizar el formato "YYYY-MM-DD".

Ejemplo de consulta paginada

# 第1页
condition = "Stkcd like '3%' limit 0,200000"
# 第2页
condition = "Stkcd like '3%' limit 200000,200000"

mcp__csmar__csmar_query(
    table_name="FS_Combas",
    columns=["Stkcd", "ShortName", "Accper", "Typrep"],
    condition=condition
)

🐛 Solución de problemas

Preguntas frecuentes

1. "El servidor MCP no responde"

  • Confirme que Claude Code se haya reiniciado.

  • Verifique que la ruta del archivo de configuración sea correcta.

  • Pruebe manualmente el cliente de Python:

    echo '{"action":"check_availability","params":{}}' | python src/python_client.py --once

2. "La base de datos no existe"

  • Use csmar_list_databases() para obtener el nombre exacto.

  • Verifique si el nombre de la base de datos contiene espacios.

  • Confirme que la cuenta tenga permisos de acceso a esa base de datos.

3. Los resultados de la consulta están vacíos

  • Verifique si el rango de tiempo es correcto.

  • Valide la sintaxis de la condición de consulta.

  • Use preview() primero para ver el formato de los datos.

4. Error al importar el SDK de CSMAR

  • Confirme que el SDK de CSMAR-PYTHON esté instalado correctamente.

  • Ejecute python src/python_client.py para ver información detallada del error.

Archivos de registro

  • Registro del cliente de Python: Salida a través de stderr.

  • Registro del servidor MCP: Salida a través de stderr.

🔄 Registro de cambios

v1.1.0 (2026-04-15)

  • ✨ Nuevo modo de proceso de Python persistente, mejorando significativamente el rendimiento.

  • ✨ Nueva herramienta de comprobación de salud csmar_health_check.

  • ✨ Implementación de las herramientas get_stock_data, get_financial_data, get_company_info.

  • 🔧 Corrección del problema de codificación rígida de la ruta de Python, detección automática de site-packages.

  • 🔧 Corrección del problema de importación de zod.

  • 🔧 Adición de mecanismo de reintento de solicitudes.

  • 🔧 Adición de soporte para cierre elegante.

v1.0.0

  • 🎉 Versión inicial.

🤝 Contribuciones

¡Las propuestas de Issues y Pull Requests son bienvenidas!

  1. Haga un Fork del proyecto.

  2. Cree una rama de funciones (git checkout -b feature/amazing-feature).

  3. Confirme los cambios (git commit -m 'Add amazing feature').

  4. Envíe a la rama (git push origin feature/amazing-feature).

  5. Cree un Pull Request.

📄 Licencia

Este proyecto utiliza la licencia MIT - consulte el archivo LICENSE para obtener más detalles.

🙏 Agradecimientos

  • CSMAR (Guotai'an): Por proporcionar servicios de datos financieros.

  • Anthropic: Por desarrollar el Protocolo de Contexto de Modelo (MCP).

  • Claude Code: Por ser un excelente entorno de programación con IA.

📞 Soporte

  • Soporte oficial de CSMAR: service@gtadata.com, 400-888-3636

  • Issues del proyecto: GitHub Issues

  • Documentación: Consulte la guía detallada en el directorio docs/.

💡 Sugerencia: ¡Antes de comenzar, asegúrese de haber configurado correctamente su cuenta de CSMAR y las variables de entorno!

Available Tools

11 tools
csmar_health_checkA

检查 CSMAR 服务健康状态

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

Without annotations, the description is minimal. It implies a read-only check but lacks details on what constitutes 'healthy' or potential effects if the service is down. However, for a health check tool, the behavior is somewhat self-evident.

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 a single, front-loaded sentence with no extraneous information, efficiently conveying the tool's 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?

Given the simplicity (no parameters, no output schema), the description is largely complete for understanding the tool's function. It could be enhanced by mentioning the expected output (e.g., a status string), but it is sufficient.

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?

There are no parameters, so the description does not need to add parameter meaning. The baseline for 0 parameters is 4, and the description adequately covers the absence of inputs.

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 checks CSMAR service health status, using a specific verb and resource. It distinguishes itself from sibling tools that deal with data operations like listing databases or querying.

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?

No guidance is given on when to use this tool versus alternatives, such as using it as a prerequisite before other operations or when service issues are suspected.

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

csmar_list_databasesA

列出用户有权访问的 CSMAR 数据库

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are present, so the description carries full responsibility for behavioral disclosure. It does not mention whether authentication is required, error behavior, or if the operation is read-only. Since this is a list operation, it is likely safe, but the description does not confirm this.

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 a single, concise sentence that conveys the essential purpose without any superfluous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers the basic purpose, it lacks context about preconditions (e.g., does the user need to be logged in via csmar_login?) and the nature of the output. Given no output schema, some description of the return format would improve completeness.

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?

There are no parameters, so the input schema is trivially covered. The description does not need to add parameter meaning. Baseline for zero parameters is 4.

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 verb 'list' and the resource 'databases', specifying 'that the user has access to'. This distinguishes it from siblings like csmar_list_tables and csmar_list_fields, which list different entities.

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?

No guidance is provided on when to use this tool compared to alternatives. With siblings like csmar_list_fields and csmar_list_tables, explicit usage context would help an agent decide which list tool to invoke.

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

csmar_list_fieldsB

列出指定表中的所有字段

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameYes表名称

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond the obvious listing operation. It lacks information on authentication, side effects, or constraints.

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 a single sentence with no wasted words, effectively conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is adequate but lacks context on output format, pagination, or error handling, which could be helpful.

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%, and the parameter 'table_name' is already described in the schema. The description adds no additional meaning beyond what the schema provides, aligning with the baseline of 3.

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 lists all fields in a specified table, with a specific verb ('list') and resource ('fields'). It distinguishes from sibling tools like csmar_list_tables and csmar_list_databases.

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?

No guidance on when to use this tool versus alternatives. The description only states what it does, without providing context for usage or exclusions.

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

csmar_list_tablesB

列出指定数据库中的所有表

ParametersJSON Schema
NameRequiredDescriptionDefault
database_nameYes数据库名称

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden. It only states 'list tables' without disclosing any behavioral traits (e.g., read-only, error handling, side effects). This is insufficient for a tool with no annotation coverage.

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 description is a single, short sentence that efficiently conveys the core purpose. However, it could add more context without becoming verbose, hence not a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description is minimally adequate. It explains what it does and the parameter, but lacks details on return format, error cases, or behavior, leaving gaps.

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 coverage is 100%, and the parameter 'database_name' has a description in the schema. The tool description does not add any extra semantic value beyond the schema; baseline 3 is appropriate.

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 action (list tables) and scope (in a specified database). It distinguishes from siblings like csmar_list_databases (lists databases) and csmar_list_fields (lists fields).

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?

No guidance on when to use this tool vs alternatives, such as prerequisites or context. The description merely states the action without contextual usage advice.

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

csmar_loginC

登录 CSMAR 账户

ParametersJSON Schema
NameRequiredDescriptionDefault
accountYes用户名/已验证电话/已验证邮箱
pwdYes密码
langNo语言: 0=中文, 1=英文

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, and the description only says 'log in', omitting important behavioral details such as session creation, authentication state, error handling, or rate limits. The description carries the full burden but fails to disclose these traits.

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 description is a single concise sentence. While it efficiently conveys the core purpose, it lacks any structured detail (e.g., bullet points) that could improve scannability. Still, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is authentication-related and has no output schema, the description fails to cover important context such as what happens on successful/failed login, whether it sets a session token, or how to handle credentials. This is a notable gap for a login operation.

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 coverage is 100% with descriptions for all three parameters (account, pwd, lang). The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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 clearly states the tool logs into a CSMAR account (specific verb and resource). Though no sibling differentiation is provided, the sibling tools are data retrieval functions, making the purpose distinct.

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?

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, order of operations, or context (e.g., must be called before other tools).

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

csmar_previewC

预览表数据 (前几行)

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameYes表名称

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states 'preview' without explaining if it is read-only, limits rows, or how it handles errors. Minimal transparency.

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 description is concise and front-loaded, using a single line to convey the tool's purpose. No wasted words, though structure could be improved with sections for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple preview tool, the description covers the basic purpose but omits details like return format, row limit, or behavior. It is adequate but not fully complete.

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 coverage is 100% with a clear description for the single parameter 'table_name'. The tool description adds no additional meaning beyond the schema, earning the baseline score of 3.

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 clearly states it previews table data (first few rows), using a specific verb and resource. It is distinguishable from sibling tools like csmar_query (full query) and csmar_query_count (count), but does not explicitly differentiate.

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?

No guidance provided on when to use this tool versus alternatives. Sibling tools exist for full queries and counts, but the description lacks any context on prerequisites or scenarios.

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

csmar_queryD

通用 CSMAR 数据查询

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameYes表名称
columnsNo要查询的字段列表
conditionNo查询条件 (SQL WHERE 子句)
start_timeNo开始时间 (YYYY-MM-DD)
end_timeNo结束时间 (YYYY-MM-DD)
limitNo返回记录数限制
formatNo返回格式

TDQS

D1.7/5.0
Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, authorization needs, rate limits). The term 'query' implies read-only, but it is not explicitly stated, leaving the agent without safety or usage context.

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

Conciseness2/5

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

The description is a single short sentence, but it is under-specified and lacks structure. It fails to convey essential information, making it more of a placeholder than a concise description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 7 parameters, multiple sibling tools, and no output schema or annotations, the description is completely inadequate. It does not explain what CSMAR is, how queries are executed, or any constraints, severely limiting an agent's ability to use the tool correctly.

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

Parameters2/5

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

Schema coverage is 100%, but the description adds no additional meaning beyond the parameter names and types. It does not explain how the parameters interact, provide examples, or clarify the purpose of SQL WHERE clauses or return formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description is '通用 CSMAR 数据查询' which translates to 'General CSMAR data query'. It is vague and does not specify what specific data or operations are covered, nor does it differentiate from sibling tools like csmar_preview or csmar_query_count.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., csmar_preview, csmar_query_count). The description lacks any context about prerequisites or use cases.

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

csmar_query_countC

查询满足条件的记录数量

ParametersJSON Schema
NameRequiredDescriptionDefault
table_nameYes表名称
columnsNo字段列表
conditionNo查询条件
start_timeNo开始时间
end_timeNo结束时间

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided; the description does not disclose behavioral traits such as whether it is read-only, any limitations, or performance implications. The agent is left with no information beyond the basic function.

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?

A single sentence that is clear and front-loaded. No extraneous information, though additional details could be added without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple count query, the description combined with the schema is minimally adequate. However, missing usage guidelines and behavioral context make it incomplete for an AI agent to use correctly without extra knowledge.

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 coverage is 100% with Chinese descriptions for all parameters. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states it queries the count of records, distinguishing it from sibling csmar_query which likely returns actual records. However, it does not explicitly differentiate between the two.

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?

No guidance on when to use this tool versus alternatives like csmar_query or csmar_preview. The description implies counting, but does not advise on context.

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

get_company_infoC

获取公司基本信息

ParametersJSON Schema
NameRequiredDescriptionDefault
stock_codeYes股票代码

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'get basic company info', implying a read operation, but gives no details on scope, side effects, or return format.

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 description is extremely concise (one sentence), which is front-loaded but lacks substance. It earns its place minimally, but could be more informative without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and sibling tools that may overlap, the description is incomplete. It does not clarify what 'basic company info' includes, leaving ambiguity about its domain.

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?

The input schema covers 100% of parameters with a clear description for 'stock_code'. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the action (获取) and resource (公司基本信息), identifying it as a retrieval tool for basic company info. However, it does not differentiate from sibling tools like get_financial_data or get_stock_data.

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 description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context for its use.

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

get_financial_dataC

获取 CSMAR 财务数据

ParametersJSON Schema
NameRequiredDescriptionDefault
stock_codeYes股票代码
start_dateYes开始日期 (YYYY-MM-DD)
end_dateYes结束日期 (YYYY-MM-DD)
indicatorsNo财务指标列表

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden for behavioral transparency. It does not mention any side effects, authorization needs, rate limits, or data scope (e.g., whether it returns all available financial indicators or just those specified).

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

Conciseness2/5

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

The description is extremely short (one sentence), but it sacrifices completeness for brevity. It does not provide enough context to be useful, falling into under-specification rather than effective conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters and no output schema or annotations, the description is incomplete. It does not explain the return format, how results are paginated, or any dependencies like login requirements, leaving significant gaps for an agent to use it correctly.

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?

The input schema covers 100% of parameters with descriptions, so the schema already explains each parameter. The description adds no additional semantic context beyond what the schema provides, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description '获取 CSMAR 财务数据' states the verb 'get' and resource 'CSMAR financial data', giving a general idea of the tool's purpose. However, it does not distinguish this tool from similar siblings like 'get_stock_data' or 'csmar_query', which may retrieve overlapping or different data.

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 description provides no guidance on when to use this tool versus its siblings (e.g., get_stock_data, csmar_query). There is no information about prerequisites, such as requiring a session from csmar_login, or when not to use it.

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

get_stock_dataC

获取 CSMAR 股票交易数据

ParametersJSON Schema
NameRequiredDescriptionDefault
stock_codeYes股票代码
start_dateYes开始日期 (YYYY-MM-DD)
end_dateYes结束日期 (YYYY-MM-DD)
frequencyNo数据频率

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are present, and the description does not disclose any behavioral traits such as return format, side effects, authentication requirements, or rate limits. For a tool with no output schema, this is a significant gap.

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 description is a single concise sentence, but it lacks any structural formatting. While minimal, it is not overly verbose, but the brevity sacrifices completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters and no output schema, the description is too brief. It does not explain what the returned data represents, how errors are handled, or any constraints like date range limits.

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?

The input schema has 100% description coverage for all 4 parameters, each with Chinese descriptions. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 clearly states the verb '获取' (get) and resource 'CSMAR 股票交易数据' (CSMAR stock trading data), distinguishing it from siblings like get_company_info and get_financial_data. However, it lacks specificity about what exactly constitutes 'stock trading data'.

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?

No guidance is provided on when to use this tool versus alternatives. Sibling tools such as get_financial_data or get_company_info exist, but the description does not help the agent decide which to choose.

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. Dates show when Glama detected each change.

  1. 11 tool updatesv1.2.0
    • First observedcsmar_health_check
    • First observedcsmar_list_databases
    • First observedcsmar_list_fields
    • First observedcsmar_list_tables
    • First observedcsmar_login
    • First observedcsmar_preview
    • First observedcsmar_query
    • First observedcsmar_query_count
    • First observedget_company_info
    • First observedget_financial_data
    • First observedget_stock_data
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (e.g., listing databases vs tables vs fields, login vs query). However, the three 'get_*' tools (get_company_info, get_financial_data, get_stock_data) could overlap with the generic csmar_query since all fetch data, but descriptions and specific naming mitigate confusion.

Naming Consistency3/5

Tools are in snake_case, but eight are prefixed with 'csmar_' while three (get_company_info, get_financial_data, get_stock_data) lack this prefix. This inconsistency breaks the pattern and could cause agents to misgroup tools.

Tool Count5/5

11 tools is appropriate for a data retrieval service covering login, database exploration, querying, counting, previewing, and specific data endpoints. Each tool earns its place without being excessive.

Completeness4/5

The tool set covers core CRUD-like operations for data retrieval: listing databases/tables/fields, querying, counting, previewing, and accessing specific data types. Missing write/update/delete operations, but those likely fall outside the scope of a read-only CSMAR data service.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • FinData MCP Server

    zlinzzzz
    A
    license
    A
    quality
    D
    maintenance
    Provides professional financial data access for LLMs via MCP, supporting providers like Tushare, Wind, and DataYes.
    14
    58
    Apache 2.0

  • cn-financial-mcp

    ccq1
    A
    license
    Not graded
    quality
    F
    maintenance
    Provides access to Chinese mainland financial data including A-stock quotes, financial statements, industry analysis, and macroeconomics through 42 MCP tools, with automatic data source fallback and no API key required.
    40
    Apache 2.0

  • CSMAR MCP Server

    luckyxpw
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables access to the CSMAR financial database via MCP, providing tools for querying financial data, stock data, company info, and more through natural language in compatible clients like Codex and Claude Code.
    18
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ww11-max/CSMAR-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server