Returns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful detail about the returned data, but doesn't disclose any additional behavioral nuances such as whether the call hits a live service or requires authentication. This is a modest increase over annotations.
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, tightly structured sentence that immediately states the result and then lists the key components. No filler or repetition. Every clause 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?
The tool is simple with no parameters and no output schema, so the description carries the full burden. It explains what will be returned (installed MCPs, connection status, accounts, tool counts), which is complete enough for an agent to understand the tool's purpose and expected output. It doesn't mention error behavior or format, but the task complexity is low.
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 tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameters, and it correctly avoids inventing any. The focus on return content is appropriate for a parameterless tool.
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 uses a specific verb ('Returns') and clearly identifies the resource: current toolkit state. It itemizes the exact contents (installed MCPs, connection status, accounts, catalog tool counts), which distinguishes it from sibling tools like show_version or search_tools.
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: you would call this to inspect toolkit state. However, it provides no explicit guidance on when to use this instead of other tools, nor does it mention alternatives or exclusions. The context is clear but not elaborated.
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 have significant overlap, with both covering search, describe, and invoke actions for the MCP catalog. connect and toolkit_info also both provide connection/status information, creating ambiguity about which to use for state checks.
Tool names mix verb-only (authenticate, connect), noun-only (marketplace), and verb_noun patterns (report_bug, search_tools, show_version, toolkit_info). There is no consistent convention, making the naming feel chaotic.
Seven tools is a reasonable count for a management/marketplace utility. However, the broad marketplace tool bundles many sub-operations that could arguably be split, and the server name 'Olist Tiny ERP' suggests a completely different domain, making the count feel misaligned with expectations.
Within the MCP management domain, the tools cover authentication, connection status, catalog search/execution, version info, and bug reporting. Gaps include no dedicated tool for managing installed MCP configurations or direct access controls beyond what's bundled in marketplace. The server name implies ERP functionality entirely absent, making the surface incomplete for the stated name.