ontology-atlas
Related Servers
Alternatives to ontology-atlas
No user-submitted related servers found.
Related Servers
- FlicenseBqualityCmaintenanceTurns local code repositories into a queryable dependency graph built from AST parsing and git co-edit history, then exposes it alongside an Obsidian vault as persistent memory. Enables context retrieval, impact analysis of proposed changes, and curation of durable prose knowledge through full-text search and Personalized PageRank classification—all fully offline without API keys or embeddings.30-
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to read and write a local-first knowledge base of plain markdown files in git, with governance gates for safe, hash-anchored edits.1Apache 2.0
- AlicenseAqualityAmaintenanceSelf-hostable, markdown-native team wiki with a built-in MCP server: agents search, read, and write your wiki pages (ranked Postgres full-text + semantic search, backlink traversal). Plus Atlas, which auto-generates a cited, coverage-checked wiki from your git repos and Jira.4162AGPL 3.0
- AlicenseNot gradedqualityAmaintenanceTransforms a folder of Markdown files into a structured, version-controlled knowledge base with semantic search and safe AI editing via draft branches.MIT
- AlicenseNot gradedqualityCmaintenanceBuilds a local-first digital twin of your microservice ecosystem, enabling natural-language questions about project code, architecture, incidents, and more via hybrid search and a knowledge graph.Apache 2.0
- AlicenseAqualityAmaintenanceLocal-first dev memory: indexes Git commits, PRs, Jira/Linear tickets, Confluence docs, Slack threads, and Calendar events into a local SQLite/FTS5/ONNX index, and exposes them as MCP tools so Claude Code, Cursor, and Codex can search and cite your past work.174MIT
TDQS
Scored across 38 tools
The CRUD and relation tools are clearly distinct (add/get/patch/delete/rename/merge), but the query surface has meaningful overlap: find_path, find_neighbors, find_backlinks, find_orphans, find_evidence, query_concepts, and query_ontology (which bundles 30+ graph operations) all serve discovery and could cause misselection. The code-analysis quartet (analyze_repo_structure, infer_imports, inspect_architecture, index_project) also has blurry boundaries, though each has a stated distinct role.
Naming is highly consistent: verb_noun snake_case throughout (add_concept, get_concept, list_concepts, patch_concept, merge_concepts). Batch variants consistently pluralize the noun (add_concepts, get_concepts, add_relations), and prefix pairs like connect_project_source/disconnect_project_source and find_path/find_backlinks/find_neighbors follow a clear predictable pattern.
At 38 tools this is well above the comfortable 3-15 range and over the 25+ heavy threshold, but the server's scope is genuinely broad: ontology CRUD, batch operations, relation management, git integration, code analysis, validation, and graph queries. Notably, query_ontology bundles ~30 operations into one tool, so the effective surface is even larger; the breadth earns some leeway but it remains a heavy, sprawling surface.
The tool surface covers the full ontology lifecycle: create (single/batch), read, update (patch/rename/reclassify), delete, merge; full relation management (add/remove/replace, batch); validation (validate_vault, validate_wiki); git checkpointing; a code-analysis pipeline; and rich graph-query operations. Minor gaps exist (no batch delete, no direct node export beyond compile_ontology), but there are no dead ends in the core workflows.