file-finder-mcp
Allows searching and retrieving files and their metadata (name, path, size, creation date) from the filesystem using path fragments.
Click on "Deploy 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., "@file-finder-mcpfind files containing 'report' in my documents folder"
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.
file-finder-mcp MCP Server
A MCP server for searching files in the filesystem based on a path fragment.
Components
Resources
The server implements a file search system:
Each file resource includes:
File name
Full path
File size
Creation date
Tools
The server provides one tool:
search-files: Searches for files matching a given path fragment.Takes
queryas a required string argument.Takes
directoryas an optional string argument to specify the base directory for the search. If not provided, the search runs in the root directory.Returns a list of matching files with their metadata.
Related MCP server: Find Library MCP Server
Quickstart
Install
Replace the contents of the cline_mcp_settings.json file with the following configuration:
{
"mcpServers": {
"file-finder-mcp": {
"command": "uv",
"args": [
"--directory",
"/Users/stleubaev/Desktop/ClineTest/file-finder-mcp",
"run",
"file-finder-mcp"
]
}
}
}Testing
The testing was conducted using the Gemini model with the following prompt:
hi can you find files called file_to_find on my desktop using my mcp serverAvailable Tools
1 toolsearch-filesC
Поиск файлов по фрагменту пути
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Фрагмент пути для поиска | |
| directory | No | Каталог для поиска | / |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does (searching) but lacks critical details such as search scope (e.g., recursive vs. shallow), performance implications, error handling, or output format. This leaves significant gaps in understanding the tool's behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool, though it could be slightly more structured by including key behavioral details to improve clarity.
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?
Given the lack of annotations and output schema, the description is incomplete. It fails to address important contextual aspects like what the search returns (e.g., file paths, metadata), how results are formatted, or any limitations (e.g., case sensitivity, supported file systems). This leaves the agent with insufficient information for reliable use.
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 schema description coverage is 100%, meaning the input schema fully documents both parameters. The description does not add any additional meaning or context beyond what the schema provides, such as examples or edge cases, so it meets the baseline score of 3 for high schema coverage.
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 'Поиск файлов по фрагменту пути' clearly states the purpose: searching files by path fragment. It specifies the verb (search) and resource (files), but since there are no sibling tools, it cannot demonstrate differentiation from alternatives, which is required for a score of 5.
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 provides no guidance on when to use this tool versus alternatives, prerequisites, or limitations. It merely restates the basic functionality without contextual usage instructions, which is insufficient for effective tool selection.
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 tool update
- First observed
search-files
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'search-files' has a clear and distinct purpose, so agents cannot misselect between non-existent alternatives.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The tool name 'search-files' follows a verb_noun pattern, but consistency cannot be assessed across a set of one.
A single tool is too few for most server purposes, as it severely limits functionality and scope. For a 'file-finder' server, one might expect additional tools like list directories, filter by type, or get file metadata, making this feel incomplete and thin.
The server's domain appears to be file searching, but with only a search tool, there are significant gaps. For example, no tools exist to navigate directories, retrieve file details, or handle errors, which could lead to agent failures in broader file-related tasks.
Maintenance
Related MCP Connectors
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Search a nightly-refreshed directory of MCP servers by keyword, category or topic.
Public MCP server for discovering open jobs. Search, filter, and get application links.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides tools for reading, writing, and editing files on the local filesystem.1,607Apache 2.0
- FlicenseNot gradedqualityDmaintenanceAn MCP server that enables searching for specific files by name within the current directory and its subdirectories. It uses Server-Sent Events (SSE) to provide a find_file tool for locating local files and libraries.-
- AlicenseNot gradedqualityCmaintenanceAn MCP server that enables file system search and inspection, including directory listing, regex-based file name and content searches, and reading text, PDF, and DOCX files.1MIT
- FlicenseNot gradedqualityDmaintenanceMCP server providing filesystem operations, shell execution, and web search capabilities.-