Skip to main content
Glama
mesopelagique

4D Documentation Viewer

by mesopelagique
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

4D Documentation Viewer

A VS Code extension and MCP (Model Context Protocol) server for browsing 4D command documentation.

Overview

This project provides two ways to access 4D command documentation:

  1. VS Code Extension: Browse documentation directly in VS Code with intelligent command detection

  2. MCP Server: Use as a Model Context Protocol server with AI assistants like Claude

Both modes share the same caching system for improved performance.

Related MCP server: MCP Docs Server

Features

VS Code Extension Features

  • Smart Command Detection: Automatically detects 4D commands from:

    • Selected text

    • Word at cursor position

    • LSP/hover information

    • Strips command numbers (e.g., :C123 format) when getting command name

  • Two Display Modes:

    • Open in browser (quick external reference)

    • Open in editor webview (integrated documentation with CSS styling)

  • Context Menu Integration: Right-click commands for quick access

  • Automatic Caching: Faster subsequent lookups

MCP Server Features

  • Fetch 4D Command Documentation: Retrieve HTML documentation for any 4D command

  • Smart Caching: Automatically caches documentation in OS-specific cache directories

  • Cache Management: Clear the cache when needed to fetch fresh documentation

  • Browser Integration: Open documentation URLs directly in default browser

Installation

As a VS Code Extension

  1. Build the extension:

npm install
npm run build

  1. Install locally:

    • Press F5 to run the extension in a new VS Code window (for development)

    • Or package and install:

npm run package
code --install-extension mcp-4d-docs-0.1.0.vsix

As an MCP Server

# Clone or navigate to the project
cd mcp-4d-docs

# Install dependencies
npm install

# Build the TypeScript code
npm run build

Usage

Using the VS Code Extension

  1. Open a 4D code file (or any file)

  2. Select a 4D command name or place cursor on it

  3. Use one of these methods:

    • Command Palette (Cmd+Shift+P):

      • 4D: Open Command Documentation in Browser

      • 4D: Open Command Documentation in Editor

    • Right-click Context Menu:

      • Select command text, right-click, choose option

    • Keyboard Shortcut: (can be configured in VS Code)

If no command is detected, you'll be prompted to enter one manually.

Using as MCP Server

Add to your MCP client configuration (e.g., Claude Desktop):

{
  "mcpServers": {
    "4d-docs": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-4d-docs/build/index.js"]
    }
  }
}

For VS Code, add to .vscode/mcp.json:

{
  "mcpServers": {
    "4d-docs": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-4d-docs/build/index.js"]
    }
  }
}

Available MCP Tools

get_4d_command_docs

Fetches documentation for a 4D command.

Parameters:

  • command_name (string): The name of the 4D command (e.g., "ACTIVITY SNAPSHOT", "ARRAY TO LIST")

Returns:

  • HTML documentation content extracted from the <article> tag within the <main> section

Example:

// Fetches from https://developer.4d.com/docs/commands/activity-snapshot
get_4d_command_docs("ACTIVITY SNAPSHOT")

clear_4d_docs_cache

Clears all cached documentation files.

Returns:

  • A message indicating the number of files cleared

open_4d_command_in_browser

Opens a 4D command documentation page in the default web browser.

Parameters:

  • command_name (string): The name of the 4D command (e.g., "ACTIVITY SNAPSHOT", "ARRAY TO LIST")

Returns:

  • A message confirming the URL was opened

Example:

// Opens https://developer.4d.com/docs/commands/activity-snapshot in your browser
open_4d_command_in_browser("ACTIVITY SNAPSHOT")

How It Works

  1. Command Detection (VS Code Extension):

    • Checks for selected text first

    • Falls back to word at cursor position

    • Uses LSP hover information when available

    • Prompts for manual entry if needed

  2. URL Encoding: Command names are converted to lowercase and spaces are replaced with hyphens

    • Example: "ACTIVITY SNAPSHOT" → "activity-snapshot"

  3. Documentation Fetching: The server requests documentation from:

    • https://developer.4d.com/docs/commands/<encoded-command-name>

  4. HTML Extraction: The server parses the HTML and extracts the <article> node from within the <main> tag

  5. Link Rewriting: Relative /docs/ links are converted to absolute URLs

  6. Caching: Results are cached in the OS system cache directory:

    • macOS: ~/Library/Caches/mcp-4d-docs/

    • Windows: %LOCALAPPDATA%\mcp-4d-docs\

    • Linux: ~/.cache/mcp-4d-docs/

  7. Cache Key: Each command is cached using an MD5 hash of its name as the filename

  8. Display (VS Code Extension):

    • Browser mode: Opens URL directly

    • Webview mode: Displays cached HTML with 4D CSS styling and VS Code theme integration

