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., "@Synergy/DE MCP Server search for documentation on how to use the SELECT statement"
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.
A read-only Model Context Protocol (MCP) server that exposes Synergy/DE documentation as tools and resources, making it easy to search, retrieve, and browse documentation topics from Cursor and other MCP clients.
Full-text search across Synergy/DE documentation with relevance scoring
Topic retrieval with chunked content optimized for LLM consumption
Related topics navigation (previous, next, parent, and related links)
Section browsing to discover topics by category
Version support for different Synergy/DE documentation versions
Intelligent caching to minimize network requests and improve performance
Online and local documentation support (hybrid mode available)
MCP Resources for direct topic and section access in Cursor
Related MCP server: Dedalus MCP Documentation Server
Node.js 18.0.0 or higher (provides built-in fetch API for HTTP requests)
npm or pnpm package manager
Cursor (for MCP integration) or another MCP-compatible client
Clone this repository:
git clone https://github.com/h0ck3ystyx/synergyde-mcp.git
cd synergyde-mcpInstall dependencies:
npm install
# or
pnpm installBuild the project:
npm run buildConfigure environment variables (optional):
cp .env.example .env
# Edit .env with your preferencesThe server can be configured via environment variables. All variables are optional and have sensible defaults.
Variable | Description | Default | Required |
| Base URL for online documentation |
| No |
| Default documentation version to use |
| No |
| Path to local documentation directory | (none) | No |
| Directory for caching parsed topics |
| No |
| Logging level: |
| No |
SYNERGYDE_DOC_BASE_URL: The base URL for the Synergy/DE documentation site. Should end with a trailing slash (automatically added if missing).
SYNERGYDE_DOC_DEFAULT_VERSION: The default version to use when no version is specified in tool calls. Common values: "latest", "v111", "v112", etc.
SYNERGYDE_LOCAL_DOC_PATH: If provided, enables local documentation support. The path must be readable and point to a directory containing local documentation files. When set, the server operates in "hybrid" mode, preferring local docs but falling back to online docs if a topic isn't found locally.
SYNERGYDE_CACHE_DIR: Directory where parsed topics are cached on disk. The directory will be created automatically if it doesn't exist. Cached topics are stored as JSON files keyed by version and topic ID.
LOG_LEVEL: Controls the verbosity of logging. Use debug for detailed information during development, info for normal operation, warn for warnings only, or error for errors only.
.env File# Use online documentation with latest version
SYNERGYDE_DOC_BASE_URL=https://www.synergex.com/docs/
SYNERGYDE_DOC_DEFAULT_VERSION=latest
# Cache directory (relative to project root)
SYNERGYDE_CACHE_DIR=./cache
# Logging level
LOG_LEVEL=infoThe server uses stdio transport and is designed to be launched by MCP clients:
npm startThe server will:
Initialize configuration
Connect to stdio transport
Wait for MCP requests from clients
Note: The server is intended to be run by MCP clients (like Cursor), not directly. Running it manually will cause it to wait for input on stdin.
Add the server to your Cursor MCP configuration. The configuration file location depends on your setup:
Global config: ~/.cursor/mcp.json (macOS/Linux) or %APPDATA%\Cursor\mcp.json (Windows)
Project config: .cursor/mcp.json in your project root
{
"mcpServers": {
"synergyde-docs": {
"command": "node",
"args": ["/absolute/path/to/synergyde-mcp/dist/server.js"],
"env": {
"SYNERGYDE_DOC_DEFAULT_VERSION": "latest"
}
}
}
}{
"mcpServers": {
"synergyde-docs": {
"command": "node",
"args": ["/absolute/path/to/synergyde-mcp/dist/server.js"],
"env": {
"SYNERGYDE_DOC_BASE_URL": "https://www.synergex.com/docs/",
"SYNERGYDE_DOC_DEFAULT_VERSION": "latest",
"SYNERGYDE_LOCAL_DOC_PATH": "/path/to/local/docs",
"SYNERGYDE_CACHE_DIR": "/path/to/cache",
"LOG_LEVEL": "info"
}
}
}
}Important: Use absolute paths for the server executable and any file paths in the configuration.
The server exposes the following MCP tools:
search_docsSearch documentation topics using full-text search.
Parameters:
query (required): Search query string
version (optional): Documentation version (defaults to configured default)
section (optional): Filter by section name
limit (optional): Maximum number of results (default: 10)
Returns: Array of search results with relevance scores
get_topicFetch a documentation topic by ID or URL.
Parameters:
topic_id (optional): Topic ID (e.g., "Language/variables.htm")
url (optional): Full URL to the topic page
version (optional): Documentation version
max_chunks (optional): Maximum number of chunks to return (default: 3, 0 = no limit)
Returns: Topic object with chunked content
get_related_topicsGet related topics (previous, next, parent, related links) for a given topic.
Parameters:
topic_id (required): Topic ID
version (optional): Documentation version
Returns: RelatedTopics object with navigation links
list_section_topicsList all topics in a documentation section.
Parameters:
section (required): Section name (e.g., "Language", "Reference")
version (optional): Documentation version
limit (optional): Maximum number of topics (default: 50)
Returns: Array of topic summaries
describe_docsGet metadata about available documentation.
Parameters: None
Returns: DocMetadata with versions, sections, and source type
The server exposes the following MCP resources:
URI: synergyde:topic/{topic_id} or synergyde:topic/{version}/{topic_id}
Returns plain text content of a documentation topic with metadata. Content is limited to ~8k tokens to fit within LLM context windows.
Examples:
synergyde:topic/Language/variables.htm
synergyde:topic/latest/Language/variables.htm
synergyde:topic//Language/variables.htm (explicit no version)
URI: synergyde:section/{version}/{section}
Returns a plain text index of topics in a section with titles, IDs, URLs, and summaries. Content is limited to ~8k tokens.
Examples:
synergyde:section/latest/Language
synergyde:section/v111/Reference
All tools and resources return structured error payloads with the following format:
{
code: string; // Error code (e.g., "TOPIC_NOT_FOUND", "NETWORK_ERROR")
message: string; // Human-readable error message
details?: { // Additional context
topic_id?: string;
version?: string;
// ... other fields
};
retryable?: boolean; // Whether the error is retryable
}INVALID_INPUT: Invalid input parameters (not retryable)
TOPIC_NOT_FOUND: Requested topic doesn't exist (not retryable)
SECTION_NOT_FOUND: Requested section doesn't exist (not retryable)
VERSION_NOT_FOUND: Requested version doesn't exist (not retryable)
NETWORK_ERROR: Network/HTTP error (usually retryable)
CACHE_ERROR: Cache operation failed (usually retryable)
PROVIDER_ERROR: Provider-specific error (not retryable)
INTERNAL_ERROR: Unexpected internal error (not retryable)
Server won't start:
Verify Node.js version: node --version (must be 18+)
Check dependencies: npm install
Verify TypeScript compilation: npm run build
Check logs for specific error messages
Tools return errors:
Verify network connectivity (for online provider)
Check that topic IDs are correct
Verify the documentation version exists
Check server logs for detailed error information
Cache not working:
Verify SYNERGYDE_CACHE_DIR is writable
Check file permissions on cache directory
Look for cache errors in server logs
Cursor integration issues:
Verify MCP configuration file syntax (valid JSON)
Use absolute paths for server executable
Check Cursor's MCP server status/logs
Restart Cursor after configuration changes
Verify environment variables are set correctly
src/
├── server.ts # Main MCP server entry point
├── types.ts # TypeScript type definitions
├── config.ts # Configuration and environment variables
├── tools/ # MCP tool implementations
│ ├── search-docs.ts
│ ├── get-topic.ts
│ ├── get-related-topics.ts
│ ├── list-section-topics.ts
│ └── describe-docs.ts
├── resources/ # MCP resource handlers
│ ├── topic-resource.ts
│ └── section-resource.ts
└── lib/
├── providers/ # Documentation providers (online/local/hybrid)
├── parser/ # HTML parsing and chunking
├── search/ # Search index implementation
├── cache/ # Disk caching layer
└── utils/ # Utilities (logger, errors)# Build TypeScript
npm run build
# Watch mode for development
npm run dev
# Run linter
npm run lint
# Fix linting issues automatically
npm run lint:fix
# Type checking (no emit)
npm run typecheck
# Run tests
npm test
# Run tests with coverage
npm test -- --coverage
# Run tests in watch mode
npm run test:watchThe project uses Vitest for testing with comprehensive coverage:
Unit tests: Test individual modules in isolation
Integration tests: Test tool handlers and workflows
End-to-end tests: Test complete flows (search → get_topic → get_related)
See MANUAL_TESTING.md for manual testing procedures.
TypeScript: Strict type checking enabled
ESLint: Code linting with TypeScript support
Test Coverage: ≥80% statement coverage required
Error Handling: Structured error payloads, no unhandled exceptions
Modularity: Small, composable modules with clear responsibilities
Type Safety: Strong TypeScript typing throughout
Error Handling: Structured errors, no unhandled exceptions
Caching: Aggressive caching to minimize network calls
Read-Only: No write operations, respect remote resources
LLM-Friendly: Chunked, structured content optimized for AI consumption
Deterministic: Idempotent operations, stable results
Providers: Fetch documentation from online or local sources
Parser: Extract and structure content from HTML
Chunker: Split content into LLM-friendly chunks
Cache: Disk-based caching for parsed topics
Search Index: In-memory full-text search with relevance scoring
MCP Server: Expose tools and resources via Model Context Protocol
MIT
Contributions are welcome! Please ensure:
All tests pass: npm test
Code is properly typed (no any types)
Coverage remains ≥80%
Linting passes: npm run lint
Get metadata about available documentation (versions, sections, source type).
| 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 full burden but only states what the tool does, not how it behaves. It doesn't disclose if it's read-only, requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant behavioral gaps for an agent.
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, efficient sentence that front-loads the core action ('Get metadata') and specifies the resource and metadata types. There is no wasted verbiage or unnecessary elaboration.
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 annotations and no output schema, the description is incomplete. It doesn't explain what the metadata output looks like (e.g., format, structure), potential limitations, or how it integrates with sibling tools. For a tool with zero parameters but unknown output, more context is needed.
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 tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it meets the baseline of 4 for zero-parameter tools by focusing on the tool's purpose without redundancy.
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 action ('Get metadata') and resource ('available documentation'), specifying what kind of metadata (versions, sections, source type). It distinguishes from siblings like 'search_docs' (searching content) or 'get_topic' (retrieving specific content), but doesn't explicitly contrast them.
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 like 'list_section_topics' or 'search_docs'. The description implies it's for metadata about documentation structure, but doesn't specify use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a documentation topic by ID or URL. Returns the topic with chunked content optimized for LLM consumption.
| Name | Required | Description | Default |
|---|---|---|---|
| topic_id | No | Topic ID (e.g., 'Language/topic.htm') | |
| url | No | Full URL to the topic page | |
| version | No | Documentation version (e.g., 'v111', 'latest'). Defaults to configured default version. | |
| max_chunks | No | Maximum number of chunks to return (default: 3, 0 = no limit) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a read operation ('Fetch'), returns chunked content optimized for LLMs, and implies no destructive actions. However, it doesn't mention potential errors (e.g., invalid IDs), rate limits, or authentication needs, leaving some behavioral aspects uncovered.
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 highly concise and front-loaded in a single sentence, with no wasted words. It efficiently communicates the core action, inputs, and output format, making it easy for an agent to parse and understand quickly.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is reasonably complete. It covers the purpose, input methods, and output format, but lacks details on error handling, performance constraints, or examples, which could enhance completeness for a retrieval tool.
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 schema fully documents all four parameters. The description adds no specific parameter semantics beyond what the schema provides, such as explaining relationships between 'topic_id' and 'url' or detailing 'max_chunks' behavior. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 action ('Fetch'), resource ('documentation topic'), and method ('by ID or URL'), distinguishing it from siblings like 'search_docs' or 'list_section_topics' which handle broader queries or lists. It specifies the return format ('chunked content optimized for LLM consumption'), making the purpose explicit and differentiated.
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 implies usage for retrieving specific topics via identifiers, but does not explicitly state when to use this tool versus alternatives like 'search_docs' for broader queries or 'list_section_topics' for section-based listings. It provides context (fetching by ID/URL) but lacks explicit guidance on exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all topics in a documentation section. Returns topic summaries with IDs, titles, URLs, and summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Section name (e.g., 'Language', 'Reference') | |
| version | No | Documentation version (e.g., 'v111', 'latest'). Defaults to configured default version. | |
| limit | No | Maximum number of topics to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return format (summaries with IDs, titles, URLs, and summaries), which is helpful, but lacks details on pagination (implied by 'limit'), error handling, authentication needs, rate limits, or whether it's a read-only operation. For a tool with 3 parameters and no annotations, this leaves significant gaps.
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, efficient sentence that front-loads the core action ('List all topics in a documentation section') and follows with key return details. Every word earns its place, with no redundancy or unnecessary elaboration.
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 3 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the purpose and return format, but lacks behavioral context (e.g., safety, errors) and doesn't fully address usage relative to siblings. For a read-like tool, it's passable but incomplete for optimal agent decision-making.
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 schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples or constraints beyond defaults). Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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 ('List') and resource ('topics in a documentation section'), making the purpose immediately understandable. It distinguishes from siblings like 'get_topic' (single topic) and 'search_docs' (search across docs), though not explicitly. However, it doesn't fully differentiate from 'get_related_topics' or 'describe_docs' in scope.
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 explicit guidance on when to use this tool versus alternatives like 'get_topic' for single topics or 'search_docs' for broader searches. The description implies usage for listing topics within a section but doesn't specify prerequisites, exclusions, or comparative contexts with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documentation topics using full-text search. Returns a list of matching topics with relevance scores.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| version | No | Documentation version (e.g., 'v111', 'latest'). Defaults to configured default version. | |
| section | No | Optional section filter (e.g., 'Language', 'Reference') | |
| limit | No | Maximum number of results to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'returns a list of matching topics with relevance scores,' which gives some output context, but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation. For a search tool with no annotations, this is a significant gap in transparency.
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 highly concise and well-structured: two sentences that efficiently cover the action and output. Every sentence earns its place by providing essential information without redundancy. It's front-loaded with the core purpose, making it easy for an agent to parse quickly.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and output but lacks details on behavioral traits, usage context, and deeper parameter meaning. Without an output schema, it doesn't fully explain return values beyond mentioning 'relevance scores,' leaving gaps in completeness.
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 schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain search syntax or relevance scoring). According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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 purpose: 'Search documentation topics using full-text search.' It specifies the verb ('search') and resource ('documentation topics'), and mentions the return type ('list of matching topics with relevance scores'). However, it doesn't explicitly differentiate from sibling tools like 'describe_docs' or 'get_related_topics' beyond the search functionality.
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 like 'describe_docs' or 'get_related_topics'. It states what the tool does but offers no context about when it's appropriate, such as for finding topics by keyword versus browsing sections. This leaves the agent without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: describe_docs for metadata, get_related_topics for topic relationships, get_topic for fetching specific content, list_section_topics for section overviews, and search_docs for full-text search. An agent can easily distinguish between them based on their names and descriptions.
All tools follow a consistent verb_noun pattern with snake_case: describe_docs, get_related_topics, get_topic, list_section_topics, and search_docs. The verbs (describe, get, list, search) are appropriate and predictable, making the set easy to navigate and understand.
With 5 tools, the server is well-scoped for documentation access, covering metadata retrieval, topic fetching, section listing, relationship discovery, and search. Each tool earns its place without redundancy, aligning with typical MCP server sizes of 3-15 tools for focused domains.
The tool set provides complete coverage for documentation interaction: describe_docs for overview, list_section_topics and search_docs for discovery, get_topic for content retrieval, and get_related_topics for navigation. There are no obvious gaps, enabling agents to perform full documentation workflows without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
Versioned documentation registry and semantic search for AI tools and coding assistants.
MCP server for querying Forkast documentation
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/h0ck3ystyx/synergyde-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
