Related Servers

Many tools have overlapping purposes. For example, get_docx_content, fetch_document_asset, document, document_asset, section, and docx all provide access to document content. The numerous consolidated entrypoints (job, document, evidence, knowledge, etc.) that dispatch via an 'op' parameter create ambiguity, as an agent can't easily tell which tool to use. Generic names like 'document' or 'job' further blur boundaries with more specific tools.

There is a mix of patterns. Some tools follow a consistent verb_noun style (ingest_documents, list_documents, get_job_status, save_docx, find_evidence_spans), and the table_* group (plan_table, table_manage, table_data) is consistent. However, several single-word names (job, document, evidence, section, docx, knowledge) are vague and break the pattern, making the set feel inconsistent.

With 30 tools, the count is above the 25 threshold that would be considered heavy. More importantly, many tools are consolidated facades (e.g., document, docx, table_* entrypoints) that duplicate existing functionality, inflating the count and adding cognitive load. The server would be better with fewer, more distinct tools.

The tool surface covers a wide range of operations: document ingestion (PDF/DOCX), asset extraction (tables, figures, sections), citation/evidence management, and comprehensive table workflows (plan, create, manage, cite, draft, history). However, gaps exist: there is no explicit document deletion or metadata update, and the consolidated entrypoints make it harder to discover the actual operations. Some dead ends remain, like the lack of a clear way to remove documents or manage document-level assets beyond retrieval.