Prefeitura SC Joinville: Clearance Certificate (Debts), official-source lookup. Platform-hosted, pay
Scored across 7 tools
Several tools overlap in purpose: authenticate, connect, and toolkit_info all deal with authentication/connection status, while marketplace subsumes capabilities like listing callable tools, reporting bugs, and invoking MCPs — including the CND consultation itself. Only pref_sc_joinville_cnd_consultar has a clearly unique, domain-specific purpose.
Names mix bare English verbs (authenticate, connect), a noun (marketplace), snake_case utilities (report_bug, show_version, toolkit_info), and a long Portuguese domain-specific name (pref_sc_joinville_cnd_consultar). There is no consistent verb_noun pattern, and language mixing makes the set feel arbitrary.
Seven tools is not an excessive number, but the composition is lopsided: only one tool actually serves the CND domain, while the other six are generic platform utilities. The count is borderline because a single domain tool feels thin despite the total number being reasonable.
For the stated purpose of consulting a Certidão Negativa de Débitos, the single domain tool covers the core operation, and supporting tools handle authentication, wallet/payment, and status concerns. Minor gaps such as batch queries or explicit PDF/issuance workflows are absent but likely out of scope or workaround-able.
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?
Annotations already indicate idempotent and non-destructive behavior. The description adds meaningful context: non-expiring vs session-only login, the token being a JWT, and that no-args returns the login link. This is sufficient for a simple tool, though it doesn't mention what happens with invalid tokens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the purpose front-loaded, followed by clear usage alternatives. Every clause adds value; no filler or redundant restatement.
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 only one optional parameter and no output schema, the description is complete: it covers both input modes, the no-argument case, and the permanent config alternative. An agent has all the information needed to invoke it 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 schema only defines `token` as a string with no description, so the description compensates well: it explains that `token` is a JWT for session-only login and that calling without it returns the login link. This adds the semantics the schema lacks.
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 an MCP.AI server for IDE agents via browser login and token. It distinguishes itself from sibling tools by explaining the two login modes (config header or session token), which is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: configure the token in the server config for permanent access, or call with a pasted token for session-only login, or call with no args to get the login link. This fully explains the invocation options and their trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful context by describing conditional outputs for all-connected vs missing-credentials scenarios, going beyond what annotations alone 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 with the core purpose and key behavior in the first sentence. No redundant information, clear and front-loaded.
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 parameters, the description covers the main edge cases (all connected vs. missing credentials). It could mention partial connectivity, but the core behavior is adequately described.
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 the schema has 100% coverage, so the parameter baseline is 4. The description does not need to explain parameters, and it doesn't.
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 that the tool returns connection status and URLs. It provides specific behavioral details (authenticated:true, pending[], connect_url) that distinguish it from sibling tools like authenticate or show_version.
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 the tool is used to check connection status, especially for provider connectivity, but it does not explicitly state when to use this tool instead of authenticate or other siblings, nor does it mention any exclusions.
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?
Annotations only provide generic flags, but the description discloses important behaviors: invoke runs tools even when the MCP is not installed, returns connect/checkout links for auth/payment, and may trigger a one-off install. It also states that writes require workspace owner/admin. No contradiction with annotations exists.
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 dense and every sentence adds substantive information, with the purpose front-loaded. However, it is one continuous, semicolon-heavy block of text with no visual structure (bullets, headings, or per-action separation), which reduces scannability despite the high information density.
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 14 actions, 23 parameters, and no output schema, the description covers the core flow, prompt library, permissions, auth/payment special cases, and installed-vs-workspace status flags. Gaps remain: the 'resume' action is never mentioned, and no return shape is described beyond links and flags. Still, it is substantially complete for an agent to select and invoke the 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?
With 23 parameters and 0% schema description coverage, the description carries a heavy burden and does compensate meaningfully by explaining action values and key parameters like tool_id, arguments, prompt_vars, and prompt_slug in context. However, many parameters such as limit, immediate, tier_slug, cancel_reason, conversation, report_context, and request_details are left unexplained.
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 establishes the marketplace as 'the official mcp.ai marketplace' and explains that it covers both discovery and execution of MCPs/tools, including capability requests like 'find an MCP that does X'. The core search → describe → invoke flow is explicitly laid out, which distinguishes it from siblings and makes the tool's 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 gives explicit decision guidance: 'prefer invoke for a single/occasional use' and 'Use install only to make an MCP PERMANENT'. It also names alternatives like request_mcp for new MCPs, list_tools for what is currently callable, and subscribe/cancel for billing. This is strong when-to-use and 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.
Prefeitura SC Joinville: Certidão Negativa de Débitos, consulta em fonte oficial. Hospedado pela plataforma, sem credenciais da plataforma, pague por consulta com crédito pré-pago. Consulta informação de fontes e órgãos oficiais brasileiros (a mesma disponível ao cidadão), não é dado sigiloso. O cliente é o controlador dos dados e responde pela finalidade legítima (LGPD).
| Name | Required | Description | Default |
|---|---|---|---|
| cpf | No | ||
| cnpj | No | ||
| inscricao_mobiliaria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description does not need to repeat that. It adds useful context about payment per query, no platform credentials needed, and LGPD compliance. However, it does not describe the exact response format or any limitations 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?
The description is concise and front-loaded with the key purpose. It includes necessary context about payment and LGPD in a few sentences. However, it could be slightly more structured, but overall it is efficient and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three parameters (likely alternative identifiers), no output schema, and annotations only provide read-only and idempotent hints, the description covers the basic purpose and payment model. However, it lacks details on which parameter should be used depending on the user type (PF or PJ), and it does not mention anything about response structure or error conditions. For a simple read-only query tool, this is adequate but not comprehensive.
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 three parameters: cpf, cnpj, and inscricao_mobiliaria, but no descriptions. The description does not elaborate on any of these parameters, leaving the agent to infer that they are alternative identifiers (CPF for individuals, CNPJ for companies, and municipal registration). Since schema coverage is 0% and the description adds no parameter-specific information, the agent must rely on the parameter names alone, which is somewhat clear but incomplete.
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: consulting Certidão Negativa de Débitos (negative debt certificate) from the official source of Prefeitura de Joinville. It specifies the resource (the certificate) and the action (consult), and distinguishes it from other tools in the context.
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 context that this tool accesses official Brazilian sources, is hosted on the platform, and requires prepaid credits. It implies when to use it (to check for debts with Joinville municipality) and mentions that it does not require platform credentials. However, it does not explicitly state when not to use it or mention alternative tools for other municipalities or certificates.
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 already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one behavioral detail: include the conversation array for reproduction. It does not mention what happens after submission or any limitations, but this is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the key instruction front-loaded. Every sentence earns its place. It is slightly imprecise in calling 'conversation' an array when the schema default is a string, but the text remains tight and readable.
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 feedback/reporting tool with no output schema and only three plain parameters, the description covers the main scenario and reproduction guidance. It is not fully complete because the required message parameter is not elaborated, but the tool's low complexity and straightforward purpose make the description adequate.
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 only explains the conversation parameter, calling it an 'array' while the schema defines it as a string. The required 'message' parameter and optional 'context' are never described, leaving the agent to infer their meaning from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear action 'Report' and names the resources: bug, missing feature, and feedback. This distinguishes it from unrelated siblings like authenticate, connect, and marketplace. It leaves little doubt about what the tool accomplishes.
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 clearly states the context for use: reporting a bug, missing feature, or feedback, and instructs the user to include the conversation array with recent messages. There are no exclusions or alternatives, but none of the sibling tools compete for this purpose, so the guidance is clear enough.
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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. It adds minimal context by specifying that both platform and adapter versions are shown, but does not disclose any additional behavioral traits like output format or side effects. The description is consistent 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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's purpose without any 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?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It clearly states what the tool does, and the annotations cover the safety profile. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema is empty with 100% coverage. No additional parameter semantics are 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 action (show) and the resource (current MCP platform and adapter versions). It is specific and unambiguous, effectively distinguishing from sibling tools like 'toolkit_info' by focusing on version details.
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 when version information is needed but provides no explicit guidance on when to use this tool versus alternatives. There are no exclusions or comparisons to sibling tools, so it falls short of explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current toolkit state: installed MCPs, their connection status, the accounts connected to each one, and how many catalog tools each exposes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by specifying exactly what is included in the state (installed MCPs, connection status, accounts, catalog counts), which goes beyond the basic safety profile. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the main verb 'Returns' and immediately provides specific details. Every word contributes to clarity, with no fluff or redundancy.
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 info tool with strong annotations, the description fully captures the tool's behavior and output. It covers the main aspects an agent would need to know, though it could theoretically mention error behavior or return format, but that seems unnecessary for this simple 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?
The tool has zero parameters, so the description does not need to explain any. It adds meaning by describing the output, which is sufficient given the absence of 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 it 'Returns the current toolkit state' and enumerates specific data points (installed MCPs, connection status, connected accounts, catalog tool counts). This makes the tool's purpose unambiguous and easily distinguishable from siblings like connect or authenticate, which handle different concerns.
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 whenever toolkit state information is needed, but it does not provide explicit context about when to prefer this tool over alternatives or mention any prerequisites. There are no exclusions or when-not-to-use scenarios, but the simplicity of the tool makes the implication sufficient.
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!
Prefeitura SC Itajaí: Clearance Certificate (Debts), official-source lookup. Platform-hosted, pay pe
Prefeitura SC Blumenau: Clearance Certificate (Debts), official-source lookup. Platform-hosted, pay
Prefeitura SC Florianópolis: Clearance Certificate (Debts), official-source lookup. Platform-hosted,
Prefeitura PR Curitiba: Clearance Certificate (Debts), official-source lookup. Platform-hosted, pay