MCP server exposing a deliberately flawed card issuance API as tools for testing and exploration
Server provides 7 tools with complete input schemas and descriptions in Portuguese. Naming follows verb_noun pattern (issue_card, authorize, get_card, etc.). Descriptions are detailed (100-250 chars) and explain purpose, prerequisites, and return values. However, schemas lack parameter descriptions, only type and required fields are present. No output schemas documented. Error handling is implicit (HTTP status codes) but lacks recovery guidance. Tool composition is sound: each tool has one responsibility, and outputs contain IDs for chaining (cardId for authorize, etc.). Risk annotations (WRITE, DESTRUCTIVE, READ_ONLY) are present but not formalized in schema. STDIO transport caps protocol readiness.
Tenta autorizar uma transação contra o limite disponível de um cartão. Devolve 201 aprovada, 402 recusada por limite insuficiente, 422 entrada inválida, ou 404 cartão inexistente. É o caminho quente do sistema e o lugar onde os defeitos interessantes moram.
Dispara N autorizações SIMULTÂNEAS contra o mesmo cartão e devolve quantas foram aprovadas. Existe porque defeito de concorrência não é alcançável por chamadas sequenciais: o entrelaçamento não é um valor que se passe como parâmetro. Compare o número de aprovações com floor(limite / valor) para saber se a invariante de limite foi violada.
Lê o estado de um cartão: limite, gasto e disponível. Use para conferir invariantes depois de agir — o que a resposta de uma autorização diz e o que sobrou no cartão são duas afirmações diferentes.
Estado do serviço: se os defeitos semeados estão ativos, quantos cartões e quantos lançamentos existem. Bom primeiro passo para saber contra o que se está trabalhando.
Emite um cartão novo com um limite de crédito. Devolve o id do cartão, necessário para todas as autorizações. Use antes de qualquer teste que precise de um cartão em estado conhecido.
Parameter descriptions missing from all input schemas. Schema objects contain only type and required fields; no description field for holder, limitCents, cardId, amountCents, merchant, count, etc. LLMs cannot infer parameter semantics from names alone.
No output schemas documented. Tools return HTTP status codes and JSON bodies, but response structure is not formally specified. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Error handling lacks recovery guidance. Tools return HTTP status codes (402, 404, 422, 409) but descriptions do not explain what the LLM should do next. E.g., authorize returns 404 for missing card but does not suggest calling issue_card first.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Apaga todos os cartões e lançamentos, devolvendo o serviço a um estado conhecido. Chame antes de medir qualquer coisa: um serviço no modo certo mas com histórico herdado de outra execução produz medição sem linha de base, e um caminho já lento pode mascarar defeito de concorrência ao serializar as requisições.
Insere N transações históricas no ledger. Serve para observar o sistema num estado que produção apresenta e ambiente de teste não: com histórico. Alguns defeitos de desempenho só existem depois que a tabela cresce.
Risk annotations (WRITE, DESTRUCTIVE, READ_ONLY) are present in metadata but not formalized in tool schema. Modern MCP spec uses toolAnnotations (readOnlyHint, destructiveHint, idempotentHint) for structured risk declaration.
STDIO transport only. Server is not remotely accessible and cannot be used by hosted MCP clients. Limits deployment and integration scenarios.