de en es ja ko ru zh

Renesas FSP MCP Server

Name: Renesas FSP MCP Server
Author: hungnguyen1503

by hungnguyen1503

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

🔧 Renesas FSP MCPサーバー

📋 概要

FSP (Firmware Support Package) MCPサーバーは、Renesas RA MCUファミリ向けのソフトウェアアーキテクチャであるRenesas Flexible Software Packageのための管理およびドキュメント検索インターフェースです。

このサーバーは以下の機能を提供します：

🔍 GitHubリポジトリからのドキュメント検索
💻 コード例とAPIリファレンスの発見
📦 依存関係とバージョンの管理
🛠️ e² studioを用いた開発ワークフローのサポート

Related MCP server: ABAP MCP Server

✨ 主な機能

1. ドキュメント検索 🔍

GitHubリポジトリからFSPドキュメントを検索します：

アーキテクチャの概要
サポートされているソフトウェアモジュール
ドライバガイドおよびHAL APIリファレンス
RTOS統合ドキュメント
ミドルウェアスタックドキュメント

2. コード例の発見 💻

機能ごとのコード例を発見します：

SPI、I2C、UART周辺機器ドライバ
ADC/DACサンプリング例
セキュアブートの実装
FreeRTOS統合
DMAベースのデータ転送

3. APIリファレンスの検索 📚

APIドキュメントを検索します：

コアFSPライブラリ (FspLib)
周辺機器ドライバ (SPI、I2C、UARTなど)
RTOS統合API
セキュリティおよび暗号化機能

4. 依存関係の管理 📦

依存関係とバージョンを管理します：

バージョン履歴の追跡
プラットフォーム互換性マトリックス
e² studioのバージョン要件
最小ハードウェア仕様

🏗️ システムアーキテクチャ

┌─────────────────────────────────────┐
│         MCP Server                  │
│  ┌──────────┬──────────┬──────────┐ │
│  │ Doc      │ Examples │ API      │ │
│  │ Search   │ Discovery│ Reference│ │
│  └──────────┴──────────┴──────────┘ │
│         ↓                           │
│  ┌─────────────────────────────┐    │
│  │  GitHub Repository          │    │
│  │  - Documentation            │    │
│  │  - Code Examples            │    │
│  │  - API References           │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘

📁 プロジェクト構造

fsp-mcp-server/
├── src/                    # Source code
│   ├── index.ts           # Main MCP server entry point
│   └── handlers/          # Handler modules
│       ├── info.ts        # FSP architecture information
│       ├── version.ts     # Version management
│       ├── documentation.ts  # Documentation search
│       ├── examples.ts    # Code examples discovery
│       ├── api-reference.ts  # API reference lookup
│       └── dependencies.ts   # Dependency management
├── schemas/               # JSON schema definitions
├── docs/                  # Generated documentation
├── examples/              # Usage examples
├── package.json          # NPM configuration
├── tsconfig.json         # TypeScript configuration
└── README.md            # This file

🚀 インストールと使用方法

1. 依存関係のインストール

cd fsp-mcp-server
npm install

2. ビルドと実行

# Build TypeScript code
npm run build

# Run server
npm start

または、開発モードで直接実行します：

npm run dev

3. MCPクライアントへの接続

MCPクライアント（例：LM Studio、Claude Desktopなど）に以下の設定を追加します：

{
  "mcpServers": {
    "fsp-mcp-server": {
      "command": "node",
      "args": ["/path/to/fsp-mcp-server/dist/index.js"]
    }
  }
}

/path/to/fsp-mcp-server をプロジェクトディレクトリへの実際の絶対パスに置き換えてください。

LM Studioの場合：

Settings → Extensions → Model Context Protocol を開きます。
新しい MCP endpoint を追加し、コマンドに node /path/to/fsp-mcp-server/dist/index.js を入力します。
transport を stdio に設定します。
MCP Explorer を介して接続を保存し、テストします。

🔧 設定

package.json を通じてサーバーをカスタマイズできます：

