- Category
- Developer Tools
- Rank
- No. 1942Tools index
Previous survey · No. 1845 ·
- Pricing
- Open Source
- Type
- AGENT
- Use case
- Productivity & Collaboration
- Interfaces
- Web · API · MCP
- GitHub
- 2 stars
- Latest release
- v0.2.0
- Date
About
Numen is a self-hosted engineering intelligence tool that connects Linear, GitHub, Slack, Jira, Notion and Google Docs into a unified context graph, then proactively scores and surfaces what deserves each person's attention via Slack, email, or chat. It resolves entities across tools, computes urgency scores from deadlines, blockers, and goal linkage, and exposes the joined graph to agents through a built-in MCP server.
What it does
Numen runs on your own servers and reads a team's ticket tracker, code host, chat and documents on a schedule, stitching them into one map of who owns what, what waits on what, and which goal each piece of work serves. Each morning it ranks items per person and sends a short list with the reasons attached. The same map answers questions in chat, over a plain web API, through any client that speaks the OpenAI chat format, and to coding assistants through the Model Context Protocol (MCP), the standard way agents call outside tools.
Why it's ranked here
The case rests on the join. Per-tool integrations give an agent separate silos; this one hands over a single map where the same person across three apps is already one person and the ranking is already computed. It ships under the AGPL, talks to any OpenAI-compatible model including a local one, and refuses to start in production with shipped default passwords. Against that, the project declares itself beta, its own architecture notes still describe an earlier three-connector scope, and the upgrade notes warn that database migrations cannot be reversed. A serious self-hosted option for teams willing to read the code, not a drop-in product.
What's good
The hardening is specific. The evaluation setup binds Postgres, Redis and the graph database to loopback only, with comments saying why. Production startup fails if a secret is still the placeholder, if the developer header login is on, if webhook signature checks are off, or if either database password is the compose default. A seeded demo organisation needs no model key and no OAuth app, so the graph can be explored from a coding assistant before anything real is connected. Outside production, missing secrets are generated and cached so the documented quick start actually boots.
Tradeoffs
Setup is heavy. Every connector needs its own OAuth app in that vendor's console, and web sign-in needs Google OAuth. Without a public URL for webhooks, syncing falls back to polling every 300 seconds. The default sign-up mode admits anyone at a domain that already has an org, which the README itself calls usually wrong for a company. Six services idle at roughly 340 MB of RAM, the graph database holds everything in memory, and backups must capture two volumes together. The MCP library is pinned below version 2 until the server is migrated. The AGPL obliges anyone serving a modified version over a network to publish its source.
How to use it well
Start with the demo org and point Claude Code or Cursor at it to see whether graph-level answers beat your existing per-tool integrations. Then connect one source, GitHub or Linear, before adding others. Switch sign-up to domain mode with an allowlist before exposing the instance, and set the app URL to the exact hostname people use or agent connections fail with a 421 error. It fits an engineering team that wants cross-tool triage kept in-house. Observability and product analytics sources appear only on the roadmap, so it does not cover incident or adoption signals yet.
Technical notes+
src/main.py is a FastAPI app that starts sync, briefing and demo schedulers in its lifespan and mounts the MCP server at /mcp/ over streamable HTTP, logging a warning instead of failing if the import breaks. src/mcp/server.py builds a FastMCP instance with DNS-rebinding protection keyed to app_url; over HTTP the org comes from the bearer key and write tools need a user-bound key, while src/mcp/cli.py runs stdio with auth off and attributes writes to a synthetic actor. src/config.py holds the production startup checks. pyproject.toml declares AGPL-3.0-only, Python 3.12 and mcp below 2. .agent/architecture.md still lists only Linear, GitHub and Slack connectors.
Observed
- License
- AGPL-3.0-only (LICENSE, pyproject.toml)
- Language
- Python 3.12 backend (FastAPI); React and TypeScript frontend
- Packaging
- Docker Compose, separate evaluation and production files; numen-mcp console script for stdio
- Interfaces
- REST API, OpenAI-compatible chat completions endpoint, MCP over HTTP and stdio, Slack, email briefings, web app
- Datastores
- PostgreSQL with pgvector, Redis, FalkorDB
- Model backend
- Any OpenAI-compatible endpoint, including local Ollama or vLLM (.env.example)
- Declared maturity
- Development Status 4, Beta (pyproject.toml)
- Default sign-up mode
- open: any email at a domain that already has an org (src/config.py)
Read from README.md, pyproject.toml, LICENSE, VISION.md, .agent/architecture.md, src/main.py, src/config.py, src/mcp/server.py, src/mcp/cli.py, docs/agent-setup.md, docker-compose.yml, docs/recipes.md, .env.example.
What it can do
Connect and unify data from Linear, GitHub, Slack, Jira, Notion and Google Docs into a context graph
OAuth connections to work tools → Unified context graph
Resolve entities across connected tools
Data from connected tools → Resolved entity mappings
Compute urgency scores based on deadlines, blockers, and goal linkage
Task/issue data with deadlines and blockers → Urgency scores
Surface prioritized items to users via Slack, email, or chat
Urgency scores and context graph → Proactive notifications/briefings
Expose the unified context graph to agents via a built-in MCP server
Context graph → MCP server access
Provide urgency-ranked briefings through Slack, web chat, or API
User request → Ranked briefing of relevant items
Tags
Tech Stack
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.