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., "@CSDK Docs MCP Server Find React examples of useExecuteQuery"
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.
An MCP server that provides both structured browsing and TF-IDF search over the Sisense Compose SDK documentation. Works with Claude Code, Claude Desktop, or any MCP client.
Tool | Description |
| TF-IDF search over 1,700+ doc chunks. Returns the most relevant documentation for any query. |
| Browse docs by category ( |
| Lists all available categories, files, and their descriptions. |
The server also exposes structured resources that MCP clients can browse directly:
Resource | URI | Description |
Full index |
| Complete documentation index across all categories |
Category index |
| List files in a category (e.g., |
Doc file |
| Read a specific doc file (e.g., |
Search (search_csdk_docs) — when you have a question and need the most relevant chunks. Uses TF-IDF scoring across 1,700+ pre-indexed chunks.
Browse (browse_csdk_docs or resources) — when you know which category or file you need. Returns the full structured document, organized by the monorepo's own folder structure.
The search_csdk_docs tool also supports:
Framework filter — restrict results to React, Vue, or Angular docs
Code context (optional) — pass a code snippet and it extracts SDK imports, components, hooks, and factories to boost relevant results
Related MCP server: Code Context Manager
git clone https://github.com/pmorris24/csdk-docs-mcp.git
cd csdk-docs-mcp
npm install && npm run buildThe repo includes .mcp.json — just open Claude Code in the repo directory and the server connects automatically.
Or add to any project's .mcp.json:
{
"mcpServers": {
"csdk-docs": {
"command": "node",
"args": ["/absolute/path/to/csdk-docs-mcp/dist/index.js"]
}
}
}Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"csdk-docs": {
"command": "node",
"args": ["/absolute/path/to/csdk-docs-mcp/dist/index.js"]
}
}
}Once connected, Claude will automatically use the tools when it needs SDK information. Just ask naturally:
"How do I query data with useExecuteQuery and display it in a ColumnChart?"
"What are the props for ChartWidget?"
"How do I embed a Fusion dashboard using DashboardById?"
"How do I customize chart colors with styleOptions?"
"How do I use onBeforeRender to modify Highcharts options directly?"
"How do I build a custom dashboard layout with useComposedDashboard?"This works alongside the official sisense-mcp-server:
Server | What it does |
Sisense MCP | Queries your Sisense instance — get data sources, fields, build charts |
This server | Searches SDK documentation — how to write the code to use that data |
Use both together: Sisense MCP tells Claude what data you have, this server tells Claude how to build the UI with the Compose SDK.
The server respects Sisense SDK documentation tags:
Tag | Behavior |
| Completely excluded from search results and browse output |
| Completely excluded from search results and browse output |
| Included but flagged with a warning: "This API is marked as beta. It may change without notice." |
| Included normally (indicates Fusion embedding features) |
Docs are pulled directly from the official Sisense Compose SDK monorepo (docs-md/sdk/). When Sisense releases a new SDK version:
./scripts/update-docs.sh
npm run buildTo pull from a specific branch:
./scripts/update-docs.sh --branch devRun the validation script after updating docs to verify completeness:
./scripts/validate-docs.shThis checks:
chunks.json exists and has expected chunk count
All framework categories have doc files and INDEX.md
Key files are present and non-empty
No @internal/@sisenseInternal content leaked into public docs
Framework parity (React, Vue, Angular have equal file counts)
Build output is up to date
React
Vue
Angular
Browse CSDK documentation by category. Returns a list of available doc files in a category, or the full content of a specific file. Use this when you know which category or file you need, instead of searching.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Specific file to read, e.g. 'charts.md' or 'dashboards.md'. Omit to list all files in the category. | |
| category | Yes | Documentation category to browse. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently states what the tool returns (list or file content) and how the optional file parameter changes that behavior. It implies a read-only operation without explicitly claiming side effects, which is sufficient for a documentation browsing tool.
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 two sentences long, front-loads the purpose and return behavior, and includes a usage note. Every sentence earns its place with no redundancy or vague filler.
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?
The tool is simple (2 parameters, no output schema), and the description covers the core purpose, return modes, and usage context. The sibling tools provide contrast, and the description explains enough for an agent to select and invoke it correctly. Minor gaps (e.g., error handling) are not critical for this use case.
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 100% coverage with detailed descriptions for both parameters, including the example values and the 'omit to list all files' behavior. The description adds no new parameter information 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Browse CSDK documentation by category') and specifies the two possible return types: a list of files or full content of a specific file. It also distinguishes from the sibling tool search_csdk_docs by positioning it as a direct browsing alternative, satisfying the goal of differentiating tools.
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 gives a clear usage trigger: 'Use this when you know which category or file you need, instead of searching.' This explicitly tells the agent when to use this tool and when to prefer search, providing practical guidance beyond what the schema offers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available documentation categories and files. Use this to understand the documentation structure before browsing or searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately describes the operation as listing categories and files, which implies a read-only action with no side effects. While it does not detail output format or limitations, for a simple list tool this is adequate and concise.
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 two sentences, front-loaded with the action('List all available...') followed by a usage note. Every word serves a purpose and there is no fluff.
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 the tool's simplicity (no parameters, no output schema, no annotations), the description adequately explains what it does and why to use it. It is complete enough for an agent to select and invoke it correctly in the context of browsing or searching documentation.
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 zero parameters, so there is nothing to describe. Per the rubric, the baseline for no-parameter tools is 4, and the description adds context about understanding the documentation structure, which is helpful.
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 lists all available documentation categories and files, and explicitly positions it as a precursor to browsing or searching, distinguishing it from sibling tools search_csdk_docs and browse_csdk_docs.
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 says 'Use this to understand the documentation structure before browsing or searching,' which provides explicit when-to-use guidance and implies the alternatives (browse and search tools). This gives clear context for selecting this tool first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Sisense Compose SDK documentation using TF-IDF search. Returns the most relevant documentation chunks for a given query. Use this for specific questions where you need targeted results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query — e.g. 'how to create a bar chart with filters' or 'useExecuteQuery props' | |
| framework | No | Filter results to a specific framework. Omit to search all. | |
| max_results | No | Number of results to return (default 8). | |
| code_context | No | Optional code snippet to extract SDK identifiers from — improves relevance by detecting imports, components, hooks, and factories in use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the TF-IDF search mechanism and that it returns documentation chunks, which is transparent about core behavior. However, it does not explicitly state side effects or safety (e.g., read-only), though this is implied for a search operation.
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 two sentences, front-loaded with the action, and each sentence adds value. The phrase 'Search ... using TF-IDF search' has slight redundancy, but it is minor and does not detract from overall conciseness.
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?
The description adequately covers purpose, usage, and return type ('documentation chunks'). There is no output schema, but the description gives a reasonable expectation of what the tool returns. For a search tool with straightforward parameters, this is sufficient, though it could mention result structure in more detail.
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 description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides, such as query examples or filtering options, but the schema descriptions are thorough enough.
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 searches Sisense Compose SDK documentation using TF-IDF search and returns relevant chunks. It uses a specific verb ('search') and resource ('documentation'), and distinguishes itself from sibling tools like browse_csdk_docs and list_csdk_topics by focusing on targeted search rather than browsing or listing.
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 usage context: 'Use this for specific questions where you need targeted results.' This implies the tool is ideal for focused queries but does not explicitly name alternatives or exclusions, making it clear but not fully comprehensive.
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.
v1.0.0browse_csdk_docslist_csdk_topicssearch_csdk_docsEach tool serves a distinct purpose: searching for relevant chunks, browsing by category/file, and listing the overall structure. There is no ambiguity between search, browse, and list operations.
All tool names follow a consistent verb_csdk_docs pattern (search_, browse_, list_). This predictable structure makes it easy to infer function.
Three tools is well-scoped for a documentation server: one to discover structure, one to browse content, and one to search. Each tool earns its place with no redundancy.
For a documentation access domain, this covers the full lifecycle: understand the structure (list), retrieve content (browse), and answer specific queries (search). No obvious gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Apple Developer Documentation with Semantic Search, RAG, and AI reranking for MCP clients
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pmorris24/csdk-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