Development

Project Structure

mcp-4d-docs/
├── src/
│   ├── index.ts              # MCP server implementation
│   ├── extension.ts          # VS Code extension entry point
│   ├── docService.ts         # Shared documentation service
│   ├── commandDetector.ts    # Command name detection logic
│   └── webviewProvider.ts    # Webview panel management
├── build/                    # Compiled JavaScript output
├── logo.png                  # Extension icon
├── package.json             # Project metadata & VS Code extension config
├── tsconfig.json            # TypeScript configuration
├── .vscodeignore            # Files excluded from extension package
└── README.md

Building

# Install dependencies
npm install

# Build TypeScript
npm run build

# Watch mode for development
npm run watch

# Package extension
npm run package

Testing the Extension

Press F5 in VS Code to launch the Extension Development Host with the extension loaded.

Testing the MCP Server

# Use MCP Inspector
npx @modelcontextprotocol/inspector node build/index.js

Dependencies

  • @modelcontextprotocol/sdk - Model Context Protocol SDK

  • cheerio - HTML parsing

  • @types/vscode - VS Code API types

  • @vscode/vsce - VS Code extension packaging

Configuration

Extension Settings

The extension works out of the box with no configuration needed. It will:

  • Activate when opening 4D files (onLanguage:4d)

  • Be available via command palette for any file type

  • Cache documentation in your system cache directory

Custom Keybindings

You can add custom keyboard shortcuts in VS Code:

{
  "key": "cmd+k cmd+d",
  "command": "4d-docs.openInWebview",
  "when": "editorTextFocus"
},
{
  "key": "cmd+k cmd+b",
  "command": "4d-docs.openInBrowser",
  "when": "editorTextFocus"
}

Publishing

For Personal Use

The extension is ready to use locally. After building and packaging:

npm run package
code --install-extension mcp-4d-docs-0.1.0.vsix

For Distribution

Before publishing to the VS Code Marketplace:

  1. Update publisher name in package.json:

    "publisher": "your-actual-publisher-id"

  2. Add repository URL in package.json:

    "repository": {
  "type": "git",
  "url": "https://github.com/yourusername/mcp-4d-docs.git"
}

  3. Add a LICENSE file (e.g., LICENSE.txt with MIT license text)

  4. Publish to marketplace:

    vsce publish

    Or create a VSIX for sharing:

    npm run package
# Share the .vsix file

License

MIT

Contributing

Contributions are welcome! Please feel free to submit issues or pull requests.

  • If the remote CSS doesn’t exist (for instance, if it was renamed), consider embedding one in the plugin.

  • Support 4D language highlighting (Prism?).

  • Keep a key pressed when requesting documentation via the command palette to allow forcing a download (i.e., bypassing the cache).

Available Tools

3 tools
clear_4d_docs_cacheA

Clear the local cache of 4D documentation. This removes all cached documentation files, forcing fresh fetches on subsequent requests.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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 that the tool 'removes all cached documentation files,' indicating a destructive operation, and explains the effect ('forcing fresh fetches'). However, it lacks details on permissions needed, error handling, or confirmation prompts, which are relevant for a cache-clearing tool.

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 two sentences with zero waste: the first states the purpose, and the second explains the effect. It is front-loaded and appropriately sized, with every sentence earning its place by adding value.

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 tool's simplicity (0 parameters, no output schema, no annotations), the description is mostly complete. It covers what the tool does and the outcome. However, for a destructive operation, it could benefit from mentioning potential side effects or confirmation steps, slightly reducing 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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is applied since no parameters exist, and the description adds no unnecessary param info.

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 specific action ('Clear') and target resource ('local cache of 4D documentation'), distinguishing it from sibling tools like get_4d_command_docs (fetch) and open_4d_command_in_browser (open in browser). It precisely defines what the tool does without being tautological.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('forcing fresh fetches on subsequent requests'), implying it should be used when cached documentation is stale or problematic. However, it does not explicitly state when not to use it or name alternatives, such as whether to use it before or after other operations.

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

