2026 — present
MCP Server for Reportia
Sole author — CtisEvolution
Impact
Any automation over Reportia stays bounded to a surface of 66 known, auditable operations, instead of a generic tool an agent could misuse — with no extra effort from whoever uses it.
The problem
Reportia, my own product under CtisEvolution, exposes an HTTP API for
companies, accounting transactions, commissions, account mappings, and SIIGO
sync. Giving that API to an AI agent the most direct way — a generic tool
like http_request(url) — means the model can point the client at any URL,
including an internal IP. It's the classic entry point for an
agent-induced SSRF.
The approach
The MCP server exposes 66 curated tools, one per real business endpoint,
instead of an open surface. Authentication supports three modes — a
pre-issued cookie, a bearer token, and email/password login — with precedence
cookie > bearer > session, because the cookie already matches the identity
resolved upstream. If REPORTIA_TOKEN and REPORTIA_COOKIE are set
together, the server deliberately throws a configuration error, so a token
set by accident doesn't override an already-valid per-user session. There's a
dedicated test file that verifies the order in which security guards are
applied — for example, that the company is resolved first and only then is
confirmation of a destructive operation validated — not just that they
exist, so a configuration error returns a useful message instead of a
generic rejection.
Result
Published on npm and in the official MCP Registry. Any automation over Reportia stays bounded to a surface of 66 known, auditable operations, instead of a generic tool an agent could misuse — with no extra effort from whoever uses it.