Inspiration
AI agents can call tools on a user’s behalf, but a model’s decision should not automatically become an action. I wanted to build the control layer that sits in between.
What it does
Nexus-MCP is an MCP server that sits between an MCP client (Alexa+) and the tools it exposes. Each call is authenticated, checked against a policy, and either executed (ALLOW) or blocked (DENY). Every attempt is written to an audit log.
get_customer (READ, LOW): allowed create_order (WRITE, MEDIUM): allowed cancel_order (DESTRUCTIVE, HIGH): denied and never executed
How we built it
Python with the official MCP Python SDK over Streamable HTTP. OAuth bearer tokens are validated (JWKS, pinned algorithms, required iss and exp), and startup fails closed if the configuration is wrong. Authorization is deny-by-default and runs before any tool. The audit log is append-only JSONL with sanitized arguments. The project is a modular monolith tested with pytest, including unit and integration tests. Remote access during development uses a temporary tunnel.
Challenges we ran into
Most of my problems were with Git: virtual environment and bytecode files had been committed, which caused merge conflicts between develop and main. I cleaned the history, resolved the conflicts, and documented the process. On the technical side.
Accomplishments that we're proud of
A working gateway where denied actions are provably not executed, a complete audit trail for each decision, and a published pre-release (v0.1.0-rc1) with tests.
What we learned
The difference between authentication and authorization, why denial should be a normal outcome rather than an error, how the MCP lifecycle works, and why repository hygiene matters as much as the code.
What's next for Nexus-MCP
Persistent audit storage, a richer policy format, and evaluating whether the project should continue as a learning project or become a product.
Log in or sign up for Devpost to join the conversation.