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 | |||
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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, informing the agent this is a safe read operation. The description adds valuable context by listing exactly what state is returned (installed MCPs, connection status, connected accounts, catalog tool counts), going beyond the annotations. No contradictions with 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, well-structured sentence that leads with the key action ('Returns') and then lists the specific components of the toolkit state. Every phrase adds meaning; there is no waste or redundancy.
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 (0 parameters, no output schema) and the strong annotation coverage (read-only, idempotent, non-destructive), the description is complete. It specifies all the key state components an agent would need to decide whether to invoke it and what to expect from the response.
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 0 parameters, so the input schema is trivially 100% covered. Per the rubric, a tool with 0 parameters gets a baseline of 4. The description appropriately focuses on return value rather than parameters, so no additional parameter explanation is needed.
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 the specific verb 'Returns' and names concrete resources: 'current toolkit state', including 'installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.' This clearly distinguishes the tool from siblings like show_version (which likely only returns version info) and action-oriented tools like authenticate and connect.
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 the tool should be used to inspect the overall toolkit state, but it does not explicitly state when to prefer it over alternatives such as show_version or connect. No exclusion criteria or alternative tool names are mentioned, so usage guidance is only implied.
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.
Each tool has a clear primary purpose: authenticate, query CNEP, connect, marketplace, report bug, show version, and toolkit info. The only overlap is between connect and toolkit_info, both of which report connection status, but their roles are otherwise distinct.
Tool names mix bare verbs (authenticate, connect), a noun (marketplace), noun_verb (cnep_consultar), and verb_noun (report_bug, show_version), with inconsistent use of underscores. There is no uniform pattern, which makes the set feel haphazard.
Seven tools is within the acceptable range, but the balance is skewed: only one tool (cnep_consultar) addresses the server's apparent domain, while the other six are generic platform utilities. This makes the count feel inflated for a CNEP-focused server, though each tool does have a role.
For the CNEP domain, the set provides only a single lookup operation, with no options for broader searches, history, or data export. The platform utilities are comprehensive for their meta-purpose, but they do not fill the domain coverage gap.