Skip to main content
Glama
deenesjakoruzh
hungnguyen1503

Renesas FSP MCP Server

by hungnguyen1503
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

🔧 Renesas FSP MCP Server

📋 Overview

FSP (Firmware Support Package) MCP Server is a management and documentation search interface for Renesas Flexible Software Package - the software architecture for Renesas RA MCU family.

This server provides the following capabilities:

  • 🔍 Search documentation from GitHub repository

  • 💻 Discover code examples and API references

  • 📦 Manage dependencies and versions

  • 🛠️ Support development workflow with e² studio

Related MCP server: ABAP MCP Server

✨ Key Features

1. Documentation Search 🔍

Search FSP documentation from GitHub repository:

  • Architecture overview

  • Supported software modules

  • Driver guides and HAL API references

  • RTOS integration documentation

  • Middleware stack documentation

2. Code Examples Discovery 💻

Discover code examples for features:

  • SPI, I2C, UART peripheral drivers

  • ADC/DAC sampling examples

  • Secure boot implementation

  • FreeRTOS integration

  • DMA-based data transfer

3. API Reference Lookup 📚

Lookup API documentation:

  • Core FSP Library (FspLib)

  • Peripheral drivers (SPI, I2C, UART, etc.)

  • RTOS integration APIs

  • Security and cryptographic functions

4. Dependency Management 📦

Manage dependencies and versions:

  • Version history tracking

  • Platform compatibility matrix

  • e² studio version requirements

  • Minimum hardware specifications

🏗️ System Architecture

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

📁 Project Structure

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

🚀 Installation and Usage

1. Install dependencies

cd fsp-mcp-server
npm install

2. Build and run

# Build TypeScript code
npm run build

# Run server
npm start

Or run directly in development mode:

npm run dev

3. Connect to MCP Client

Add the following configuration to your MCP client (e.g., LM Studio, Claude Desktop, etc.):

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

Replace /path/to/fsp-mcp-server with the actual absolute path to your project directory.

For LM Studio:

  1. Open Settings → Extensions → Model Context Protocol.

  2. Add a new MCP endpoint with the command: node /path/to/fsp-mcp-server/dist/index.js.

  3. Set the transport to stdio.

  4. Save and test the connection via MCP Explorer.

🔧 Configuration

You can customize the server via 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 ."
  }
}

📚 References

📄 License

BSD 3-Clause License - See LICENSE file for details.

👨‍💻 Contributing

To contribute to this project, please:

  1. Fork the repository

  2. Create a branch with your feature (git checkout -b feature/AmazingFeature)

  3. Commit your changes (git commit -m 'Add some AmazingFeature')

  4. Push to the branch (git push origin feature/AmazingFeature)

  5. Open a Pull Request

Available Tools

9 tools
find_code_examplesC

Find code examples for specific FSP features or peripherals

ParametersJSON Schema
NameRequiredDescriptionDefault
featureNoFeature to find examples for (e.g., 'SPI', 'UART', 'secure_boot')
platformNoTarget 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
targetNoTarget 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
moduleNoModule name (e.g., 'FspLib', 'Spi', 'I2c')
functionNoSpecific 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
NameRequiredDescriptionDefault
actionNo
platformNoTarget 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
NameRequiredDescriptionDefault
queryNoSearch query for documentation
categoryNo

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.

  1. 9 tool updatesv1.0.0
    • 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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Scored 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

Related MCP Connectors

Related MCP Servers