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?
Annotations already declare read-only, idempotent, non-destructive behavior, so no contradiction exists. The description adds context by specifying the returned information granularity (which MCPs are installed, their connection status, associated accounts, and catalog tool counts). It doesn't explicitly note staleness or system-call behavior, but for a simple getter, the disclosure is adequate.
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, information-dense sentence with the key verb upfront. It uses a colon to introduce a list of returned state elements, which is efficient. It loses a single point for the ability to be slightly more compact, though this level of detail is arguably necessary to convey the range of state covered.
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 zero-parameter tool with no output schema, the description provides a complete picture of the return value. It could potentially mention the default behavior, but that's a minor point. It's complete for its intended purpose.
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?
This tool has zero parameters, and schema coverage is effectively 100% at 100% per context signals. The baseline for zero-parameter tools is 4, and the description adds value by clearly enumerating the output state details, going beyond the baseline.
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?
Uses a specific verb ('Returns') with a clear resource ('current toolkit state') and enumerates the contained data (installed MCPs, connection status, connected accounts, catalog tool counts). This is readily distinguishable from its siblings by its description of a state-inspection operation; 'connect' and 'authenticate' are clearly different actions.
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 has no explicit when-to-use guidance or alternative tools. However, as an information-gathering tool, its use case is clear and largely unambiguous from the phrasing 'current toolkit state.' There is no mention of when not to use it, such as 'to modify connection status, use connect instead.'
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 distinct core purpose: auth, connection status, the ECAC query, the marketplace, bug reporting, version info, and toolkit state. However, there's some overlap between `connect` and `toolkit_info` (both surface connection state), and `marketplace` is a multifunction blob that also covers billing, prompts, and other capabilities an agent might expect as separate tools.
Most tools follow a clean lowercase verb_noun pattern (authenticate, connect, report_bug, show_version, toolkit_info), but `ecac_perdcomp_consultar` breaks the pattern entirely—it's snake_case but in Portuguese and uses a different verb ordering. This naming mixes languages, making the set feel inconsistent even though the convention itself (utterances separated by underscores) holds.
With 7 tools, the server falls comfortably in the ideal 3-15 range. The count feels right for a platform bootstrapping an ECAC integration: one domain-specific tool plus six infrastructure/meta tools. No tool feels redundant enough to cut, though the market place tool could arguably be split.
For a read-only tax query service, the single `ecac_perdcomp_consultar` tool covers the core use case. However, there's no history, balance/credit check, or query status tool exposed at the top level, and the marketplace's generic dispatch is too broad to guarantee discovery of what the platform can really do.