MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | 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?
Annotations indicate readOnlyHint=false and idempotentHint=true, and the description adds valuable behavioral context: it explains that providing a token results in a session-only login, while configuring as a header gives a permanent connection. It also implies that calling with no args returns a link. This goes beyond the annotations without contradicting them.
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 front-loaded with the core action and then expands into usage details. It is somewhat dense with parentheticals and options, but each clause serves a purpose. Slightly verbose, but not wasteful.
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 moderate complexity (authentication with two modes), the description covers invocation, persistence, and token usage. There is no output schema, but the description implies the tool returns a link or confirmation, which is sufficient for an auth tool. It provides enough context without requiring additional details.
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 single optional parameter 'token' is well-explained: it is used for session-only login by pasting the JWT, and omitting it triggers the link retrieval. Although schema description coverage is 0%, the description compensates fully for the one parameter.
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 the tool's purpose: to authenticate by logging in via browser and obtaining an access token, with options for permanent or session-scoped tokens. It is not a tautology and identifies the key action (authenticate/log in), but it does not explicitly differentiate from the sibling 'connect' tool.
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?
Provides explicit usage guidance: recommends adding the token as a header for a permanent connection, or pasting it for a session-only login. It also explains two invocation modes (with token argument or no arguments to get a link), leaving no ambiguity about when and how to use it.
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.
Several tools serve unrelated purposes: authenticate/connect/marketplace/toolkit_info/report_bug/show_version are platform infrastructure, while only cro_ba_cadastro_consultar provides actual dental registration data. There's functional overlap between connect and toolkit_info (both report connection status), and between marketplace and the general platform tools, creating ambiguity about which tool handles a given request.
Tool names are highly inconsistent: some use generic English verbs (authenticate, connect, report_bug, show_version), one uses Portuguese domain language (cro_ba_cadastro_consultar), and two use noun-only names (marketplace, toolkit_info). No consistent verb_noun or other pattern is followed.
Seven tools is a reasonable count, but the mix is skewed: only one tool actually serves the stated domain (Brazilian dental registration queries), while six are platform utilities that might belong to a separate server. This makes the count feel disproportionate for the server's stated purpose.
For a server titled 'Conselho Regional de Odontologia BA: Cadastro', there is only one domain tool (cro_ba_cadastro_consultar) that can only query. There are no tools to verify, parse, store, or manage queried data, no batch operations, and no other dental council resources. The remaining tools are unrelated platform utilities, leaving the domain surface severely incomplete.