Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@govbr-apis-mcp search the catalog for APIs about public spending"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that turns Brazilian government APIs into Claude-callable tools through a catalog-driven gateway: instead of one tool per endpoint (hundreds — would blow up client context), five generic tools operate over a local YAML catalog of 116 APIs.
Only the entries that declare an openapi_url have a spec to load: today the Câmara dos
Deputados and the Portal da Transparência, 2 of the 116. For those, describe_api loads
the OpenAPI spec on demand. Every other callable entry (see the "Callable today?" column
below) is reached through call_api alone, using the endpoints in its description and
docs_url.
Tier | File | Access model | Callable today? |
|
| Free — no auth or free API key (IBGE, Banco Central, Câmara, Senado, Portal da Transparência, DataJud, Ipeadata, dados.gov.br…) | Yes |
|
| Serpro commercial (loja.serpro.gov.br) — OAuth2 client credentials per contracted API, paid per call | With a Serpro contract: set the |
|
| Eligibility sources for half-price tickets (student CIE, ID Jovem, PcD, e-MEC) — see docs/meia-entrada.md and the POC | CIE yes (DNE and FESN); the rest is manual |
|
| Conecta gov.br — restricted to public-sector entities; 95 APIs indexed as stubs for discovery | Not yet (adhesion pending) |
The Conecta tier exists so the catalog reflects the whole landscape now, and becomes
callable later by filling in base_url + credentials — the OAuth2 client-credentials
flow is already implemented (Serpro uses the same one).
Related MCP server: MCP Brazil Public Data
search_catalog(query, category?) — accent-insensitive keyword search; reports total
matches and whether the list was truncated.
list_apis(category?, status?, limit?) — enumerate entries, callable ones first (by the
catalog's status, not by whether your credentials are set; filter it: ~95 Conecta stubs
otherwise dominate the output).
describe_api(api_id, path?, method?) — catalog metadata + OpenAPI operation list;
with path, parameter/request/response schemas ($refs inlined, depth-limited). Reads
OpenAPI 3 and Swagger 2.0, as JSON or YAML.
call_api(api_id, path, method?, query?, body?, headers?) — invoke an endpoint; base URL
and auth resolved from the catalog entry.
method is GET, HEAD, POST, PUT, PATCH, DELETE or OPTIONS; anything else returns an
error with allowed_methods. A body is accepted only with POST, PUT and PATCH.
path is relative to the base_url. . and .. segments (after up to three rounds of
percent-decoding, with \ read as / and ; parameters removed) and any path that
leaves the base_url prefix are rejected. So is a # (a fragment is never sent; write a
literal one as %23) or a control character.
A query string embedded in path is merged with query; a key in query replaces the
embedded one, and a list value repeats the key.
Caller headers are matched case-insensitively, with _ equal to -. Authorization,
Proxy-Authorization, Host, Cookie and Accept-Encoding, plus connection, proxy,
forwarding and method-override headers, are dropped and reported in ignored_headers
(the full list is in server.py). The managed credential is applied last and always wins.
A header with an invalid name or value is not ignored: it fails the call with an error.
Method, body, headers and path are validated before any OAuth2 token is requested, and
invalid input comes back as {"error": ...}.
A 3xx is not followed: the response carries its location (redacted, resolved
against the requested URL). Response bodies are cut at 60,000 characters.
credentials_status(api_id?) — which env vars each API needs and whether they're set,
plus callable: whether call_api would accept the entry right now (available and
unstable entries; requires_contract ones only once their env vars are set).
Fluxo funcional ponta a ponta (código da CIE → decisão de elegibilidade), incluindo
modo demo sem credencial: poc/README.md.
python3 -m venv .venv
.venv/bin/pip install -e '.[dev]'
.venv/bin/pytestRegister in Claude Code (.mcp.json or claude mcp add):
{
"mcpServers": {
"govbr-apis": {
"command": "/path/to/govbr-apis-mcp/.venv/bin/govbr-apis-mcp",
"env": {
"TRANSPARENCIA_API_KEY": "...",
"DATAJUD_API_KEY": "..."
}
}
}
}From PyPI: uvx govbr-apis-mcp (set "command": "uvx" and "args": ["govbr-apis-mcp"]
in the entry above; no checkout needed). Each release is published to PyPI and to the MCP
Registry automatically (publish.yml).
Or run it in a container. The server speaks stdio, so keep -i:
docker build -t govbr-apis-mcp . && docker run -i --rm -e TRANSPARENCIA_API_KEY=... govbr-apis-mcpAll secrets come from env vars declared per entry in the catalog (auth_config).
Nothing is stored in the repo. .env.example lists the variables. Entries with a free key
carry a signup_url; Serpro credentials come with the contract, at loja.serpro.gov.br.
credentials_status reports readiness.
The server does not read .env files, and MCP clients start it with a minimal environment,
so an export in your shell may never reach it. Put the variables in the client's env
block (the example above, or claude mcp add -e KEY=value). For a container, copy
.env.example to a git-ignored file such as .env.local, fill in the copy and pass it
with docker run --env-file .env.local. Never put real values in .env.example: it is
versioned.
API keys (the value together with any prefix) are stripped of surrounding whitespace and
must be printable ASCII; otherwise the call fails with credential in <VAR> contains invalid characters, without echoing the value. OAuth2 client ids and secrets are only
stripped: they travel base64-encoded, so any text works. The access token the endpoint
returns must be printable ASCII too. When the token endpoint fails, the call returns an
error and the token_url, with neither the response body nor any secret.
Auth profiles: none, api_key (static header, optional value prefix — e.g.
DataJud's APIKey <key>), oauth2_client_credentials (token endpoint + id/secret,
in-memory token cache; used by Serpro today, by Conecta after adhesion).
Add an entry to a YAML file in src/govbr_apis_mcp/catalog_data/. The directory is package
data, so the wheel, uvx and the Docker image all carry the catalog. Minimum fields:
id, name, provider, category, status, auth. Add openapi_url when the API
publishes a spec — describe_api then works with zero code. Regenerate the Conecta
tier with .venv/bin/python scripts/scrape_conecta.py. It leaves the file alone when the
page yields no APIs, an id the catalog would reject, or fewer than half the current
entries (--force overrides only the last check).
Entries are validated on load: ids must be filename-safe, URLs must be https on an
allowlisted host (*.gov.br, *.leg.br, *.jus.br plus a few named hosts), and a hostname
may only contain [a-z0-9.-] (write internationalized names in punycode). This is a
security boundary, not style — the catalog decides where your credentials are sent. Add a
host with GOVBR_EXTRA_ALLOWED_HOSTS only if you trust it with them; the same hostname
rule applies to it.
To override entries without forking (e.g. filling in Conecta base URLs after adhesion),
point GOVBR_EXTRA_CATALOG_DIR at a directory of .yaml or .yml files whose same-id
entries win. A directory that does not exist or holds no entries is an error, and so is an
id repeated inside it; an empty value counts as unset. GOVBR_CATALOG_DIR replaces the
base catalog entirely and should be treated as trusted input.
python3 -m venv .venv
.venv/bin/pip install -e '.[dev]'
.venv/bin/ruff check .
.venv/bin/ruff format --check .
.venv/bin/pytestCI runs ruff on Python 3.12 and the test suite on 3.11–3.14, then builds the wheel and loads the catalog from a clean install.
Responses are never written to disk. Only OpenAPI specs are cached, in
$XDG_CACHE_HOME/govbr-apis-mcp/ (or ~/.cache/govbr-apis-mcp/) for 24 hours, under a
file name derived from sha256(api_id + "\n" + openapi_url): never the id itself, and a
changed openapi_url never serves the old spec. OAuth2 tokens live in memory only.
call_api does not follow redirects — credentialed requests cannot be steered to
another host by a 3xx; the response carries the (redacted) location instead. It always
sends Accept-Encoding: identity, so a server has no reason to compress. The
60,000-character cut counts decoded text, though: a server that compresses anyway can
still inflate a small chunk before the cut (an accepted risk; see the roadmap).
Cookies an API sets are never stored or sent back, so one API cannot plant a cookie that another would receive.
Spec fetches follow redirects only by hand: at most 5 hops, and every URL (the first
and each Location) must be https on an allowlisted host before it is requested.
The body is capped at 5 MiB, JSON and YAML are accepted (YAML with aliases, including
merge keys that rely on them, is refused), and the document must carry openapi or
swagger. A compressed response is refused and the whole download has a 60-second
deadline; both come back as spec_error.
The httpx and httpcore loggers stay at WARNING, so httpx logs no request URL (query
string included).
Entries flagged pii: true return personal data (CPF, name, photo) into the client
transcript. Today: meiaentrada-cie-validador, fesn-cie-validador (callable without
any credential: whoever holds a use code gets the holder's data) and the three Serpro
entries.
Conecta adhesion as a public-sector entity → fill gateway base URLs + credentials
Per-API OpenAPI URLs for Conecta entries (linked from each detail page)
Serpro trial-mode toggle (call -trial base URLs with the published demo token)
Per-call cost guard for paid Serpro APIs
Bounded decompression for compressed upstream responses
Pleito à SNJ para a API conecta-id-jovem (admite instituição privada)
Fallback documental para CIE fora da base DNE (DCEs e entidades estaduais)
MIT - see LICENSE.
Call an endpoint of a catalog API; base URL and credentials are resolved for you.
path is relative to the API's base_url (e.g. '/estados/mg') and may carry a query
string; query overrides its keys, and a list value repeats a key. method is GET,
HEAD, POST, PUT, PATCH, DELETE or OPTIONS; send body (JSON) only with POST/PUT/PATCH.
Credential, Host, proxy and framing headers in headers are dropped and listed in
ignored_headers.
Returns {status, url, body} (JSON parsed, text cut at 60k chars); a 3xx is not followed
and carries its absolute location. Problems come back as {error}. Entries flagged
pii: true return personal data (CPF/CNPJ): call them only when the user asked.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| path | Yes | ||
| query | No | ||
| api_id | Yes | ||
| method | No | GET | |
| headers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discharges it: dropped credential/Host/proxy/framing headers surfaced via ignored_headers, no redirect following with absolute location returned, body truncated at 60k chars, errors shaped as {error}, and a PII safety warning. This is unusually rich 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?
Dense but essentially waste-free; the purpose is front-loaded and each subsequent sentence covers a distinct behavior (query semantics, methods, headers, return shape, errors, PII). The one-line-per-topic layout is readable, though the parenthetical detail is heavy.
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 six-parameter, zero-schema-documentation, no-annotation passthrough tool, this covers everything an agent needs: input semantics for path/query/method/body/headers, safety caveats, redirect and truncation behavior, and error shape. Even with an output schema present, the return description adds useful parsing/truncation detail.
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 and does: it defines what path is relative to, how query interacts with the path query string and how list values repeat keys, enumerates the allowed method values, restricts body to POST/PUT/PATCH, and explains header filtering. Only api_id is left to inference from its name.
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 first sentence gives a specific verb+resource ('Call an endpoint of a catalog API') plus a key behavioral promise (base URL and credentials resolved for you). This clearly distinguishes it from siblings like list_apis, describe_api and credentials_status, which enumerate or introspect rather than execute requests.
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 conditional usage rules: body only with POST/PUT/PATCH, query overriding path query-string keys, and an explicit when-not for PII-flagged entries ('call them only when the user asked'). It doesn't explicitly name a sibling alternative for any scenario, so it stops short of the 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
ready says whether the credential env vars are set; callable whether call_api
accepts the entry right now (a requires_contract entry, such as Serpro's, only does
once they are).
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it defines the two returned flags (`ready` = env vars set, `callable` = call_api currently accepts the entry) and discloses the non-obvious rule that requires_contract entries such as Serpro's are only callable once a contract exists. It never explicitly states the operation is read-only/non-mutating, which is the one gap.
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?
Three short sentences, zero filler. The scope-defining behavior ('Without api_id...') is front-loaded before the flag semantics, and the parenthetical Serpro example earns its place by making `callable` concrete.
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?
An output schema exists so return structure need not be explained, yet the description helpfully goes further by decoding the two key output fields and their edge case. For a single-optional-parameter read tool this is essentially complete; only the absence of any statement about the tool's own auth/read-only nature keeps it from a 5.
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 api_id has no description in the schema, so the description must compensate. It does: 'Without api_id, reports every catalog entry that requires auth' implicitly and correctly defines the omitted case as a full catalog scan, leaving the agent to infer the single-entry case. That inference is safe but not spelled out.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Show which APIs have credentials configured') and immediately scopes it further by explaining the no-argument behavior. It also distinguishes itself from call_api by defining `ready` vs `callable` in terms of what call_api will accept, so the agent can tell it apart from its siblings without reading any schema.
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?
Gives clear context for the primary use case: with no api_id it enumerates every auth-requiring catalog entry 'so you can see what is ready to call'. This tells the agent when the tool is the right choice (pre-flight readiness check), but it names no explicit alternative to use instead and states no exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe an API from the catalog.
Without path: catalog metadata plus, when an OpenAPI spec is published, the
full operation list (method + path + summary). With path (templated exactly
as the spec lists it): parameter/request/response schemas for that operation.
Paths from the spec are relative to the API's base_url — pass them to call_api unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | ||
| api_id | Yes | ||
| method | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses a two-mode read behavior and what each mode returns, but says nothing about failure modes (unknown api_id, path not in the spec) or any auth/permission requirements. A 'describe' verb implies read-only, so this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-line purpose followed by the two operating modes and a path-handling note; every sentence carries information and there is no boilerplate 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?
An output schema exists, so return structure need not be explained, and the description correctly focuses on the path/base_url contract an agent needs to chain into call_api. The remaining gap is `method` semantics and error behavior for unresolvable api_id/path, which a no-annotation tool would ideally cover.
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 and it does so well for `path` (must be templated exactly as the spec lists it, relative to base_url, passable to call_api unchanged). However, `method` is never mentioned, leaving its disambiguation role for same-path operations unexplained, and `api_id` sourcing is only implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Describe an API from the catalog') and immediately disambiguates itself from siblings by contrasting catalog-level output with per-operation schema output, and by noting paths feed into call_api unchanged. An agent can distinguish it from list_apis, search_catalog, and call_api without opening any schema.
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 conditional usage: omit `path` for catalog metadata and the operation list, supply `path` to get parameter/request/response schemas for one operation. It also routes the agent onward to call_api. It does not state when to prefer search_catalog/list_apis to find the api_id in the first place, so a true 'vs alternatives' statement is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No | ||
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose a genuinely useful behavioral trait: ~95 Conecta stubs in the catalog that are not callable yet, making unfiltered results mostly noise. It does not cover read-only/safety semantics or the meaning of the limit default, so gaps remain.
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?
Front-loads the core action, then supplies the two closed value sets compactly, then the caveat about stubs. Every sentence earns its place; the pipe-delimited value lists are dense but appropriately terse.
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 3-parameter, zero-required listing tool with an output schema already describing returns, the description supplies the missing enum values and the key filtering caveat. The only unaddressed item is the limit parameter, which is minor.
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 schema carries no enums or descriptions, so the description's enumeration of valid category and status values is essential and adds real meaning beyond the schema. The limit parameter is left completely unexplained, which prevents a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List catalog entries') so the agent knows exactly what comes back. It does not however name or contrast itself with the sibling search_catalog, leaving the listing-vs-searching distinction to inference.
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?
Gives strong contextual guidance: 'most useful with a filter' and explicitly 'filter by category or status', plus the rationale that an unfiltered listing is noise. No alternatives (e.g. search_catalog) or when-not-to-use cases are named, so it stops short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| category | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that matching is accent-insensitive and that some categories return results that are not yet callable, but it says nothing about authentication, result limits, pagination, or ordering 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?
Two short blocks, front-loaded with the search verb and match scope, followed by the filter semantics. Every clause earns its place; there is no filler or repetition of schema structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. The description covers the query semantics and the full category vocabulary, which are the two things an agent needs; only pagination/limit behavior and auth expectations are left unstated.
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 there are no enums, so the description must compensate — and it largely does: it defines what 'query' matches against and how it is normalized, and enumerates all four valid category literals with their meaning. It does not restate that category is optional/defaults to null, but the schema covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the government API catalog by keyword') and defines the match surface (name, provider, tags, description), which clearly separates it from the sibling list_apis (unfiltered listing) and describe_api (single-item detail). An agent can pick this tool without opening any schema.
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 category values carry implicit selection guidance ('public' = callable today, 'serpro' = needs contract, 'conecta' = not callable yet), which helps an agent choose a filter. However, there is no explicit statement of when to use this tool versus list_apis, and no exclusions or prerequisites are given.
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.
v0.2.0call_apicredentials_statusdescribe_apilist_apissearch_catalogScored 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.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Any REST/SOAP/GraphQL/OData/SQL API as MCP tools for Claude & ChatGPT. 517 connectors: SAP, ERP.
Discover, compare, route, and execute machine-accessible capabilities for AI agents.