{
  "scripts": {
    "build": "tsc && echo '✅ TypeScript compilation complete: dist/index.js'",
    "build:clean": "npm run build && find dist -name '*.d.ts' -delete && echo '🧹 Cleaned .d.ts files'",
    "dev": "tsx watch src/index.ts",
    "start": "node ./dist/index.js",
    "lint": "eslint \"src/**/*.ts\"",
    "format": "prettier --write ."
  }
}

📚 参照

📄 ライセンス

BSD 3-Clause License - 詳細はLICENSEファイルを参照してください。

👨💻 コントリビューション

このプロジェクトに貢献するには、以下を行ってください：

リポジトリをフォークする
機能用のブランチを作成する (git checkout -b feature/AmazingFeature)
変更をコミットする (git commit -m 'Add some AmazingFeature')
ブランチにプッシュする (git push origin feature/AmazingFeature)
プルリクエストを開く

Available Tools

9 tools

find_code_examplesC

Find code examples for specific FSP features or peripherals

ParametersJSON Schema

Name	Required	Description	Default
`feature`	No	Feature to find examples for (e.g., 'SPI', 'UART', 'secure_boot')
`platform`	No	Target platform filter

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, and the description only states 'find' without details on behavioral traits such as read-only nature, rate limits, or result limitations. The agent lacks understanding of 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.

Conciseness2/5

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

The description is a single short sentence, but it omits crucial information. It is under-specified rather than efficiently concise, failing to provide sufficient context for an agent.

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?

With no output schema and only two parameters, the description does not explain what the output looks like, how results are formatted, or any pagination. This leaves the agent with incomplete understanding for effective invocation.

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 input schema already describes both parameters (feature and platform) adequately. The description does not add additional meaning beyond the schema, so baseline score applies.

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?

Description clearly states that the tool finds code examples for FSP features or peripherals, with a specific verb and resource. However, it does not differentiate from sibling tools like search_documentation or get_api_reference, which may overlap in purpose.

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. The sibling tools include similar search and reference tools, but the description does not clarify the distinct context for this tool.

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

fsp_build_infoB

Get FSP build-related information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

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 only states that the tool 'gets' information, implying it is read-only, but provides no details on safety, idempotency, or potential 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.

Conciseness4/5

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

The description is a single, clear sentence that is efficiently concise. It could be slightly more informative without sacrificing brevity, but it avoids verbosity.

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, the description should elaborate on what the tool returns (e.g., build version, date, dependencies). Without this, the agent has insufficient context to judge the tool's utility.

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 tool has zero parameters, and the schema coverage is trivially 100%. The description adds no parameter information, but none is needed. Baseline for zero parameters is 4.

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 retrieves build-related information, distinguishing it from sibling tools like fsp_info or fsp_version. However, it lacks specificity about what exactly constitutes 'build-related information'.

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. The description does not mention scenarios or prerequisites, leaving the agent to infer context from the tool name alone.

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

fsp_config_infoC

Get FSP configuration information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, and the description merely states the action without disclosing any behavioral traits such as side effects, authentication needs, or rate limits.

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 concise but lacks structure; it is a single phrase without any additional information.

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?

With no output schema and absent annotations, the description does not explain what 'configuration information' includes, leaving the agent uncertain about the return value.

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 no parameters (100% coverage), so the description does not need to add parameter meaning; baseline 4 as per guidelines.

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 'Get FSP configuration information' clearly indicates the tool retrieves configuration data, but it does not distinguish it from sibling tools like fsp_info or fsp_build_info.

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; the description gives no context about usage scenarios.

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

fsp_helpB

Get help information for the FSP MCP server

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the purpose but does not mention read-only nature, side effects, or any other behavioral 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 with no wasted words. However, it lacks front-loading or structuring that might improve scannability.

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?

