jdocmunch-mcp
Related Servers
Alternatives to jdocmunch-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityBmaintenanceIndexes codebases and lets AI agents retrieve precise code snippets (functions, classes, routes) instead of reading entire files, reducing token usage and improving accuracy.169 npm7MIT
- AlicenseNot gradedqualityNot gradedmaintenanceEnables AI coding agents to retrieve only the specific code sections that answer their questions, drastically reducing context usage while running fully locally.MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to intelligently navigate and understand codebases by providing instant file descriptions, semantic search, and context-aware recommendations, eliminating the need to repeatedly scan files.20MIT
- AlicenseAqualityAmaintenanceEnables AI agents to search local Markdown documents using natural language, with automatic indexing and section-level retrieval.105 npm1MIT
- AlicenseNot gradedqualityDmaintenanceProvides AI agents with document conversion to Markdown, intelligently routing small and large files, and enabling targeted extraction via sections, search, and token budgets.6MIT
- AlicenseNot gradedqualityCmaintenanceEnables agentic document retrieval over markdown, CSV, and JSONL using BM25 and tree navigation, without vector databases or embeddings, allowing AI agents to search, browse, and retrieve structured document sections.22 npm1MIT
TDQS
Scored across 64 tools
Many tools are carefully differentiated, but the set contains numerous overlapping section-navigation and health-inspection tools (get_section_context vs describe_section, get_doc_health vs doc_health_radar vs get_wiki_stats, get_related_sections vs section_neighbors). The detailed descriptions help, but the boundaries are subtle enough that an agent could easily misroute a query.
Names are all snake_case, but conventions are mixed: get_* verbs dominate, yet doc_list_repos, doc_index_repo, and doc_resolve_repo lead with a noun, while section_neighbors is noun-first. Similar operations are inconsistently prefixed (doc_health_radar vs get_doc_health, doc_list_repos vs list_docs), making predictable lookup hard.
64 tools is far beyond the 25+ threshold, and many are micro-wrappers or batch variants (get_section_excerpt vs get_section_excerpts, get_section_summary vs get_section_summaries) that could be consolidated. This overwhelms the tool-selection surface for what is essentially a docs-indexing/query domain.
The surface is impressively complete for a documentation indexer: indexing, search, TOC, section retrieval, health/drift, link analysis, wiki stats, OpenAPI, glossary, and code-symbol bridging are all covered. Minor gaps such as a single consolidated re-index/refresh tool or cross-repo search without groups are workable, but the domain is thoroughly addressed.