get_4d_command_docsA

Get documentation for a 4D command. Fetches the documentation from https://developer.4d.com/docs/commands/ and extracts the article content from the main tag. Results are cached locally for faster subsequent access.

ParametersJSON Schema
NameRequiredDescriptionDefault
command_nameYesThe name of the 4D command (e.g., "ACTIVITY SNAPSHOT", "ARRAY TO LIST")

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it fetches from a specific URL, extracts content from the main tag, and implements local caching. It doesn't mention error handling, rate limits, or authentication needs, but covers the core operational behavior adequately.

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 highly concise and front-loaded: the first sentence states the core purpose, followed by operational details and caching benefit. Every sentence earns its place with no wasted words, 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.

Completeness4/5

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

Given the tool's moderate complexity (fetching web content with caching), no annotations, and no output schema, the description provides good context about the source URL, extraction method, and caching. It could improve by mentioning the return format (e.g., plain text, HTML) or error cases, but it's largely complete for the task.

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%, so the schema already fully documents the single parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of valid command names beyond the schema's examples). Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Get documentation for a 4D command' with specific details about fetching from a URL and extracting content. It distinguishes from siblings by focusing on retrieving and caching documentation rather than clearing cache or opening in browser. However, it doesn't explicitly contrast with 'open_4d_command_in_browser' beyond the caching aspect.

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

Usage Guidelines3/5

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

The description implies usage context through the caching benefit ('faster subsequent access'), suggesting this tool is preferred for repeated access. However, it doesn't explicitly state when to use this versus 'open_4d_command_in_browser' (e.g., for programmatic use vs. human viewing) or provide any exclusion criteria.

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

open_4d_command_in_browserA

Open a 4D command documentation page in the default web browser. This opens the URL https://developer.4d.com/docs/commands/ directly in your browser.

ParametersJSON Schema
NameRequiredDescriptionDefault
command_nameYesThe name of the 4D command (e.g., "ACTIVITY SNAPSHOT", "ARRAY TO LIST")

TDQS

A4/5.0
Behavior3/5

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 behavioral trait of opening a browser and the specific URL format, but doesn't mention potential side effects (e.g., browser pop-ups, network requirements), error handling, or platform dependencies. It adequately describes the core behavior but lacks completeness for a tool with external effects.

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?

Two sentences with zero waste: the first states the purpose and resource, the second provides the exact URL pattern. Every word earns its place, and the description is appropriately sized for a simple tool.

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 tool's low complexity (one parameter, no output schema, no annotations), the description is nearly complete. It explains what the tool does, the URL format, and the browser interaction. The only minor gap is lack of explicit mention of potential errors or platform constraints, but for this simple tool, it's largely sufficient.

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%, so the schema already fully documents the single parameter. The description adds no additional parameter semantics beyond what the schema provides (it mentions the URL structure but doesn't elaborate on command_name format or constraints). Baseline 3 is appropriate when the schema does all the work.

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 specific action ('Open a 4D command documentation page in the default web browser'), identifies the resource ('4D command documentation page'), and distinguishes from siblings by specifying it opens a browser URL rather than retrieving or caching documentation like get_4d_command_docs or clear_4d_docs_cache.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (to open documentation in a browser), but doesn't explicitly state when not to use it or name alternatives. It implies but doesn't explicitly contrast with the sibling tools that retrieve or cache documentation instead of opening a browser.

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.

  1. 3 tool updatesv0.1.1
    • First observedclear_4d_docs_cache
    • First observedget_4d_command_docs
    • First observedopen_4d_command_in_browser
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: clearing cache, fetching documentation content, and opening documentation in a browser. There is no overlap in functionality, making tool selection unambiguous for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with '4d' as a prefix (clear_4d_docs_cache, get_4d_command_docs, open_4d_command_in_browser). The naming is uniform and predictable throughout the set.

Tool Count3/5

With only 3 tools, the set feels thin for a documentation viewer that might benefit from additional operations like listing commands or searching documentation. However, it covers basic needs without being excessive.

Completeness4/5

The tools provide core functionality for accessing and managing 4D documentation (fetch, open, clear cache). Minor gaps exist, such as no tool for browsing or searching command lists, but agents can work around this by using the provided tools effectively.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers