HyperStore MCP gives you access to a curated directory of 6,500+ AI applications, letting any MCP-compatible LLM client discover, search, browse, and compare AI tools.
Tools
search_apps — Keyword-based full-text search returning name, slug, description, pricing, and rating
ai_search — Semantic/embedding-based natural language search (e.g. "something like Midjourney but free"), returning up to 12 ranked results
get_app — Full details for a specific app by slug: long description, features, screenshots, pricing, rating, and website URL
list_apps — Paginated listing with optional filters for category, pricing model, and keyword, sorted by popularity
list_categories — All 30+ categories with app counts
category_apps — Apps within a specific category, optionally filtered by pricing
browse_apps — Alphabetical A–Z directory browsing by starting letter (or # for digits/symbols)
get_homepage — Trending apps, top categories, and catalog overview/stats
Resources
hyperstore://app/{slug} — Markdown rendering of an app's detail page
hyperstore://category/{slug} — Top apps in a given category
hyperstore://catalog — Full category index
Prompts
find_tool_for_task — Guided discovery to find the right AI tool for a specific task
compare_apps — Side-by-side comparison of multiple apps
discover_category — Explore a topic or category of AI tools
Allows OpenAI models to search, browse, and get details of 6,500+ AI applications from the HyperStore catalog via the Responses API.
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., "@HyperStore MCP Find me a free AI tool that summarises PDFs."
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.
Plug 6,500+ AI apps into any LLM via the Model Context Protocol.
HyperStore is a curated directory of 6,500+ AI applications, developed by HyperGPT. This MCP server exposes the HyperStore catalog to any LLM client — Claude, ChatGPT, Cursor, Windsurf, Cline, Zed, Gemini, and anything else that speaks MCP.
Ask your LLM:
"Find me a free AI tool that summarises PDFs." "Compare ChatGPT, Claude, and Gemini side-by-side." "Show me the top 5 image-generation apps with an API."
The LLM calls HyperStore MCP behind the scenes and answers with up-to-date, curated results.
13 tools:
Tool | Purpose |
| Full-text keyword search |
| Embedding-based semantic search |
| Full app detail (features, screenshots, pricing) |
| Paginated apps with filters (category, pricing) |
| Browse all 30+ categories |
| Apps within a category |
| A-Z directory listing |
| Trending + top categories overview |
| Curated alternatives to an app |
| Audience segments (developers, lawyers, …) |
| Best AI tools for an audience |
| Use-case taxonomies (legal-contracts, …) |
| AI tools for a use case |
3 resources:
hyperstore://app/{slug} — markdown rendering of any app
hyperstore://category/{slug} — top apps in a category
hyperstore://catalog — full category index
3 prompts:
find_tool_for_task — guided discovery for a task
compare_apps — side-by-side app comparison
discover_category — explore a topic
Related MCP server: Hermes Atlas MCP Server
uvx (zero install, recommended)Requires uv. One command and you're done:
uvx hyperstore-mcppipxpipx install hyperstore-mcp
hyperstore-mcpdocker run --rm -p 8080:8080 ghcr.io/deficlow/hyperstore-mcp
# Now MCP Streamable HTTP at http://localhost:8080/mcpUse our managed Streamable HTTP server:
https://mcp.store.hypergpt.ai/mcpEdit ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"hyperstore": {
"command": "uvx",
"args": ["hyperstore-mcp"]
}
}
}Restart Claude → tools appear in the 🛠 menu.
claude mcp add hyperstore -- uvx hyperstore-mcp.cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"hyperstore": {
"command": "uvx",
"args": ["hyperstore-mcp"]
}
}
}~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"hyperstore": {
"command": "uvx",
"args": ["hyperstore-mcp"]
}
}
}settings.json:
{
"cline.mcpServers": {
"hyperstore": {
"command": "uvx",
"args": ["hyperstore-mcp"]
}
}
}~/.config/zed/settings.json:
{
"context_servers": {
"hyperstore": {
"command": {
"path": "uvx",
"args": ["hyperstore-mcp"]
}
}
}
}~/.gemini/settings.json:
{
"mcpServers": {
"hyperstore": {
"command": "uvx",
"args": ["hyperstore-mcp"]
}
}
}Settings → Connectors → Add custom connector:
Name: HyperStore
MCP Server URL: https://mcp.store.hypergpt.ai/mcp
Authentication: None
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-4.1",
tools=[{
"type": "mcp",
"server_label": "hyperstore",
"server_url": "https://mcp.store.hypergpt.ai/mcp",
"require_approval": "never",
}],
input="Find me 3 free AI tools for writing unit tests.",
)
print(response.output_text)from anthropic import Anthropic
client = Anthropic()
response = client.messages.create(
model="claude-opus-4-7",
max_tokens=1024,
mcp_servers=[{
"type": "url",
"url": "https://mcp.store.hypergpt.ai/mcp",
"name": "hyperstore",
}],
messages=[{"role": "user", "content": "Top 5 AI image generators?"}],
)See examples/ for ready-to-paste configs for every supported client.
For self-hosting, use the Docker image.
For direct invocation without Docker, the CLI accepts --transport http|sse
(see hyperstore-mcp --help).
When self-hosting, these environment variables can be set
(see .env.example for the full list):
Variable | Default | Purpose |
|
| Bind host (http/sse transports) |
|
| Bind port (http/sse transports) |
|
| Logging level ( |
git clone https://github.com/deficlow/HyperStore-MCP
cd HyperStore-MCP
uv sync --all-extras
uv run pytest
uv run hyperstore-mcp # stdio mode for local testingInspect the running server with the official MCP Inspector:
npx @modelcontextprotocol/inspector uvx hyperstore-mcpHyperStore MCP is a thin async wrapper around the HyperStore public REST API. It is read-only — no credentials, no writes, no PII. The same data that powers the website powers the MCP server. Updates land in your LLM the moment they land on the site.
LLM client ──MCP──▶ hyperstore-mcp ──HTTPS──▶ store.hypergpt.ai/apiMIT © HyperGPT
Natural-language semantic search powered by embeddings. Best for fuzzy intent ('a tool that helps me write Python tests', 'something like Midjourney but free'). Returns up to 12 apps ranked by semantic similarity.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Natural-language description of what the user is looking for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it uses embeddings, ranks by semantic similarity, and returns up to 12 apps. This provides clear expectations about behavior and output, though it could mention if authentication is needed or if results are from a specific database.
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?
Two sentences: first states purpose, second gives usage hints and result details. Every sentence is information-dense with no filler. Perfectly concise and front-loaded.
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 simple single-parameter input and no output schema, the description covers all needed aspects: what it does, when to use, how it works (embeddings), and what is returned. No gaps present.
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?
Schema coverage is 100% and the description mostly restates the schema's 'Natural-language description' with additional examples. Since the schema already explains the parameter well, the description adds only marginal value (e.g., examples), so baseline 3 is appropriate.
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 it is a semantic search for apps using embeddings. It provides examples of fuzzy intent queries, which distinguishes it from sibling tools like search_apps (presumably keyword-based). However, it does not explicitly name alternatives, making it a 4 rather than a 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 explicitly says 'Best for fuzzy intent' and gives concrete examples, guiding when to use. It also mentions the result limit (up to 12 apps). However, it does not state when not to use or explicitly compare to siblings, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse apps A-Z by starting letter. Use letter='#' for apps starting with digits or symbols. Useful for alphabetical discovery rather than search.
| Name | Required | Description | Default |
|---|---|---|---|
| letter | Yes | A single letter A-Z, or '#' for digits/symbols. | |
| pricing | No | Filter by pricing model: 'free', 'freemium', 'paid', 'free-trial', 'subscription', or 'one-time'. | |
| cursor | No | Pagination cursor (app id from prior page). | |
| limit | No | Max results per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lacks details on pagination behavior, rate limits, error handling, or what happens with invalid letters. Beyond the schema, it adds minimal behavioral insight.
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?
Two sentences, front-loaded with the core action, no redundancy. Every sentence is necessary and informative.
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?
With 4 parameters and no output schema, the description should explain what the response contains (e.g., app names, IDs, details). It omits return value information and pagination behavior, leaving the agent with gaps.
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?
Schema coverage is 100%, so baseline is 3. The description adds marginal value by clarifying the letter parameter format and pricing filter options, but these are already described in the schema.
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 tool browses apps alphabetically by starting letter, with specific handling for digits/symbols using '#', and distinguishes it from search by emphasizing alphabetical discovery.
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 context by contrasting with search ('rather than search'), which implicitly guides usage, but it does not explicitly list alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get apps within a specific category. Returns the category metadata plus a paginated list of apps in that category, sorted by popularity.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | URL slug, e.g. 'chatgpt' or 'ai-image-tools'. | |
| pricing | No | Filter by pricing model: 'free', 'freemium', 'paid', 'free-trial', 'subscription', or 'one-time'. | |
| cursor | No | Pagination cursor (app id from prior page). | |
| limit | No | Max results per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool returns category metadata and a paginated list sorted by popularity, which implies read-only behavior. However, it does not mention error handling (e.g., invalid slug), rate limits, or required permissions.
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, front-loaded sentence that efficiently conveys the tool's purpose and behavior. No superfluous words or unnecessary details.
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 absence of an output schema, the description adequately describes the return (category metadata + paginated list) and notes sorting by popularity. The four parameters are fully documented in the schema. Minor omission: no mention of error responses or edge cases.
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?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional semantic context beyond summarizing the pagination and filtering, which is already in the schema. Baseline score of 3 is appropriate.
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 action ('Get apps within a specific category') and specifies the output includes category metadata and a paginated list sorted by popularity. This distinguishes it from sibling tools like list_categories (which lists categories) and search_apps (which searches across categories).
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 implies usage for browsing apps by category but does not explicitly state when to use this tool versus alternatives (e.g., list_categories for category listing, search_apps for queries). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full detail page for a single AI app by slug: long description, features, screenshots, categories, pricing, rating, website URL, source attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | URL slug, e.g. 'chatgpt' or 'ai-image-tools'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists the returned fields (description, features, screenshots, etc.), providing good transparency. However, it does not mention idempotency or any prerequisites.
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 sentence that is concise and informative, front-loading the main action and listing key return fields without extraneous text.
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?
The description enumerates the return fields, compensating for the lack of an output schema. It is complete for a simple fetch tool, but could mention error handling (e.g., app not found).
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 input schema covers the single parameter slug with a description. The tool description adds no further semantics beyond the schema, so baseline score of 3 is appropriate.
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 verb 'Fetch' and the resource 'full detail page for a single AI app', specifying it is accessed by slug. This distinguishes it from sibling tools that return lists (list_apps, search_apps).
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 implies usage when you have a slug, but does not explicitly state when to use this over siblings like list_apps or search_apps. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the HyperStore homepage payload: top categories with their featured apps, the trending apps strip, and totals. Good first call to give the user a broad overview.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Homepage pagination — page 1 returns trending + stats. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the payload contents and pagination behavior (page 1 returns trending + stats). Adding safety traits (e.g., read-only) would improve it, but current disclosure is sufficient.
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?
Two sentences with no wasted words. The purpose and components are front-loaded, making it efficient.
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 tool's simplicity (one optional param, no output schema), the description fully covers what the tool does, its return components, and pagination. No gaps remain.
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?
Schema coverage is 100% (one parameter 'page' described). The description adds overall context but does not enhance parameter meaning beyond the schema's description. Baseline 3 is appropriate.
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 tool fetches the HyperStore homepage payload and lists its components (top categories, featured apps, trending strip, totals). It distinguishes itself from siblings by emphasizing a broad overview, making it a specific verb+resource combination.
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 explicitly recommends it as a 'good first call' for a broad overview, providing clear context. However, it does not explicitly state when not to use it or list alternative tools, which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paginated apps listing with optional filters. Combine category, pricing, and a free-text query to drill down. Returns apps sorted by popularity. Use cursor (last app id from previous page) to paginate.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category slug to filter by. | |
| pricing | No | Filter by pricing model: 'free', 'freemium', 'paid', 'free-trial', 'subscription', or 'one-time'. | |
| query | No | Optional keyword filter. | |
| cursor | No | Pagination cursor (app id from prior page). | |
| limit | No | Max results per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: results are sorted by popularity, pagination uses a cursor (last app id), and filters can be combined. This adds value beyond the schema by explaining the sorting and pagination mechanism.
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?
Two concise sentences that front-load the purpose and immediately provide actionable guidance. No wasted words; every sentence contributes essential information.
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 5 optional parameters, no required ones, and no output schema, the description adequately covers usage (filtering and pagination). It could mention default values or rate limits, but it is sufficient for an agent to invoke correctly.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context by explaining how to combine filters and paginate, e.g., 'Use cursor (last app id from previous page) to paginate.' This goes beyond the schema's individual parameter descriptions.
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 it is a 'Paginated apps listing with optional filters', listing specific filter types and pagination behavior. It distinguishes itself from sibling tools like 'search_apps' by focusing on filtering and sorting by popularity, though not explicitly naming alternatives.
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 guidance on when to use: for a paginated list with filters, and how to combine filters and paginate. However, it does not specify when to avoid this tool or mention direct alternatives, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all HyperStore categories with app counts. Use this first when the user asks 'what kinds of AI tools are there?' or to discover available category slugs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description fully communicates the tool's behavior: listing categories with counts. Since there are no parameters or side effects, the description is adequately transparent. Could mention if there are any limits, but given simplicity, this is sufficient.
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?
Two sentences, no fluff. Front-loaded with the core action, followed by usage context. Every sentence adds value.
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 tool is a simple list with zero parameters and an output schema, the description covers purpose, typical use case, and value. No missing information.
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?
No parameters exist, so schema coverage is 100%. Description does not need to add parameter details. Baseline score of 4 for zero-parameter tools.
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?
Description clearly states it lists all HyperStore categories with app counts, and provides a specific use case ('when the user asks 'what kinds of AI tools are there?' or to discover available category slugs'). This differentiates it from sibling tools like list_apps and category_apps.
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?
Explicitly instructs to use this tool first for category discovery, with example queries. Provides clear guidance on when to use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search HyperStore's AI apps directory by keyword. Returns a paginated list of matching apps with name, slug, short description, pricing, and rating. Use this when the user gives concrete keywords (e.g. 'image upscaler', 'code copilot').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. | |
| limit | No | Max results per page. | |
| cursor | No | Pagination cursor (app id from prior page). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions pagination but does not disclose whether the operation is read-only (likely but not stated), what happens on invalid input, or any authentication or rate limits. The behavioral context is minimal beyond the schema.
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 extremely concise: two sentences. The first sentence states the primary action and resource. The second provides usage guidance and return information. No unnecessary words, and front-loaded with the core purpose.
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 search tool with 3 parameters and no output schema, the description adequately covers purpose, usage, and return fields. It does not detail pagination mechanics or error handling, but given the schema covers the pagination cursor and limit, it is reasonably complete. Could be improved by noting ordering or result count.
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?
Schema coverage is 100%, and the description adds value by indicating that the 'query' parameter is used for keyword search and that results include specific fields (name, slug, short description, pricing, rating). This supplements the schema descriptions, though details for 'limit' and 'cursor' are not expanded further.
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 action ('Search') and the resource ('HyperStore's AI apps directory by keyword'). It distinguishes from siblings like 'browse_apps' or 'category_apps' by emphasizing keyword-based search. The return fields (name, slug, short description, pricing, rating) are listed, providing specificity.
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 explicitly says 'Use this when the user gives concrete keywords (e.g. 'image upscaler', 'code copilot').' This provides clear context for when to invoke the tool. However, it does not mention when not to use it or suggest alternatives like 'browse_apps' or 'category_apps' for non-keyword exploration.
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.
v0.1.0ai_searchbrowse_appscategory_appsget_appget_homepagelist_appslist_categoriessearch_appsEach tool has a clearly distinct purpose: ai_search for semantic search, search_apps for keyword search, browse_apps for alphabetical browsing, category_apps for category browsing, get_app for details, get_homepage for overview, list_apps for filtered paginated listing, and list_categories for category listing. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case: `ai_search`, `browse_apps`, `category_apps`, `get_app`, `get_homepage`, `list_apps`, `list_categories`, `search_apps`. No deviations.
8 tools is an appropriate number for an app directory MCP server. Each tool covers a specific access pattern (search, browse, detail, categories, homepage) without being overly many or too few.
The tool set provides comprehensive coverage for an AI apps directory: multiple search methods (semantic and keyword), multiple browse methods (alphabetical, category, paginated filters), detail retrieval, category listing, and homepage overview. No obvious gaps for a read-only directory.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered SaaS tool discovery API. Search 150+ curated business tools and get recommendations.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/deficlow/HyperStore-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
