govbr-apis-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DATAJUD_API_KEY | No | API key for DataJud, as shown in the example Claude Code configuration. | |
| GOVBR_CATALOG_DIR | No | Replaces the base catalog entirely and should be treated as trusted input. | |
| TRANSPARENCIA_API_KEY | No | API key for the Portal da Transparência, as shown in the example Claude Code configuration. | |
| GOVBR_EXTRA_CATALOG_DIR | No | Point to a directory of .yaml or .yml files whose same-id entries win over the base catalog. | |
| GOVBR_EXTRA_ALLOWED_HOSTS | No | Add a host to the allowlist for catalog entries. The same hostname rule (`[a-z0-9.-]`) applies to it. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_catalogA | Search the government API catalog by keyword (accent-insensitive; matches name, provider, tags and description). category filters to: 'public' (free, callable today), 'meia-entrada' (half-price ticket eligibility sources), 'serpro' (commercial, needs contract) or 'conecta' (requires public-sector adhesion, not callable yet). |
| list_apisA | List catalog entries, most useful with a filter. category: public | meia-entrada | serpro | conecta. status: available | unstable | manual_only | requires_contract | requires_public_entity. Note the catalog holds ~95 Conecta stubs that are not callable yet, so an unfiltered listing is mostly noise — filter by category or status. |
| describe_apiA | Describe an API from the catalog. Without Paths from the spec are relative to the API's base_url — pass them to call_api unchanged. |
| call_apiA | Call an endpoint of a catalog API; base URL and credentials are resolved for you.
Returns {status, url, body} (JSON parsed, text cut at 60k chars); a 3xx is not followed
and carries its absolute |
| credentials_statusA | Show which APIs have credentials configured. Without api_id, reports every catalog entry that requires auth, so you can see what is ready to call.
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
search_catalog and list_apis both enumerate catalog entries and both accept category filters, so their boundary is somewhat blurry (keyword vs. filter is the only real differentiator), though the descriptions do explain the intent. describe_api, credentials_status and call_api each target a clearly distinct facet of the workflow.
Four of five tools follow a clean verb_noun pattern (search_catalog, list_apis, describe_api, call_api). credentials_status breaks it with a noun_noun form, and there is a minor singular/plural mismatch (list_apis vs. describe_api), but overall the naming reads predictably.
Five tools is exactly right for a catalog gateway: one search, one list, one schema lookup, one credential check, one invocation. Each earns its place with no redundancy or padding.
The surface covers the full discover→describe→verify-credentials→call lifecycle, and call_api handles methods, bodies, headers and error/redirect reporting. The only minor gaps are the absence of any way to configure credentials or page through large result sets, both of which an agent can work around.