Brazilian legal stack in one MCP: lawsuits, court publications, case law, tenders, certificates.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotent, non-destructive), the description discloses that passing a token creates a session-only login, omitting it returns the link, and the recommended config approach gives a non-expiring connection. It does not detail failure behavior or whether an existing session is replaced, but the added context exceeds what the annotations provide.
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 relatively compact but awkwardly worded ('log in in the browser') and mixes setup instructions with tool-call semantics in one run-on passage. It is not excessively long, but readability and structure could be improved.
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 two usage modes and the optional token are covered, which is sufficient for basic invocation. However, with no output schema, the description never states what the tool returns on success or failure, and it leaves unclear how the agent should present the login-link flow to the user.
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?
Even though schema coverage is 0%, the description compensates by explaining the single token parameter: it is a JWT, optional, and omitting it triggers the no-args link flow. It could add more detail about token format or expiry, but for one parameter the semantics are well covered.
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 identifies the tool as authentication for MCP.AI with IDE agents and explains the two invocation modes (with a JWT token or with no arguments). It is clear about the resource, but it never explicitly uses a verb like 'authenticate' and does not differentiate itself from sibling tools such as 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?
It gives concrete when-to-use guidance: use the config header for a permanent connection or paste the token for a session-only login, and call with no args to get the login link. It does not mention alternatives/exclusions relative to sibling tools, but the intended usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context on response behavior under two conditions (all providers connected vs. missing credentials), including the return of authenticated, pending[], and URLs. This goes beyond the annotations and clarifies expected output, without contradiction.
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 two concise sentences. The first front-loads the core purpose, and the second adds condition-specific details. There is no redundant wording; every sentence contributes meaning.
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?
With no output schema, the description bears the full burden of explaining return values. It covers the all-connected and missing-credentials cases, but omits partial connectivity scenarios (e.g., some providers connected, others missing). It also does not specify the full response structure beyond the mentioned fields. For a simple status tool, this is adequate but leaves a notable gap.
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 takes zero parameters, and the schema coverage is trivially 100%. Per the rubric, the baseline for 0 params is 4. The description does not need to add parameter details since none exist, and it appropriately avoids inventing any.
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 returns connection status and URLs, using a specific verb and resource. It does not explicitly contrast with sibling 'authenticate', but the focus on status rather than authentication makes the purpose distinct enough for an agent to differentiate.
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 provides no guidance on when to use this tool versus alternatives like 'authenticate'. It does not mention prerequisites, typical call contexts, or exclusions. There is no implied usage context beyond the declarative statement of what it returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them. Covers capability requests like "find an MCP that does X", "consulta um CPF", "is there a tool for Y". Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile (every tool with its id + params, pricing, auth) so you pick the right tool_id → invoke RUNS that tool. KEY: invoke works even when the MCP is NOT installed — it runs the tool pontualmente (one-off), without adding the MCP to the toolkit and without bloating the tool list. If the MCP needs a credential/login, invoke returns a connect link; if it is paid and the wallet is empty, invoke returns a checkout/top-up link (the user opens it, then you retry). Use install only to make an MCP PERMANENT in the active toolkit (its tools then show up natively in future sessions); prefer invoke for a single/occasional use. list_tools lists what is callable right now. subscribe/cancel handle per-MCP billing; report_bug sends feedback; request_mcp asks us to build a NEW MCP when nothing fits. Search/describe flag installed_in_toolkit vs installed_in_workspace. Writes (install/uninstall/subscribe/cancel and the one-off install behind invoke) require workspace owner/admin. It also carries the mcp.ai PROMPT LIBRARY, which is about ready-made prompt TEXT rather than MCPs: search_prompts finds one, get_prompt returns its full text with {{variables}} filled, and publish_prompt saves a prompt and returns a shareable mcp.ai/p/ link that opens without login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| action | No | search | |
| mcp_id | No | ||
| message | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| immediate | No | ||
| tier_slug | No | ||
| prompt_body | No | ||
| prompt_slug | No | ||
| prompt_tool | No | ||
| prompt_vars | No | {} | |
| conversation | No | [] | |
| prompt_title | No | ||
| request_name | No | ||
| cancel_reason | No | ||
| cancel_comment | No | ||
| prompt_targets | No | ||
| report_context | No | ||
| prompt_category | No | ||
| request_details | No | ||
| prompt_description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: invoke runs tools one-off even when not installed, without bloating the toolkit; missing credentials return a connect link; empty wallet returns a checkout/top-up link; writes require workspace owner/admin. No contradiction with readOnlyHint=false, openWorldHint=true, idempotentHint=false, or destructiveHint=false.
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 content is dense and largely relevant, with no obvious filler, and it front-loads the core search→describe→invoke flow. However, it is one long paragraph covering many distinct concerns—actions, permissions, billing, prompt library—which makes it hard to scan; bullets or grouped sections would improve structure.
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 14-action dispatch tool with no output schema, the description covers the primary workflow, install-vs-invoke tradeoffs, connect/checkout fallbacks, permission requirements, billing actions, and the prompt-library subdomain. It does not explain return shapes or list_tools output, but the operational context is remarkably complete.
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?
There are 23 parameters with 0% schema description coverage, and the description does not compensate for most of them. It explains the action enum and some associated fields through prose, but leaves limit, immediate, tier_slug, conversation, prompt_targets, request_details, cancel_reason, and others without meaningful semantic guidance.
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?
Identifies itself as 'the official mcp.ai marketplace' and 'the in-platform catalog of every MCP/tool, AND the way to run them', which clearly states the resource and role. It cannot reach 5 because it is a multi-action dispatcher covering search, describe, invoke, install, prompts, etc., rather than a single verb+resource operation.
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 routing guidance: 'prefer invoke for a single/occasional use' versus 'use install only to make an MCP PERMANENT'. It also names sibling actions and their purposes—list_tools, report_bug, request_mcp, search_prompts—and explains when connect/checkout links require user action before retrying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a bug, missing feature, or send feedback. Include the conversation array with recent messages for reproduction.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | ||
| message | Yes | ||
| conversation | No | [] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and idempotentHint=true, but the description adds little behavioral context beyond the concept of sending/reporting. It does not explain what side effects occur, whether the report is stored, whether confirmation is given, or how retries might behave, despite the idempotentHint being somewhat surprising for a feedback/report tool.
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 two short sentences with no filler. It front-loads the purpose and then gives the key usage hint, making it easy to scan and act on.
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 tool with three parameters, no output schema, and zero schema description coverage, the description leaves major gaps: the purpose of message/context, the expected conversation format, and what the caller should expect after the call. The reproduction hint is useful, but not sufficient for confident invocation.
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?
Schema description coverage is 0%, so the description must compensate, but it only explains the conversation parameter's role in reproduction. The required message parameter is not explained, and context is completely undocumented, leaving the agent to infer their meaning from parameter names alone.
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 states a clear verb-resource pair: reporting a bug, missing feature, or sending feedback. It is immediately distinguishable from sibling tools such as authenticate, marketplace, and search_tools, which serve unrelated purposes.
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 when to use it: when the user wants to report a bug, request a feature, or give feedback. It also gives a specific instruction to include recent messages for reproduction, but it does not explicitly discuss when not to use it or mention any alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Single entrypoint for MCP catalog. action=search returns available tools ordered by relevance. action=describe returns tool schema. action=invoke executes a tool by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| action | No | search | |
| queries | No | ||
| tool_id | No | ||
| arguments | No | {} | |
| min_score | No | ||
| force_reindex | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose key behavior: search orders by relevance, describe returns schema, and invoke executes a tool by ID. But with all annotations set to false or unknown, the description carries the burden, and it omits side effects, authentication needs, and consequences of invoking arbitrary tools.
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 tight, front-loaded statement with no filler. Every clause earns its place by specifying a distinct action and return behavior.
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?
This is a multi-action, 7-parameter tool with no output schema. The description explains the routing but not the parameter contract, return shape, or operational risks, so an agent cannot reliably construct correct calls beyond the action switch.
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?
Schema description coverage is 0%, so the description must explain the parameters. It explains action and implies tool_id, but query, queries, arguments, min_score, and force_reindex are left undefined, including the important arguments format and score threshold semantics.
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 names a specific resource (MCP catalog) and a specific verb per action: search returns tools, describe returns schema, invoke executes by ID. It also labels itself as the 'single entrypoint,' which distinguishes it from catalog-adjacent siblings like marketplace and toolkit_info.
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 action= clauses give clear internal usage routing: choose search for tools, describe for schemas, invoke for execution. However, it does not explicitly contrast this tool with siblings or state when not to use it, so the guidance is more implied than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the current MCP platform and adapter versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds 'current' to indicate it retrieves live version info but does not add further behavioral context such as output format or potential errors. This is acceptable given the annotations, but not rich.
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 one short, front-loaded sentence with no filler. Every word contributes meaning: 'Show' identifies the action, and 'current MCP platform and adapter versions' specifies the exact output scope.
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 no-parameter, idempotent, read-only version tool, the description is complete. It tells the agent exactly what will be reported (platform and adapter versions), and the annotations cover the behavioral safety profile. No further context is needed for correct invocation.
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 description carries no parameter burden. With an empty input schema and 100% schema description coverage, there is nothing for the description to add; the baseline 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 uses a specific verb ('Show') and identifies a precise resource ('the current MCP platform and adapter versions'). This clearly distinguishes it from sibling tools like authenticate or marketplace, leaving no ambiguity about what the tool does.
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 by stating what it shows, but it does not explicitly mention when to use it versus alternatives or when not to use it. For a simple version-inspection tool, the context is fairly self-evident, yet no explicit guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by specifying exactly what state is reported (MCPs, connection status, accounts, catalog tool counts), making the response content predictable.
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?
A single, front-loaded sentence with no filler. Every clause adds concrete information about what the returned state includes.
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 parameterless read-only info tool, the description is complete: it states the operation, the exact content of the result, and annotations cover side-effect concerns. No output schema is needed because the return contents are enumerated.
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 takes zero parameters and schema coverage is 100%, so there is no parameter documentation burden. Baseline 4 is appropriate because the description fully compensates by telling what the tool returns.
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?
States a specific verb ('Returns') and resource ('current toolkit state') with enumerated contents: installed MCPs, connection status, connected accounts, and catalog tool counts. This clearly differentiates it from siblings like authenticate, connect, and 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 use whenever needing an overview of toolkit state, which is clear context for a read-only info tool. It doesn't explicitly state when not to use alternatives, but the focused scope makes confusion unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
authenticateconnectmarketplacereport_bugsearch_toolsshow_versiontoolkit_infoClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Full lookup of a person's or company's lawsuits from the CPF or CNPJ, with per-case detail. Platform
Open-source alternative to Jusbrasil for AI: find lawsuits by name, CPF, CNPJ or case number and bui
Case law search, court decisions and súmulas, across indexed public sources (STF, STJ, TST, state co
Free Brazilian CNPJ lookup (legal name, status, partners) + lawsuit discovery. Public data, no login
Add one secure layer between your agents and this server.
marketplace and search_tools both cover catalog search, describe, and invoke, making their boundaries unclear. connect and toolkit_info also overlap on reporting connection status, so an agent could easily select the wrong tool for the same task.
All names use lowercase snake_case, but the patterns vary: single-word verbs (authenticate, connect), a noun (marketplace), and compound nouns (toolkit_info). There is no consistent verb_noun convention, though the names remain reasonably readable.
Seven tools is a reasonable size for an MCP platform-management server, and most tools cover distinct operational areas. However, marketplace and search_tools overlap significantly, so the count could be trimmed without losing functionality.
The set covers authentication, connection status, catalog search and execution, toolkit state, version info, and bug reporting, which supports the core platform workflows. The main weakness is that install/uninstall/billing operations are buried inside the marketplace tool description rather than exposed as first-class tools.