Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sensors MCP Server query the number of page views for the last 7 days"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
基于 MCP（Model Context Protocol） 的神策分析数据服务，让 AI 助手通过自然语言直接查询和分析神策平台中的用户行为数据。
工具 | 说明 |
| 获取当前神策配置信息（调试用） |
| 验证 API 连通性和认证有效性 |
| 获取项目中的全部事件列表 |
| 获取事件标签分类信息 |
| 获取指定事件的属性定义 |
| 获取所有事件的属性列表 |
| 事件分析查询（次数、人数、维度拆分、筛选过滤） |
Related MCP server: elasticsearch-mcp
npm install复制 .env.example 为 .env，填写你的神策分析配置：
cp .env.example .envSA_URL=https://your-sensors-analytics-url
SA_PROJECT=your_project_name
SA_API_KEY=your_api_key
SA_API_SECRET=your_api_secret # 可选API Key 在神策后台「项目管理 → 数据接口」中获取。
# 编译
npm run build
# 生产模式
npm start
# 开发模式（直接运行 TypeScript，改完代码重启即可）
npm run dev在 MCP 设置中添加 Server，配置启动命令：
{
"mcpServers": {
"sensors": {
"command": "node",
"args": ["/path/to/SensorsMCPServer/dist/index.js"],
"env": {
"SA_URL": "https://your-sensors-analytics-url",
"SA_PROJECT": "your_project_name",
"SA_API_KEY": "your_api_key"
}
}
}
}MCP Server 使用 stdio 协议通信，由客户端启动和管理进程，无需手动运行。
推荐使用 MCP Inspector 进行调试：
npx @modelcontextprotocol/inspector node dist/index.js启动后访问 http://localhost:6274，可以手动调用工具、查看请求和响应。
接入 MCP 客户端后，直接用自然语言提问即可：
查询上月左侧菜单点击事件的次数和人数web_workgroup_nav_menu_cli 事件有哪些属性？查询上月左侧菜单点击情况，按用户和菜单名拆分AI 会自动探索事件元数据、构建查询参数、调用 API 并解读结果。
src/
├── index.ts # MCP Server 入口，工具注册与请求路由
├── config.ts # 环境变量配置管理
└── tools/
├── event-meta.ts # 事件列表与标签查询
├── property-meta.ts # 事件属性查询
└── segmentation.ts # 事件分析报告查询运行环境：Node.js（ES2022+）
开发语言：TypeScript 5.x
MCP SDK：@modelcontextprotocol/sdk ^0.6.0
通信协议：stdio
API 规范：神策分析 OpenAPI v3
认证方式：Header 认证（api-key + sensorsdata-project）
ISC
获取指定事件的属性列表
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | 事件名称列表 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions it retrieves a list. No disclosure of side effects, authorization needs, or other behavioral traits is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and does not provide much value beyond restating the tool's name and parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 fails to explain the return format or provide context relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documentation coverage is 100% for the only parameter 'events', which has a clear description. The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取指定事件的属性列表' clearly states the verb 'get' and the resource 'property list of specified events', and it distinguishes from siblings like 'list_event_properties_all' by specifying 'specified events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as list_event_properties_all or other siblings. The description only states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取当前的神策配置信息（仅用于调试）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, permissions, or performance impact. The only behavioral hint is 'debugging', which is insufficient for a complete understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, self-contained sentence that efficiently conveys the tool's purpose and scope. No word is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description minimally explains the tool's function. It is adequate for a simple config retrieval, but could be more helpful by noting that it returns configuration data or is safe to call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to add parameter semantics. Schema coverage is 100%, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves current Sensors configuration and explicitly marks it for debugging only. This distinguishes it from sibling tools like get_event_properties or verify_sensors_config, which target different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage is for debugging ('仅用于调试'), providing clear context. However, it does not explicitly state when not to use it or mention alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取所有事件的属性列表 (可能比较慢)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the burden. It only warns about potential slowness ('可能比较慢'), but does not disclose other behavioral traits like read-only nature, authentication needs, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded and efficient. However, it could include more useful information without reducing conciseness, such as the output format or scope differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description provides the basic purpose and a performance hint. However, it lacks details on the return format and does not explicitly differentiate from sibling tools, leaving ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the baseline is 4. However, the description adds only the operation name and a speed note, with no detail on what the returned properties look like. It is adequate but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists properties for all events, which is a specific action. It implicitly distinguishes from sibling 'get_event_properties' which likely targets a single event, but does not explicitly mention this difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_event_properties'. No when-not-to-use or context hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取神策分析事件列表 (元数据)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 nature, authentication needs, rate limits, data freshness). It only restates the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks any structure or additional context. It conveys minimal information, barely earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and no details about return format or pagination, the description is incomplete for a tool that lists events. The agent would lack necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is trivially 100%. The description adds no parameter information because none exist, which is appropriate. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '获取神策分析事件列表 (元数据)' (Get list of Sensors Analytics events (metadata)), which clearly identifies the verb (get) and resource (event list). The resource is distinct from siblings like list_event_properties_all or list_event_tags, but no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description lacks any context about prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取神策分析事件标签列表 (元数据)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'get list', omitting behavioral traits like read-only, authentication needs, or pagination. Fails to disclose any constraints or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with the key action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at what the response contains. It mentions 'metadata' but lacks details on format or structure. Adequate for a simple list but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% trivially. Description adds meaning by specifying the resource is event tags (metadata), which is useful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists event tags (metadata) with a specific verb '获取' and resource '事件标签列表'. Clearly distinguishes from siblings like list_events_all and list_event_properties_all by focusing on tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 siblings. Lacks any context about prerequisites or when to prefer this over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询事件分析报告。参数直接对应神策 OpenAPI 的 SegmentationReportRequest 结构。
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes | 查看的时间粒度：HOUR（按小时）、DAY（按天）、WEEK（按周）、MONTH（按月）、YEAR（按年） | |
| limit | No | 返回的最大行数，-1 表示返回尽量多的数据 | |
| filter | No | 全局过滤条件，格式为 {"relation":"AND","conditions":[{"field":"event.$Anything.$country","function":"equal","params":["中国"]}]} | |
| rollup | No | 查询汇总或者明细数据，true 为汇总，false 为明细 | |
| to_date | Yes | 查询日期范围的结束时间，格式为 yyyy-MM-dd，例如 2026-01-31 | |
| measures | Yes | 要查询的指标集合，例如 [{"event_name":"$MPShow","aggregator":"general"}] | |
| by_fields | No | 按什么维度查看，例如 ["event.$Anything.$country", "user.province"] | |
| from_date | Yes | 查询日期范围的开始时间，格式为 yyyy-MM-dd，例如 2026-01-01 | |
| use_cache | No | 是否使用缓存 | |
| sampling_factor | No | 抽样因子，64 为全量，32 为 1/2 抽样 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention side effects, authentication needs, rate limits, or read-only nature. The tool's behavior beyond querying is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence defines the purpose, the second provides critical mapping info. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the description lacks return value explanation, error handling, and examples. For a complex parameter set (10 params, nested objects) with no output schema, the description is too minimal to fully inform an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds that parameters map directly to the Sensors OpenAPI structure, which provides context but does not substantively enhance understanding beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries event analysis reports, with a specific reference to the Sensors OpenAPI structure. It distinguishes itself from siblings that deal with properties/events rather than reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 implies usage for segmentation reports but does not specify prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
验证神策 OpenAPI 配置是否正确
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only states the purpose without indicating side effects, authentication requirements, or whether the tool is read-only. A verification tool likely makes a network call and returns a boolean or error, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose without any extraneous information. It is appropriately sized for a tool with no parameters and no complex behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks important context. For a verification tool, the agent would benefit from knowing the output format (e.g., boolean, error message) or any conditions that might cause failure. Since there is no output schema, the description should hint at what the result looks like. Currently it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so the baseline is 4. The description does not need to add parameter info. It correctly omits parameter details since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: verifying the correctness of the Sensors OpenAPI configuration. It uses a specific verb ('verify') and resource ('sensors config'), and it distinguishes from the sibling tool 'get_sensors_config', which retrieves the config. However, the description is in Chinese, which may limit clarity for non-Chinese agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention any prerequisites, limitations, or conditions under which verification is appropriate. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_event_propertiesget_sensors_configlist_event_properties_alllist_event_tagslist_events_allquery_segmentation_reportverify_sensors_configEach tool targets a distinct aspect: specific event properties vs all properties, events vs tags, config retrieval vs verification, and a single query report. No overlapping purposes.
All tools follow a consistent verb_noun pattern in English using snake_case: get_, list_, query_, verify_. The verbs appropriately reflect the action.
7 tools is well-scoped for a Sensors analytics server, covering configuration, metadata listing, and a core reporting function without excess or deficiency.
Covers essential operations: config management, event/property/tag listing, and a segmentation report query. Minor gap in other report types, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
Ask questions in plain language, get answers from your business database. No SQL required.
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pein892/SensorsMCPServer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