Given the tool's simplicity (no parameters, no output schema), the description is minimally adequate. It could specify what 'help information' includes (e.g., list of commands, usage examples) to be more complete.

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 tool has zero parameters, achieving baseline score of 4. No additional description is needed, and the schema coverage is 100%.

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 retrieves help information for the FSP MCP server. However, it does not differentiate from sibling tools like fsp_info or get_api_reference, which may also provide help-like content.

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. There is no mention of context, prerequisites, or exclusions.

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

fsp_infoC

Get FSP architecture information and details

ParametersJSON Schema

Name	Required	Description	Default
`target`	No	Target platform (RA6, RA8, R74C, etc.)

TDQS

C2.4/5.0

Behavior1/5

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

No annotations are provided, and the description fails to disclose any behavioral traits such as whether the tool is read-only, requires authentication, or has any side effects. 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.

Conciseness2/5

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

The description is only seven words and one sentence. While concise, it is under-specified and lacks necessary detail, making it less useful than a slightly longer description.

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 no output schema, the description should explain what information is returned. It only says 'architecture information and details' without specifics, leaving the agent uninformed about the output structure.

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 schema has 100% description coverage for the single parameter 'target', so the description does not need to add more. The description does not add any semantic value beyond the schema.

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 retrieves FSP architecture information, which distinguishes it from sibling tools like fsp_build_info or fsp_config_info. However, 'details' is somewhat vague.

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 like fsp_build_info or fsp_config_info. It only states the basic function.

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

fsp_versionB

Get FSP version information and release notes

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/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 fully disclose behavioral traits. It only states the tool returns version info and release notes, but does not mention whether it is purely read-only, requires authentication, or the format of output. This is insufficient for a tool with zero annotation support.

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 directly states the tool's purpose. Every word is earned with no redundancy or fluff.

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 no parameters and no output schema, the description is somewhat complete. However, given the presence of sibling tools (fsp_build_info, fsp_info), the description does not clarify the exact scope of information returned, risking overlap confusion.

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 tool has no parameters, and the input schema is empty with 100% description coverage. The description adds no parameter information, but none is needed. A baseline of 4 is appropriate as there are no parameters to explain.

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 retrieves FSP version information and release notes. It uses a specific verb ('Get') and resource. However, it does not differentiate from sibling tools like fsp_info or fsp_build_info, which might have overlapping purposes.

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. Given several sibling tools (e.g., fsp_info, fsp_build_info), explicit usage context is needed but missing.

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

get_api_referenceB

Get API reference documentation for FSP functions and structures

ParametersJSON Schema

Name	Required	Description	Default
`module`	No	Module name (e.g., 'FspLib', 'Spi', 'I2c')
`function`	No	Specific function name

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided. Description fails to disclose return format (e.g., markdown, HTML) or any other behavioral traits beyond 'Get'.

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?

Single sentence, front-loaded verb, no superfluous words. Efficient for its length.

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?

Adequate for a simple retrieval tool with full parameter coverage, but lacks behavioral disclosure and usage context that would elevate completeness.

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 parameter descriptions are clear. Description adds minimal value beyond 'for FSP functions and structures'.

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?

Description clearly states 'Get API reference documentation' - a specific verb+resource. It distinguishes from sibling 'search_documentation' by implying reference vs. search, but could be more explicit.

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. siblings like 'search_documentation' or 'find_code_examples'. No context for prerequisites or post-conditions.

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

manage_dependenciesC

Manage FSP dependencies, versions, and compatibility matrix

ParametersJSON Schema

Name	Required	Description	Default
`action`	No
`platform`	No	Target MCU platform

TDQS

C2.3/5.0

Behavior1/5

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

No annotations provided, and description fails to disclose behavioral traits like safety, side effects, or required permissions. 'Manage' implies mutability but no details.

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?

Single concise sentence with no superfluous content. However, it lacks necessary detail but is efficiently structured.

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 2 params and no output schema, description fails to explain return values, behavior, or integration with sibling tools. Incomplete for reliable invocation.

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 50% (only platform described). Description adds no parameter details beyond schema, leaving action enum and platform usage unexplained.

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?

