Skip to main content

MCP Server

mcpfy-sdk/server provides the server-side API for building MCP servers with tools, prompts, resources, resource templates, widgets, authentication, and multiple transports. The main entry point is MCPServer.

1. Importing the Server API

Additional server APIs can be imported from the same entry point:

2. Creating an MCP Server

A server requires a name and version.
The MCPServer class wraps the official MCP SDK server while providing a simpler declarative API. The underlying native server remains accessible through:
This provides an escape hatch for functionality that is not directly exposed by mcpfy.

3. Server Configuration

The server accepts an MCPServerConfig object.

Configuration options

Example:

4. Server Capabilities

When MCPServer is created, mcpfy initializes the underlying official MCP server with support for:
  • Logging
  • Tools
  • Prompts
  • Resources
  • Resource subscriptions
  • List-change notifications
The server advertises list-change support for tools, prompts, and resources. Resource subscriptions are also enabled automatically.

5. Registering Tools

Tools are registered using:
Example:
The tool API is documented in detail in tools.md.

6. Registering Prompts

Prompts are registered using:
Example:
The prompt API is documented in detail in prompts.md.

7. Registering Resources

Resources are registered using:
Example:
Resource templates are supported through:
The complete resource API is documented in resources.md.

8. Registering Widgets

mcpfy supports interactive MCP widgets. Widgets can be registered through:
However, the widget() method is deprecated for new widget implementations. The recommended approach is to specify a widget folder through a tool definition:
The widget system supports multiple protocols, including MCP-UI, MCP Apps, and Apps SDK integrations. Widget functionality is documented in widgets.md and widget-react.md.

9. Starting the Server

The server is started using:
By default, mcpfy uses stdio transport.
is equivalent to:
Stdio is the typical transport used when an MCP host launches the server as a local process.

10. HTTP Transport

An MCP server can also be started using HTTP:
The default HTTP port is:
The default host is:
Therefore:
normally creates an MCP endpoint at:

11. HTTP Configuration

ListenOptions controls how the server starts.

transport

Selects the server transport.
or:
The default is:

port

Specifies the HTTP port.
The server will listen on:
Passing 0 allows the operating system to select an available port:
The actual assigned port is returned by listen().

host

Specifies the HTTP listening host.
The default is:

silent

Controls whether the HTTP startup URL is printed.
The default is:

12. HTTP Port Resolution

When using HTTP transport, mcpfy determines the port using the following priority:
For example:
takes priority over the environment variable. The command-line argument:
is also supported. The --port=N form is supported as well:

13. Parsing a Port from Arguments

The helper:
is exported from mcpfy-sdk/server. Example:
It supports:
and:
If multiple port arguments are present, the last valid occurrence wins. The function returns:

14. Environment Port

When no explicit port or command-line port is provided, mcpfy checks:
For example:
Then:
uses port 8080. If the environment variable is missing or invalid, mcpfy falls back to port 3000.

15. Server Listen Result

listen() returns a ListenResult.
For stdio:
The result is:
For HTTP:
The result contains:

16. Custom MCP HTTP Path

The HTTP MCP endpoint defaults to:
A custom path can be configured using basePath.
Starting the HTTP server:
produces an endpoint at:
The configured path is normalized internally before being passed to the HTTP transport.

17. Server Icons

An MCP server can advertise an icon through the icon configuration.
The icon can be provided as:
  • A remote URL
  • A data: URI
  • A local file path
  • A file: URL
  • A ServerIcon object
Local files are converted to data: URIs so MCP clients can display them.

18. Authentication

HTTP servers can require authentication using the auth configuration.
Authentication is applied to HTTP transport. For example:
Clients must provide the appropriate bearer token. JWT/JWKS authentication can be configured using:
Detailed authentication documentation is provided in authentication.md.

19. Accessing the Native MCP Server

The underlying official MCP server is exposed through:
Example:
This allows advanced users to access functionality directly from the official MCP SDK. mcpfy therefore acts as a higher-level API rather than preventing access to the underlying MCP implementation.

20. Refreshing Resources

mcpfy provides resource refresh functionality. To notify subscribed clients that a specific resource has changed:
Example:
This tells subscribed clients that new content is available for the specified resource URI.

21. Refreshing the Resource List

To tell clients to request the resource list again:
This is useful when resources are dynamically added or removed.

22. Refreshing the Tool List

To tell clients to request the tool list again:
This is useful when the available tools change during the server’s lifetime.

23. Refreshing the Prompt List

To tell clients to request the prompt list again:
This notifies clients that they should refresh their available prompt definitions.

24. Mounting Remote MCP Servers

mcpfy can expose tools, prompts, and resources from other HTTP MCP servers through the current server. This is done using:
Example:
The remote server’s tools and prompts are exposed using an alias-based naming scheme. For example:
represents a remote tool named:
mounted using the alias:
This allows multiple remote MCP servers to be combined behind one MCP server.

25. Closing the Server

A running server can be closed using:
close() performs cleanup for:
  1. The HTTP server, if running.
  2. Mounted remote server connections.
  3. The underlying native MCP server.
Example:
After closing, the HTTP handle and mounted remote connections are cleared.

26. HTTP Server Handle

After starting an HTTP server, additional information is available through:
Example:
The value is an HttpHandle while the HTTP server is running. It becomes undefined after the server is closed.

27. Complete HTTP Server Example

The server is available at:

28. Complete Stdio Server Example

Because stdio is the default transport, the final call can simply be:

29. Recommended Server Structure

A larger MCP application can organize the server separately from its tools and other features. Example:
The main server can then initialize and register the individual components.

30. Public Server API

The mcpfy-sdk/server entry point exports the following major APIs.

Server

Server types

Tools

Prompts

Resources

Context

Responses

Widgets

Authentication

Remote servers


31. Server API Summary


32. Recommended Usage Pattern

A typical mcpfy server follows this pattern:
For local MCP hosts such as Claude Desktop or Claude Code, stdio is generally used:
For remotely accessible MCP servers, HTTP transport can be used:
The same MCPServer abstraction supports both approaches, allowing the application logic to remain independent of the selected transport.