Credit score and analysis for people and companies: score, dossier, defaults, positive reports, Cent
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?
The description explains the two modes of operation (permanent config vs. session-only) and the side effect of generating a login link when called without arguments. It does not explicitly detail rate limits or other behavioral aspects, but it does not contradict the annotations (idempotentHint: true aligns with the description of calling with no args to get a link). Minor deduction for not describing error handling or edge 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 a compact paragraph that front-loads the purpose. It includes an example call format and covers both auth modes without being overly verbose. However, it could benefit from some light structuring (e.g., bullet points) to separate the permanent and session-only flows.
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 an authentication tool with one optional parameter and no output schema, the description provides the necessary context for both usage modes. It lacks details on the exact URL or the token validation process, but given the tool's simplicity and the presence of sibling tools that don't overlap, it is reasonably 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?
The schema provides only a 'token' string with no description or format. However, the description explicitly explains the parameter's meaning: the token is a JWT that can be passed for session-only login. This adds significant meaning beyond the raw schema, but it could be more precise about the expected format or validation rules.
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 handle user authentication for MCP.AI, allowing login via a browser, and supporting both permanent and session-only tokens. It distinguishes itself from the sibling tools (credit checks, marketplace) by focusing on the authentication flow.
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 explains when to use this tool: when a user needs to log in, and provides a clear distinction between permanent (config header) and session-only (pass token) auth. It also implicitly contrasts with other tools, as none of the siblings handle authentication.
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 declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds value by detailing the two possible return states (authenticated:true with empty pending[] vs connect_url and per-install URLs), which is beyond what annotations provide. It does not contradict 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 extremely concise, consisting of two sentences that fully explain the tool's behavior. Every word earns its place, and it is front-loaded with the core purpose.
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 status check, the description is complete. It explains both possible outcomes (all connected vs missing credentials) and the returned URLs. With annotations covering safety and no output schema required, the description fully equips the agent to understand and invoke the tool 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 tool has zero parameters, so per guidelines the baseline is 4. The description adds no parameter information because there are none, and the schema coverage is 100% (trivially). The description does not need to elaborate on parameters.
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: it returns connection status and URLs. It distinguishes itself from siblings like 'authenticate' by focusing on status retrieval rather than performing authentication, and it specifies the two possible output states which is very specific.
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 for checking connection status and what to expect in different states. It does not explicitly exclude alternatives or state 'use this when you need to check connectivity', but the context is clear from the tool name and sibling set. It adds behavioral expectations that help the agent decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detalhamento de negativações/pendências de um CPF ou CNPJ.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully cover the safety profile. The description adds no behavioral context beyond naming the operation type, such as data sources, response format, or pagination. With annotations present, the bar is met but not exceeded, so a score of 3 is appropriate.
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, straightforward sentence with no wasted words. It front-loads the action and resource, making it easy to scan. However, it is arguably too terse, sacrificing completeness for conciseness, though that is mitigated by the separate low scores on other dimensions.
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 parameters and no output schema, the description is notably incomplete. It does not explain what output the user can expect, nor does it clarify the distinction between CPF and CNPJ input, or the meaning of 'completo'. Given the sibling tools present overlapping functionality, the lack of contextual detail leaves the tool under-specified for an AI agent to correctly select and use it.
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%, and the description does not compensate for the lack of parameter explanations. The description mentions 'CPF ou CNPJ' but does not clarify that only one should be provided, nor does it explain the 'completo' boolean flag (whether it toggles full vs summary details). The parameters are left ambiguous, making correct invocation difficult.
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 the verb 'detalhamento' (detail) and specifies the resource as CPF/CNPJ, conveying a clear purpose of providing negative registrations/pendencies details. It distinguishes itself from sibling tools like 'credito_score' (score) and 'credito_protestos' (protests) by focusing on negativações, though it could be more explicit about what kind of detail (e.g., list of entries, dates, amounts).
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 alternative credit tools such as 'credito_dossie' or 'credito_scr_detalhada'. It does not state prerequisites (e.g., requiring CPF or CNPJ) or scenarios where this tool is preferred. The only hint is the name itself, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dossiê de crédito completo de um CPF ou CNPJ.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond that, such as whether it aggregates data or if it's expensive. It doesn't contradict annotations, but adds no extra value. Per rubric, with annotations, we credit for adding context; it doesn't, so a 3 is appropriate.
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, highly concise and front-loaded. It wastes no words, though it could be more structured with param details. But it's efficient.
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?
No output schema, and the description gives no indication of what the complete dossier contains, nor does it explain the drei parameter semantics. It's minimal but not complete for a tool with 3 parameters and no 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?
Schema has 0% description coverage for parameters (CPF, CNPJ, completo). The description does not explain these parameters at all. It doesn't clarify that CPF is for individuals, CNPJ for companies, or what 'completo' means. The description fails to compensate for the schema's lack of parameter documentation.
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 'Dossiê de crédito completo de um CPF ou CNPJ.' clearly states the tool provides a complete credit dossier for a CPF or CNPJ. However, it does not explicitly differentiate from sibling tools like credito_relatorio_pf_completo or credito_scr, which may also provide comprehensive reports. The purpose is clear for a specific resource, but lacks differentiation.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or scenarios where this tool is preferred over siblings like credito_protestos or credito_score. It's a bare statement with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Limite de crédito sugerido (positivo) de pessoa jurídica.
| Name | Required | Description | Default |
|---|---|---|---|
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds 'sugerido' and 'positivo' implying the output is a suggested positive value, which is useful but minimal. No mention of side effects, data sources, or auth requirements, but annotations lower the bar.
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 extremely concise and front-loaded, but it is too terse, missing critical context that could be added without much verbosity. It is efficient but under-informative.
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 and zero parameter coverage, the description should explain what 'completo' does and the nature of the returned limit. It doesn't, leaving significant gaps for a tool with only two parameters.
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% and the description provides zero explanation of either parameter. 'CNPJ' (likely) and 'completo' are not described at all, offering no added meaning beyond raw type definitions.
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 specific resource (suggested positive credit limit) and the target (legal entity, PJ). It clearly distinguishes from sibling tools like credito_risco_pj or credito_scr, focusing on a limit value rather than risk or reports.
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, no prerequisites, and no exclusions. It simply states what it returns without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protestos em cartório (nacional) por CPF/CNPJ.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the national scope, which is useful context, but it does not disclose behavior like authentication requirements, response format, or limitations (e.g., whether both CPF and CNPJ can be used simultaneously). Since the annotations carry the main safety information, a moderate score is appropriate.
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 concise sentence with no extraneous words. It is front-loaded with the core purpose and is appropriately sized for a tool with a clear function, achieving high conciseness without omitting essential purpose information.
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 has 3 parameters, no output schema, and no parameter descriptions, the description is insufficient. It does not explain the meaning of 'completo', potential response structure, or any usage constraints. While annotations provide safety context, the description lacks behavioral and usage detail needed for an agent to correctly use the tool, especially with sibling tools that may offer more specific variants.
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 minimally explains that the query is by CPF or CNPJ, which gives some meaning to those parameters. However, the boolean 'completo' is completely unexplained, and with 0% schema description coverage, the description fails to clarify any parameter semantics beyond the obvious document type. No distinction is made between CPF and CNPJ usage (e.g., mutual exclusivity).
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 'Protestos em cartório (nacional) por CPF/CNPJ' clearly indicates the tool retrieves notary protest records nationally by CPF or CNPJ. It distinguishes from the sibling 'credito_protestos_sp' by explicitly stating 'nacional', though it lacks a verb and is more of a noun phrase than an action statement.
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?
No guidance is provided on when to use this tool versus alternatives. It does not specify when to prefer this over 'credito_protestos_sp' or other credit-related tools, nor does it mention any exclusions or prerequisites. The 'nacional' hint is implicit but not elaborated as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Protestos em cartório de SP por CPF/CNPJ.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context such as auth requirements or data format, but it does not contradict the 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 a single, concise sentence that directly states the tool's function. It is front-loaded with no extraneous words, earning its place.
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 and no output schema, the description is thin. It does not explain the 'completo' parameter, the nature of the returned data, or any prerequisites. It leaves the agent guessing about how to use the tool effectively.
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 mentions searching by CPF or CNPJ, giving meaning to those parameters, but it does not explain the 'completo' boolean parameter. With 0% schema description coverage, this leaves one parameter undocumented in both schema and description.
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 indicates the tool retrieves notary protests for São Paulo based on CPF/CNPJ. It distinguishes from the sibling 'credito_protestos' through the 'SP' suffix, though it lacks an explicit verb like 'fetch' or 'list'. The resource and scoping are clear.
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 for São Paulo-specific protest data but provides no explicit when-to-use guidance or alternatives. It does not mention when to use this over 'credito_protestos' or other tools, relying on the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relatório de crédito completo (positivo) de pessoa física.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| completo | No |
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 clear. The description adds only that it's a 'complete (positive)' report, without disclosing return format, data scope, or any side effects. It does not contradict annotations but also provides minimal additional 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, short sentence, which is concise and front-loaded. It contains no unnecessary words. However, while appropriately brief, it omits critical details, but conciseness itself is not penalized for under-specification.
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 2 parameters, no output schema, and no nested objects, the description is severely under-specified. It fails to explain parameter semantics, return expectations, or any distinctions from similar tools. Given the sibling tools, the description does not provide enough context for an agent to confidently select and use this tool.
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 carries full responsibility for explaining parameters. It does not explain what the 'CPF' format should be, what the 'completo' boolean controls, or whether either parameter is required. The description's mention of 'completo' is ambiguous and does not clarify the 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 indicates the tool provides a complete (positive) credit report for an individual (CPF). It distinguishes from siblings like 'credito_detalhamento_negativo' which focuses on negative details. However, it lacks a specific verb (e.g., 'Generates') and could be more explicit about the output.
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?
No guidance is provided on when to use this tool versus its siblings, such as 'credito_relatorio_pf_mais' or 'credito_score'. There is no mention of prerequisites, typical use cases, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Relatório de crédito (positivo, intermediário) de pessoa física.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| completo | No |
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 cover the main behavioral traits (safe, read-only, idempotent). The description adds minimal context beyond the type of report ('positivo, intermediário'), but it does not mention any rate limits, authentication requirements, or output format, relying on annotations for behavioral disclosure.
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, short sentence that is front-loaded with the core purpose. It is concise without superfluous content, though it could benefit from a bit more detail without losing efficiency.
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 tool has no output schema and minimal annotation coverage, so the description must explain the tool's behavior, parameters, and context. It only covers a basic purpose, leaving the agent without information on how the CPF should be formatted, what the 'completo' flag does, and what the report contains beyond 'positivo, intermediário'. This is inadequate given the tool's complexity and the many sibling tools.
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 coverage is 0%, and the description provides no explanation of the 'CPF' and 'completo' parameters. The 'completo' boolean is ambiguous (does it mean include all sections?), and no format for CPF is given. The description fails to compensate for the lack of schema documentation, leaving the agent to guess parameter meaning.
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 generates a credit report for an individual (pessoa física), specifying it is 'positivo, intermediário' (positive, intermediate). This distinguishes it from sibling tools like 'credito_relatorio_pf_completo' (complete) and 'credito_detalhamento_negativo' (negative), though it does not explicitly contrast with them.
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?
No guidance is provided on when to use this tool versus the alternatives. With many sibling credit report tools (e.g., 'credito_dossie', 'credito_scr', 'credito_relatorio_pf_completo'), the agent lacks context to choose the right one, making usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Risco de crédito (positivo) de pessoa jurídica.
| Name | Required | Description | Default |
|---|---|---|---|
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds only a small semantic boundary by specifying 'positive' credit risk, but it does not disclose output format, scope changes from 'completo', or data-source caveats.
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 or redundant wording. The parenthetical '(positivo)' is an efficient discriminator, though the brevity leaves operational gaps.
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 two parameters, no output schema, and no parameter descriptions, the one-line description is not enough for an agent to know what results to expect or how 'completo' changes the response. It also lacks guidance for choosing among closely related credit-report siblings.
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%, and the description does not explain CNPJ or 'completo'. The phrase 'pessoa jurídica' makes CNPJ's role inferable, and 'completo' is a self-descriptive boolean, but the description adds no concrete meaning about output completeness or default behavior.
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 conveys that the tool is about positive credit risk for legal entities, and the '(positivo)' qualifier helps distinguish it from negative-detail siblings. However, it is a noun phrase rather than a verb+resource statement, and it does not explicitly say what action the tool performs, such as retrieving or consulting a report.
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?
There is no when-to-use guidance, no exclusions, and no reference to sibling alternatives. The '(positivo)' tag implies a contrast with negative-detail tools, but the description never tells the agent when to choose this over 'credito_score', 'credito_limite_pj', or 'credito_dossie'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score de crédito de um CPF ou CNPJ.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read nature is covered. The description adds no behavioral context beyond that, such as the score range, whether it returns a numeric value, or any limits. With annotations carrying the safety profile, the description contributes nothing extra.
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 sentence, which is concise and front-loaded with the main purpose. However, it is under-specified; it earns its place by stating the function but does not include necessary elaboration on parameters or usage, making it too terse for adequate guidance.
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 and zero parameter descriptions, the description should explain return values and parameter semantics. It does neither. The single sentence gives only the basic purpose, leaving the agent uninformed about expected results, edge cases, or the meaning of the 'completo' parameter, making it severely incomplete for a tool with 3 optional params and siblings.
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 3 parameters with zero descriptions (schema coverage 0%), so the description must compensate. It mentions 'CPF ou CNPJ' indicating either can be used, but does not clarify whether both can be provided simultaneously, nor does it explain the 'completo' boolean flag. This minimal addition barely assists with parameter understanding.
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: 'Score de crédito de um CPF ou CNPJ.' It specifies the resource (credit score) and the input types (CPF or CNPJ), distinguishing it from sibling tools like credito_dossie or credito_relatorio_pf_completo, which likely provide different report types. It is specific and not a tautology.
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, such as whether it should be used for a quick score versus detailed reports from siblings. It does not mention prerequisites, typical use cases, or exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resumo do SCR do Banco Central (histórico de crédito) — exige autorização do titular.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by stating that explicit holder authorization is required, which is not captured by the 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 a single focused sentence that front-loads the core purpose and adds the key authorization constraint. It contains no redundant or vague filler, making it highly concise.
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?
Despite good annotations, the description is too sparse for the tool's actual invocation needs: no parameter semantics, no output format, and no explicit comparison to related sibling tools. The authorization note helps, but overall the description leaves substantial gaps for correct selection and use.
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%, and the description does not explain the meanings of CPF, CNPJ, or the 'completo' boolean. Without any parameter guidance, an agent cannot determine whether to supply CPF, CNPJ, both, or how 'completo' affects the returned summary.
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 resource as the Central Bank SCR credit history summary and indicates it provides a summary-level view, which differentiates it from the sibling credito_scr_detalhada. However, it lacks an explicit verb like 'retrieves' or 'returns', so it is slightly below a fully explicit purpose statement.
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 phrase 'Resumo do SCR' implies summary-level usage and contrasts with the more detailed sibling tools, but there is no explicit guidance about when to choose this over credito_scr_detalhada or related reports. The authorization requirement is mentioned but no when-to-use or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SCR detalhado do Banco Central — exige autorização do titular.
| Name | Required | Description | Default |
|---|---|---|---|
| CPF | No | ||
| CNPJ | No | ||
| completo | No |
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 the useful authorization requirement, but does not describe what happens without authorization, what data is returned, or other runtime behavior.
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 filler. It is appropriately short for what it directly says, though it would benefit from more parameter or usage detail elsewhere.
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 optional parameters, no output schema, and many related siblings, one sentence is insufficient. It does not clarify the distinction between detailed and standard SCR, what data appears in the report, or how to correctly select CPF/CNPJ/completo.
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% and the description does not explain CPF, CNPJ, or 'completo'. The property names give some hints, but the agent is left without knowing whether one identifier is required, how they interact, or what 'completo' actually controls.
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 a 'SCR detalhado do Banco Central' and adds a key condition (holder authorization). This gives a usable sense of purpose and 'detalhado' loosely distinguishes it from the sibling credito_scr, though it lacks an explicit verb such as 'obtém' or 'consulta'.
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?
'Exige autorização do titular' is a prerequisite/context signal, implying the tool should only be used when holder authorization exists. However, it does not explain when to use this tool instead of credito_scr or the other sibling credit report tools.
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?
The description discloses key behaviors beyond annotations: invoke runs tools even if not installed (one-off, without adding to toolkit), returns connect links for auth and checkout links for payment, and requires workspace owner/admin for writes. Annotations (readOnlyHint=false, openWorldHint=true) are not contradicted; the description adds crucial context about permissions and runtime behavior.
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, dense paragraph with no formatting (bullets or sections). While it contains valuable information for a complex tool, it is overly verbose and could be more concise. It starts with purpose but then rambles through many sub-actions without clear organization, making it less scannable than it could be.
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?
Despite no output schema and complexity (23 params, 14 actions), the description covers the core flow, key edge cases (invoke when not installed, auth/payment links), permission requirements, and the separate prompt library. It even notes the installed_in_toolkit vs installed_in_workspace distinction, providing a comprehensive overview for an agent to properly select and invoke the appropriate action.
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 0% schema description coverage, the description carries the burden of explaining 23 parameters. It directly or indirectly explains most key ones: action enum values, query (for search), mcp_id, tool_id, arguments, tier_slug (billing), prompt-related params (prompt_body, prompt_slug, prompt_vars, etc.), and report_bug's message. However, some params like conversation, prompt_title, prompt_targets, cancel_reason are not explicitly detailed, leaving a few gaps.
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 explicitly states the tool is 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' This clearly identifies the verb (catalog/run), resource (MCPs/tools), and scope (in-platform), distinguishing it from sibling credit-check tools that have 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 provides a clear core flow ('action=search discovers MCPs by intent → describe returns one MCP's full profile... invoke RUNS that tool') and explicitly advises when to use invoke vs install: 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT in the active toolkit.' It also explains when to use subscribe/cancel, list_tools, report_bug, and request_mcp, covering both when to use and when not to.
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 declare idempotentHint=true and destructiveHint=false, so the agent knows repeated calls are safe and non-destructive. The description adds the useful behavioral context that providing the 'conversation array' aids reproduction, which is beyond what annotations provide. However, it doesn't describe what happens after submission (e.g., no response, internal ticket creation), but annotations cover the safety profile well.
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 very concise, two sentences that directly address the tool's purpose and a key usage hint. Every word earns its place; no filler or redundancy. It could benefit from a tiny bit more structured formatting (e.g., separating types), but for its length it's efficient.
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?
Has no output schema, so the description should explain what the agent will receive after reporting. It doesn't state whether the tool returns a ticket ID, success message, or just an acknowledgment. The three parameters are described only partially (context is unmentioned). For a simple reporting tool with annotations clarifying safety, this is passable but leaves return value and full param coverage unclear.
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 has to compensate. It mentions 'conversation array' which maps to the 'conversation' parameter, and implies 'message' is the core text. However, the 'context' parameter is left undocumented, and the format of the conversation array (JSON string?) is not clarified. This is a clear gap but the basic semantics of two of three params are inferred.
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 verb ('Report') and resources ('a bug, missing feature, or send feedback'), which is specific enough to distinguish it from sibling tools that focus on credit/information tasks. It lacks explicit differentiation from a hypothetical feedback tool but is unambiguous in its intent.
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 ('Report a bug, missing feature, or send feedback') but does not explicitly state when not to use it or name alternative tools. Given the sibling list contains no similar tool (all are data/credit/tool info tools), the implied guidance is adequate but not 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?
Annotations already declare the tool readOnly, idempotent, and non-destructive. The description adds only that it reports current versions, with no additional behavioral caveats, side effects, or operational details. It does not contradict the 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 one short sentence that fully conveys the tool's purpose. There is no padding, repetition, or unnecessary detail.
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 zero parameters, rich annotations, and the trivial nature of a version-check tool, the description is complete enough for an agent to select and invoke it correctly. It clearly states what information the agent will get back (current MCP platform and adapter versions).
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 and 100% schema coverage of parameters, so there is nothing missing from the schema. Per the guidance, the zero-parameter baseline is 4; the description need not add parameter details where none exist.
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 a clear resource ('current MCP platform and adapter versions'), making the tool's function immediately obvious. It also distinguishes this from sibling tools like authenticate and connect, since none claim to display version information.
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?
There is no explicit statement about when to use this tool or which alternatives to prefer. However, as a zero-parameter informational tool, the intended usage is largely self-evident; still, no exclusions or context 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 indicate read-only and idempotent behavior. The description adds value by detailing the returned information (installed MCPs, connection status, accounts, catalog tool counts), which is beyond what annotations convey.
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, concise sentence that directly states the purpose without unnecessary words or repetition.
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 fully covers what the tool returns, including all key components (installed MCPs, connection status, accounts, catalog tool counts). No output schema is provided, but the description sufficiently indicates the expected information.
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 no parameters, so the description adds no parameter-specific meaning. Per the rubric, with 0 params the baseline is 4; the description does not need to explain anything further.
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, listing specific aspects (installed MCPs, connection status, accounts, catalog tool counts). This is a distinct verb-resource combination that differentiates it from sibling tools like credit queries.
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 explains what the tool does but does not explicitly state when to use it relative to alternatives. While it's clear this is for general state inspection, it lacks guidance on scenarios or exclusions compared to the high-scoring example.
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.
No tool schema history has been recorded yet.
Claiming 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 credit dossier of a person or company: registration data, risk score, and delinquencies. Platfo
Credit score and risk analysis of a person or company. Platform-hosted, no credentials, pay per quer
Delinquencies of a person or company: protests, lawsuits, recoveries, and other restrictions. Platfo
Consumer credit check from a CPF: registration data, score, delinquencies, and history. Platform-hos
Add one secure layer between your agents and this server.
Several credit tools overlap heavily, such as credito_dossie vs credito_relatorio_pf_completo, credito_relatorio_pf_mais vs credito_relatorio_pf_completo, and credito_score vs credito_risco_pj. The marketplace tool also blurs the server's identity by providing generic platform capabilities that overlap with connect and toolkit_info.
Most tool names use consistent snake_case, and the credit tools follow a clear 'credito_' prefix pattern. However, generic platform tools like marketplace, report_bug, show_version, and toolkit_info break the semantic verb_noun pattern, creating a minor inconsistency.
At 17 tools, the server is on the heavier side. The credit-specific subset (13 tools) is reasonably scoped, but the inclusion of non-domain tools (marketplace, report_bug, show_version, toolkit_info) inflates the count and makes it feel bloated for a credit-focused server.
The credit data domain is well covered, including negative records, positive reports, protests, SCR, score, risk, and credit limits. The only noticeable gaps are the absence of writing operations (e.g., update/delete) and the disconnect between the platform tools and the credit domain, but the core read-only workflows are thorough.
