Thanks for your interest in contributing! This guide covers what kinds of contributions we're looking for, how to propose them, and where the project's boundaries are.
Questions that don't need a code change are best asked in the #ai channel on NetDev Community Slack - this project doesn't have dedicated community channels yet.
The NetBox MCP Server is a simple, read-only MCP server for core NetBox objects. It uses the NetBox REST API with static token authentication. The priorities are:
- Easy to get started. Minimal configuration, minimal dependencies, runs locally in under a minute.
- Hard to misuse. Read-only by design, no plugin surface, small attack surface.
- Easy to fork. Apache 2.0 licensed, small codebase, designed to be adapted.
This project is maintained by a small team - scope is deliberately limited so it stays that way. We may decline feature proposals that fall outside the areas listed below, even if they're well-executed.
If your use case needs features outside this scope, forking is actively encouraged. The project is small and focused by design - your fork can diverge without losing the core. We welcome issues or discussions that share interesting forks back with the community.
Bug reports should describe unintended or unexpected behaviour - not requests for new functionality (see "Feature requests" below for that).
- Check you're running the latest release - your bug may already be fixed.
- Search existing issues to see if it's been reported. If so, add a 👍 reaction and any extra context as a comment.
- If it's new, open an issue with clear reproduction steps, error messages, and NetBox/Python versions.
Tips:
- Screenshots and exact error messages are especially helpful.
- Don't prepend your issue title with a label like
[Bug]- labels are applied by maintainers.
Before opening a feature request:
- Check the scope section above. If your idea falls outside the project's scope, please consider a fork rather than an FR.
- Search existing issues to avoid duplicates.
- Open an issue for discussion first. Don't start implementation until a maintainer has confirmed scope fit.
In-scope contributions we're especially keen to see:
- Bug fixes in existing tools
- Improvements to error messages and logging
- Documentation, examples, and quickstart improvements
- Adding new core NetBox object types to
src/netbox_mcp_server/netbox_types.py - Compatibility fixes for new NetBox versions
- Dependency updates
For non-trivial changes, please open an issue first. This saves you time - if the change isn't a good fit, we can tell you before you write the code. Drive-by bug fixes and small docs improvements don't need an issue first - just send a PR.
Our process for larger changes:
- Open an issue describing the bug or feature.
- Wait for maintainer response confirming scope and approach.
- Submit a PR referencing the issue.
- Respond to review feedback.
- Maintainer merges.
PR checklist:
- Base off
main. - Conventional commit format (
feat:,fix:,chore:, etc. - seeCLAUDE.mdfor details). ruff checkpasses.- Type hints on all public functions.
Detailed code standards live in CLAUDE.md - please skim it before your first PR.
AI-assisted contributions are welcome. We use AI tools ourselves. That said, you're responsible for what you submit - review it, test it, and take ownership. PRs that appear to be unreviewed AI output will be asked for revision or closed.
Not every useful contribution is code:
- Answering questions in discussions or issues
- Writing a blog post or video about your use case
- Sharing useful forks back via issues or discussions
- Improving documentation