Checks whether a company has signed a Leniency Agreement under the Anti-Corruption Law from the CNPJ
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 7 of 7 tools scored.
The set mixes a single domain-specific tool (acordos_leniencia_consultar) with several generic platform tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info). While most platform tools have distinct purposes, connect and toolkit_info both report status, and marketplace's broad meta-capabilities overlap with the dedicated tools, creating boundary confusion.
Tool names use inconsistent conventions: Portuguese snake_case (acordos_leniencia_consultar) alongside English single words and compound names (authenticate, report_bug, toolkit_info). There is no uniform verb_noun pattern, and the language switch adds inconsistency.
Seven tools is a reasonable count, but the scope is mismatched: the server name implies a leniency-agreement domain, yet six of seven tools are generic MCP platform utilities. This makes the tool set feel bloated with unrelated functionality or severely underpopulated with domain-specific tools.
The only domain-relevant tool is acordos_leniencia_consultar, a single query operation. There are no other read or write operations for leniency agreements (e.g., listing, filtering, detailed views), making the surface severely incomplete for the stated domain.
acordos_leniencia_consultarAVerifica se uma empresa celebrou Acordo de Leniência sob a Lei Anticorrupção a partir do CNPJ. Hospedado pela plataforma, sem credenciais, pague por consulta com crédito pré-pago. Consulta informação de ACESSO PÚBLICO em bases e fontes oficiais (a mesma disponível ao cidadão), não é dado privado nem sigiloso. O cliente é o controlador dos dados e responde pela finalidade legítima (LGPD).
| Name | Required | Description | Default |
|---|---|---|---|
| Cnpj | Yes | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description adds meaningful behavioral context: payment requirement, lack of credentials, public data source, and LGPD compliance responsibilities. This goes beyond the safety hints already provided, though it does not describe response format or error cases.
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 concise and well-structured. The main purpose is stated first, followed by hosting/payment details, then data privacy considerations. Every sentence adds value without unnecessary fluff.
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 description is complete for a simple tool but misses some key aspects: there is no output schema, so the description should mention what the tool returns, and the 'completo' parameter remains undefined. These are notable gaps given the lack of schema descriptions.
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 description explains that the tool queries using CNPJ, giving meaning to the main required parameter. However, it does not explain the 'completo' parameter at all. With 0% schema description coverage, this leaves a gap in understanding the optional parameter's purpose.
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 ('Verifica') and clearly names the resource ('Acordo de Leniência sob a Lei Anticorrupção a partir do CNPJ'). This unambiguously distinguishes it from unrelated sibling tools like 'authenticate' or 'report_bug'.
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 clear context: hosted on the platform, no credentials required, and paid via prepaid credit. It also states the data is public access, implying no special authorization is needed. However, it does not explicitly mention when to use this tool over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
authenticateAMCP.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?
The description discloses behavioral details beyond annotations: it explains that calling with no args returns a link, passing a token yields session-only login, and config header gives a permanent non-expiring connection. This complements the idempotentHint and readOnlyHint annotations 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 verbose and mixes purpose with step-by-step instructions. It could be streamlined into a clearer structure. Redundant phrasing like 'log in in the browser, copy the access token' adds wordiness.
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 simple tool (one optional param, no output schema), the description covers both authentication flows (permanent config and session token) and the no-args behavior. It is fully self-contained for an agent to invoke correctly.
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 'token' parameter is fully explained: it should contain a JWT pasted by the user. The description also specifies the no-args behavior, which is not evident from the schema. This adds significant meaning beyond the bare schema definition.
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: authenticating MCP.AI for IDE agents via browser login and token acquisition. It distinguishes from siblings like 'connect' by specifying the IDE-agent context. However, the purpose is somewhat buried within usage instructions.
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 provides explicit guidance: call with no args to get the login link, or pass a JWT token for session-only login. It also recommends permanent configuration via Authorization header, covering both use cases. This is sufficient for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
connectAReturns 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 declare readOnly, idempotent, and non-destructive behavior. The description adds value by explaining the conditional response fields (authenticated, pending, connect_url), increasing transparency about the tool's behavior beyond what 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?
Two concise sentences deliver the essential information without redundancy. The main verb and resource appear immediately, and conditional details are logically organized.
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 simple status tool with no parameters and no output schema, the description covers the two primary states (all connected vs. missing credentials). Minor ambiguity about partial connectivity remains, but it is adequate for the tool's simplicity.
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 accepts zero parameters, so there is nothing to explain. The description correctly focuses on the output behavior. Baseline of 4 is appropriate for parameterless tools.
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, with specific conditional behavior for all-connected versus missing-credential scenarios. This distinguishes it from siblings like authenticate, which likely performs authentication rather than checking status.
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 for checking connection status but does not explicitly contrast with authenticate or other sibling tools. It provides context through conditional outcomes but lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
marketplaceAInspectThe 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 works even when the MCP is not installed, returns a connect link if credentials are needed, returns a checkout link if wallet is empty, and does not bloat the tool list. It also explains installed_in_toolkit vs installed_in_workspace and permission requirements. No contradiction 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 long but each sentence adds essential information (flow, edge cases, permissions, prompt library). It is not broken into sections or bullets, making it a dense wall of text, but the complexity of the tool justifies the length. Slightly loses points for lack of formatting.
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 23 parameters and no output schema, the description is remarkably complete. It covers the core flow, fallback behaviors (connect/checkout links), distinction between invoke and install, permissions, and the prompt library sub-features. It gives enough context for an agent to navigate most scenarios without additional documentation.
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 23 parameters and 0% schema description coverage, the description must compensate but does not. It explains the `action` enum and the general flow (search→describe→invoke), but leaves many parameters (e.g., limit, immediate, tier_slug, prompt_vars, cancel_reason, request_details) unexplained. Agents would have to guess or experiment to understand these inputs.
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 identifies the tool as 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It uses specific verbs for sub-actions (search, describe, invoke, install) and distinguishes the tool from siblings by framing it as both catalog and execution engine.
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 gives explicit when-to-use guidance: 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT.' It also explains each action's role (list_tools, subscribe/cancel, report_bug, request_mcp) and notes write permissions (workspace owner/admin), helping agents decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_bugAReport 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 already indicate idempotentHint=true and readOnly=false. The description adds the behavioral requirement to include the conversation array for reproduction, which is useful context. However, it does not describe side effects, outcomes, or authentication needs beyond what annotations imply.
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, front-loaded with the purpose, and directly actionable. All words earn their place. No superfluous content.
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 3 params and no output schema, the description provides the core purpose and one key instruction. However, it omits information about the response or outcome after reporting (e.g., whether a ticket ID is returned), which might leave the agent uncertain about the result. It is minimally viable but not fully 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?
Schema description coverage is 0%, so the description must compensate. It explains the 'conversation' parameter ('with recent messages for reproduction') but leaves 'message' and 'context' ambiguous. The description does not clarify what format the message should take or what context is for, leaving the agent to guess.
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 action ('Report a bug, missing feature, or send feedback') with a specific verb and resource. It also adds a requirement (conversation array) and distinguishes itself from unrelated sibling 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 provides clear context for when to use the tool: when reporting a bug, missing feature, or feedback. It does not explicitly name alternatives or exclusions, but given the unrelated sibling tools, this is not necessary. The scope is evident from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
show_versionAShow 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety traits. It does add that the tool shows both platform and adapter versions, offering slight contextual detail beyond the annotation.
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, front-loaded sentence with no wasted words. It conveys the essential information efficiently and is appropriately sized for the tool's simplicity.
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, read-only tool without an output schema, the description adequately states its purpose and output content. It is complete relative to the tool's simplicity and the rich annotations provided.
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, which earns a baseline of 4. The description adds no parameter info, but none is needed since the schema is empty. Coverage is complete, so no further semantic guidance is required.
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 function with a specific verb ('Show') and resource ('MCP platform and adapter versions'). It distinguishes itself from sibling tools by focusing solely on version information, making its purpose unambiguous.
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 does not explicitly state when to use this tool versus alternatives, but its purpose is self-evident for retrieving version info. There is no mention of exclusions or comparisons, which keeps it at an implied usage level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_infoAReturns 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 readonly, idempotent, and non-destructive behavior. The description adds value by detailing what the returned state includes (connection status, accounts, tool counts), but does not disclose further behavioral traits such as potential latency or the exact structure of the response. This is consistent with the calibration example where annotations carry the safety burden and the description adds context.
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 front-loads the core purpose ('Returns the current toolkit state') and then lists the specific components included. No redundant or filler content.
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 must convey what the tool returns, and it does so comprehensively by naming all key data points (installed MCPs, status, accounts, catalog tool counts). It does not specify the response format, but for a simple informational tool this is sufficient and no other context is needed.
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 input schema has zero parameters, so the baseline is 4. The description is not required to explain any parameters and correctly focuses on the return value.
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 the current toolkit state and enumerates its contents (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from siblings like authenticate or connect, which perform actions rather than report state.
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 this tool (when you need a snapshot of toolkit state and connections) without explicitly naming alternatives or exclusions. Sibling tools like show_version or connect provide different functionality, but no direct 'use this instead' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.