Single entrypoint for MCP catalog. action=search returns available tools ordered by relevance. action=describe returns tool schema. action=invoke executes a tool by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| action | No | search | |
| queries | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| min_score | No | ||
| force_reindex | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides only surface-level action descriptions without disclosing potential side effects, especially for the invoke action which executes a tool and may be mutating or require authentication. All annotations are false, so they provide no safety context. The description fails to convey any behavioral traits beyond the basic action outputs.
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 exceptionally concise—three sentences, each covering one action, with no fluff or redundancy. The opening phrase 'Single entrypoint for MCP catalog' immediately establishes context, and the action= format is consistent and easy to parse.
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 complexity (7 parameters, multi-action, no output schema), the description is far from complete. It does not describe return formats (e.g., what fields are returned for search), parameter combinations for each action, error handling, or side-effect warnings. It provides only a minimal overview that leaves many operational details ambiguous.
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?
With 0% schema description coverage, the description must explain parameters, but it only clarifies the 'action' enum values. Other parameters like query, queries, tool_id, arguments, min_score, and force_reindex are left unexplained. Even tool_id is only implied for describe/invoke rather than explicitly tied to those actions.
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 identifies this as the single entrypoint for the MCP catalog and specifies three distinct actions (search, describe, invoke) with their immediate effects. This differentiates it from sibling tools like authenticate and marketplace, making its purpose unmistakable.
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 context by calling itself the 'single entrypoint' for catalog operations, which suggests it should be used for all catalog-related tasks. It lists the available actions but does not explicitly state when not to use it or mention alternatives, though sibling tools are clearly unrelated in scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
marketplace and search_tools both provide search/describe/invoke capabilities for the MCP catalog, creating significant overlap. Additionally, connect and toolkit_info both report connection status, leading to boundary confusion between these pairs.
All tool names use lowercase with underscores, but the structural pattern varies: one-word verbs (authenticate, connect), a noun (marketplace), and verb_noun compounds (report_bug, search_tools, show_version, toolkit_info). This is readable but lacks a consistent convention.
Seven tools is well within the ideal 3-15 range for this platform management server, and each tool earns its place in the workflow without feeling bloated or sparse.
The toolkit covers authentication, connection status, catalog discovery/execution, installation/subscription (through marketplace actions), feedback, and versioning. Minor gaps exist in dedicated management operations, but core lifecycle coverage is strong.