Description states it manages FSP dependencies, versions, and compatibility matrix, which is a clear resource but uses vague verb 'manage'. It distinguishes from sibling tools like fsp_version and fsp_info by focusing on dependencies, but lacks specificity.

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 fsp_version or fsp_info. Agent receives no context for decision making.

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

search_documentationC

Search FSP documentation from GitHub repository

ParametersJSON Schema

Name	Required	Description	Default
`query`	No	Search query for documentation
`category`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It does not state read-only nature, authentication needs, rate limits, or whether it triggers external calls. 'Search' implies read-only but is not explicit.

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, concise sentence that is front-loaded with the action. No superfluous words, but could include more detail without becoming verbose.

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?

Missing crucial context: what FSP stands for, what type of documentation is searched, output format, pagination, or limitations. With no output schema and no annotations, the description leaves the agent underinformed.

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 50% (query has description, category does not). The description adds no extra meaning beyond the schema; it does not clarify how to formulate 'query' or the significance of 'category' values.

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 ('Search') and the resource ('FSP documentation from GitHub repository'). It distinguishes from sibling tools like find_code_examples and get_api_reference, but lacks specificity about the scope of 'documentation'.

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 siblings like find_code_examples. There is no mention of when to avoid using it or any prerequisites.

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.

9 tool updatesv1.0.0May 15, 2026
- First observedfind_code_examples
- First observedfsp_build_info
- First observedfsp_config_info
- First observedfsp_help
- First observedfsp_info
- First observedfsp_version
- First observedget_api_reference
- First observedmanage_dependencies
- First observedsearch_documentation

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

B3.3/5.0

Scored 2026-05-15 19:10 across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: finding code examples, build info, config info, server help, architecture info, version, API reference, dependency management, and documentation search. No two tools overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., find_code_examples, get_api_reference) or use the 'fsp_' prefix (e.g., fsp_config_info). While consistent within groups, mixing these patterns is a minor deviation.

Tool Count5/5

With 9 tools, the server is well-scoped for providing comprehensive FSP information and documentation. Each tool serves a necessary function without redundancy.

Completeness5/5

The tool set covers the full range of information needs for FSP development: code examples, build/config details, version/architecture, API reference, dependency management, and documentation search. No obvious gaps exist for an informational server.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

renCosta2025-context7fork
ai.smithery
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Documentation Access Developer Tools Search
2
GitHits AOAuth
com.githits
Search public open-source code, documentation, metadata, vulnerabilities, changelogs, and examples.
Developer Tools Documentation Access Search
2113
developer-tools-mcp-server A
com.thenextgennexus
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Developer Tools Search
72
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42

Related MCP Servers

UseKeen Documentation MCP
Documentation Access Search
PromptMixerDev
A
license
Not graded
quality
D
maintenance
Enables AI assistants to search documentation of packages and services to find implementation details, examples, and specifications.
Updated a year ago (2025-05-08 02:00 UTC)
MIT
ABAP MCP Server
Documentation Access Developer Tools Search
DXCHowardB
A
license
Not graded
quality
Not graded
maintenance
Provides unified ABAP and RAP documentation search, document retrieval, and ABAP feature matrix lookups. It also enables local ABAP linting to streamline development and documentation workflows via the Model Context Protocol.
Updated 7 months ago (2026-02-24 08:25 UTC)
-
CODESYS MCP Server
Developer Tools Documentation Access
Zandiexoder
A
license
Not graded
quality
D
maintenance
Enables CODESYS development assistance via MCP, including curated guidance, Structured Text writing help, local PDF search, and live official documentation lookup.
Updated 5 months ago (2026-04-29 00:48 UTC)
1
MIT
CHECK-MODULE MCP Server
Documentation Access Search
muhammedehab35
A
license
A
quality
D
maintenance
Enables managing internal documentation with search and add capabilities, and fetching official documentation from 13+ popular libraries via MCP tools.
Updated 8 months ago (2026-02-07 23:35 UTC)
6
9
MIT