A
licenseC
qualityNot graded
maintenanceA DevOps-friendly template for building MCP servers with CI/CD, Docker support, and automatic documentation generation using fastmcp and FastAPI.
1
FastMCP Boilerplate
by kfrzr
Provides linting capabilities to ensure code quality and consistency in the MCP server project.
Supports version control operations for the MCP server project, including cloning repositories.
Enables interaction with GitHub repositories, including cloning and forking operations for MCP server development.
Automates workflows for linting, formatting, testing, and publishing package updates to NPM.
Facilitates package management and publishing of the MCP server to the NPM registry.
Provides code formatting capabilities to maintain consistent code style in the MCP server project.
Automates version management and package publishing to NPM based on commit messages.
Supports static type checking and TypeScript ESLint integration for enhanced code quality.
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., "@FastMCP Boilerplateshow me how to run tests for my new MCP server"
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.
FastMCP Boilerplate
A boilerplate for FastMCP.
This boilerplate is a good starting point for building an MCP server. It includes a basic setup for testing, linting, formatting, and publishing to NPM.
Development
To get started, clone the repository and install the dependencies.
git clone https://github.com/punkpeye/fastmcp-boilerplate.git
cd fastmcp-boilerplate
npm install
npm run devNOTE
If you are starting a new project, you may want to forkfastmcp-boilerplate and start from there.
Start the server
If you simply want to start the server, you can use the start script.
npm run startHowever, you can also interact with the server using the dev script.
npm run devThis will start the server and allow you to interact with it using CLI.
Testing
A good MCP server should have tests. However, you don't need to test the MCP server itself, but rather the tools you implement.
npm run testIn the case of this boilerplate, we only test the implementation of the add tool.
Linting
Having a good linting setup reduces the friction for other developers to contribute to your project.
npm run lintThis boilerplate uses Prettier, ESLint and TypeScript ESLint to lint the code.
Formatting
Use npm run format to format the code.
npm run formatGitHub Actions
This repository has a GitHub Actions workflow that runs linting, formatting, tests, and publishes package updates to NPM using semantic-release.
In order to use this workflow, you need to:
Add
NPM_TOKENto the repository secretsAdd token as
NPM_TOKENenvironment secret (Settings → Secrets and Variables → Actions → "Manage environment secrets" → "release" → Add environment secret)
Grant write access to the workflow (Settings → Actions → General → Workflow permissions → "Read and write permissions")
Available Tools
1 toolproperty_searchBRead-only
Search for a real estate property via spatial, semantic, or hybrid search
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of properties to return | |
| max_price | No | Maximum price of properties to return | |
| min_baths | No | Return properties with a number of baths greater than or equal to this number | |
| min_beds | No | Return properties with a number of bedrooms greater than or equal to this number | |
| min_sqft | No | Return properties with a square footage greater than or equal to this number | |
| query | Yes | A short and concise description of desired apartment amenities and other intangibles. Don't include traits like number of bedrooms that are covered by other search parameters. Don't include amenities or intangibles the user wants to avoid. | |
| search_center_latitude | No | Optional float latitude for search center. Should always be set if longitude is set | |
| search_center_longitude | No | Optional float longitude for search center. Should always be set if latitude is set | |
| search_radius | No | Return properties within this distance (in miles) from the search center |
TDQS
B3.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, covering safety and data scope. The description adds value by specifying search types (spatial, semantic, hybrid), which provides context beyond annotations. However, it lacks details on rate limits, authentication needs, or result format.
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, efficient sentence that clearly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to understand quickly.
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 search tool with 9 parameters, no output schema, and annotations covering read-only and open-world aspects, the description is minimally adequate. It specifies search types but lacks details on result structure, error handling, or performance characteristics that would enhance 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 description coverage is 100%, so the schema fully documents all 9 parameters. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining interactions between parameters or search type implications. Baseline 3 is appropriate when schema coverage is high.
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 for a real estate property') and the resource ('real estate property'), and specifies the search methods ('spatial, semantic, or hybrid search'). However, with no sibling tools mentioned, it cannot differentiate from alternatives, preventing a perfect score.
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, prerequisites, or exclusions. It mentions search types but doesn't explain when to choose one over another or contextual constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3.3/5.0
Disambiguation5/5
With only one tool, there is no possibility of ambiguity or overlap between tools, making disambiguation perfect. The tool's purpose is clearly defined as searching for real estate properties, leaving no room for confusion.
Naming Consistency5/5
A single tool inherently exhibits perfect naming consistency, as there are no other tools to compare against. The name 'property_search' follows a clear verb_noun pattern, which is consistent in isolation.
Tool Count2/5
A single tool is generally too few for a server's purpose, as it limits functionality and suggests an incomplete or overly narrow scope. For real estate, one search tool lacks essential operations like creating, updating, or deleting properties, making it insufficient for typical workflows.
Completeness1/5
The tool set is severely incomplete for a real estate domain, as it only provides search functionality without any CRUD operations (create, read, update, delete) or lifecycle management. This gap will likely cause agent failures when attempting to perform basic tasks beyond searching.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Primarily to be used as a template repository for developing MCP servers with FastMCP in Python, P…
FastMCP commerce server starter: product catalog, search, and checkout. Deploy to Vercel in 5 min.
A simple MCP server built with FastMCP and python
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA boilerplate for building FastMCP servers, providing a basic setup for testing, linting, formatting, and publishing to NPM.131MIT
- AlicenseAqualityBmaintenanceA TypeScript starter template for MCP servers with CI/CD, OIDC npm publishing, and zero-secret setup.188MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kfrzr/realtor_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server