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, which inform the agent that this is a safe, non-mutating operation. The description adds value by specifying exactly what information is returned (installed MCPs, connection status, accounts, catalog tool counts), which is beyond the annotations. However, it doesn't disclose any additional behavioral traits like potential latency or whether it requires network calls, so a score of 3 is warranted as it adds some context but not extensive.
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 clear and front-loaded with the verb 'Returns', immediately stating the purpose. It is concise and provides essential information without unnecessary details. It earns a 4 because it is efficient and well-structured, though it could be slightly more compact by trimming 'currently' and 'each one' without losing meaning, but it's nearly ideal.
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 that this tool has no parameters, no output schema, and is marked with read-only and idempotent annotations, the description is fairly complete. It outlines the key aspects of the tool's output: installed MCPs, connection status, accounts, and tool counts. It doesn't mention details like whether the state is live or cached, but for a simple info tool, this is sufficient. The sibling tools 'authenticate' and 'connect' are action-oriented, so this description stands on its own. A score of 4 is justified.
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 zero parameters, the description doesn't need to explain parameters, and the schema coverage is 100% (trivially, as there are no parameters). The description adds contextual meaning by indicating what the returned state includes, which is helpful for the agent to understand the purpose without any input. Since there are no parameters, a baseline of 4 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 what the tool does: it returns the current toolkit state, listing installed MCPs, their connection status, connected accounts, and the count of catalog tools per MCP. It is specific and uses a clear verb ('Returns'), and it distinguishes itself from sibling tools like 'authenticate' and 'connect' by focusing on state inspection rather than actions. It loses one point because it doesn't explicitly differentiate from 'show_version' or 'marketplace', but the content is distinct enough.
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 that this tool is for inspecting the toolkit's state, likely useful before or after connecting or authenticating, but it does not explicitly state when to use it or when not to use it. It doesn't mention alternatives or exclusions, so it provides only implicit guidance. A score of 3 is appropriate for implied usage without explicit context.
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.
The ANVISA consultation tool is clearly distinct, but several platform tools overlap: authenticate and connect both concern connection/auth, and marketplace and toolkit_info both expose catalog/install state. Detailed descriptions help separate them, so misselection is possible but not constant.
Most tools use lowercase English single-word names, while the actual domain tool uses Portuguese snake_case (anvisa_processo_consultar). The set mixes languages and naming styles, with no consistent verb_noun pattern across the server.
Seven tools is not inherently too many, but six are generic platform infrastructure tools (auth, marketplace, version, toolkit state) and only one serves the declared ANVISA Processo purpose. The count is misleading because the server's apparent scope is a single domain lookup.
The named domain is represented by one generic consultar operation, with no explicit listing, filtering, or related process/document operations. For a simple citizen-available lookup this may be functional, but the surface is shallow and offers little workflow depth.