mcp-harbor-search
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_toolsA | Search the MCP Harbor directory of MCP servers, clients and SDKs by keyword, optionally filtered by category. Returns the best matches ranked by relevance and GitHub stars. |
| get_toolA | Get the full MCP Harbor listing for one tool by its slug (as returned by search_tools). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: search_tools finds listings by keyword/category, while get_tool retrieves a specific listing by slug. There is no realistic overlap or ambiguity in selection.
Both names follow the same snake_case verb_noun pattern, search_tools and get_tool. Singular/plural use is natural and predictable.
A two-tool search-and-detail surface is minimal but well matched to a directory lookup server. The count is slightly thin under the general 3-15 guideline, but each tool earns its place.
The core lifecycle of searching the directory and fetching a specific listing is covered. Minor gaps could include browsing all entries or listing categories, but agents can work around these via search.