Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sign-in-form show me the sign-in form"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small, ready-to-customize template for building an interactive Model Context Protocol (MCP) app with React and TypeScript.
The project includes:
An MCP server built with the TypeScript SDK
An interactive React UI registered as an MCP App resource
A sample open-sign-in tool that displays the UI in a compatible MCP host
Streamable HTTP and stdio transport support
A Vite build that packages the UI into a single HTML file
Development, build, serve, and type-check scripts
The included sign-in form is only a UI example. It does not authenticate users or send credentials to a server. Replace it with your own interface and application logic.
Node.js 20 or newer
npm
An MCP client or host with MCP Apps support to display the interactive UI
Related MCP server: MCP Docker Demo
On GitHub, click Use this template, choose Create a new repository, and then clone the repository you created:
git clone https://github.com/YOUR_USERNAME/YOUR_REPOSITORY.git
cd YOUR_REPOSITORYAlternatively, clone this repository directly.
Install the project dependencies:
npm installStart the UI and MCP server in watch mode:
npm run devThe MCP endpoint is available at:
http://localhost:3001/mcpThe development command rebuilds the UI when files change and restarts the server when its TypeScript files change.
Create a production build and start the server:
npm run build
npm run serveTo use another port, set the PORT environment variable:
PORT=4000 npm run serveYour endpoint will then be http://localhost:4000/mcp.
Configure your MCP client to connect to:
http://localhost:3001/mcpAfter connecting, call the open-sign-in tool. A compatible MCP Apps host will render the interactive form returned by the server.
Clients that launch local MCP servers can run this project over stdio. For example, use a configuration equivalent to:
{
"mcpServers": {
"my-mcp-app": {
"command": "npm",
"args": ["start"],
"cwd": "/absolute/path/to/YOUR_REPOSITORY",
"env": {
"TRANSPORT": "stdio"
}
}
}
}The exact configuration format depends on your MCP client. Use an absolute path for cwd.
You can also test the stdio server from a terminal:
TRANSPORT=stdio npm startThe main files are:
src/main.tsx — React interface and client-side behavior
src/style.css — UI styling
server.ts — MCP tool and UI resource registration
main.ts — HTTP and stdio transports
vite.config.ts — browser UI build configuration
When adapting the template:
Replace the sample form in src/main.tsx with your UI.
Update the tool name, description, schemas, and handler in server.ts.
Change the server and app names from sign-in-form to your project name.
If the UI needs to call MCP tools, add those tools to server.ts and invoke them through the MCP Apps client API.
Run npm run typecheck and npm run build before publishing.
For remote use, deploy the built Node.js server behind HTTPS and expose its /mcp route. Set PUBLIC_HOST to the public hostname without a protocol:
PUBLIC_HOST=mcp.example.com npm run servePUBLIC_HOST is used by the server's host and origin protection. Update the defaults and security policy in main.ts for your deployment, especially if the UI loads assets or communicates with additional domains.
Command | Purpose |
| Run the UI build and MCP server in watch mode |
| Build the single-file UI and compile the server |
| Run the compiled production server |
| Run the TypeScript server directly |
| Type-check the UI and server |
MIT
Display an interactive username and password form.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ready | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It does clarify that the tool displays an interactive form rather than performing authentication, which is useful. However, it does not disclose side effects, what happens after display, or whether any state changes occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. Every word adds meaning, and the sentence structure is immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless display tool, the description is mostly complete: it names the action and UI element shown. An output schema exists, so return-value details are presumably covered there. The main omission is usage context, but that is already reflected in the usage-guidelines score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is no parameter semantics burden. The baseline for 0-parameter tools is 4, and the description reasonably does not need to document inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, 'Display', and a specific resource, 'an interactive username and password form'. This both matches the tool name and disambiguates it from a sign-in/authentication action. There are no sibling tools, so no differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call this tool or when to avoid it. It only says what the tool does; there is no mention of prerequisites, context, or alternatives. With no siblings, some usage context would still help the agent decide when displaying a sign-in form is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0open-sign-inWith only a single tool, there is no possibility of confusing it with another tool. The purpose of open-sign-in is clearly stated and unambiguous.
The tool name follows a clear verb_noun pattern (open-sign-in) and there are no other tools to create inconsistencies. As the sole tool, it presents no naming conflicts.
The server is reduced to a single tool, which feels thin even for a narrow purpose. While the scope is minimal, a complete sign-in flow would typically require additional tools such as submit_sign_in or validate_credentials, so the count is borderline.
The tool displays a sign-in form but offers no way to submit or process the entered credentials, leaving the agent unable to complete a sign-in action. This is a notable gap in the tool surface for a server that claims to handle sign-ins.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/krasnoff/mcp-app-template'
If you have feedback or need assistance with the MCP directory API, please join our Discord server