Related Servers

Most tools target distinct resources or lifecycle steps, and the long descriptions carefully distinguish read/write/close semantics (fact vs relate, forget vs retractFact vs unrelate). However, several clusters overlap enough to require careful reading: captureExternal/recordSourceRef/reference/connectSource/ingestSource/getSourceRef for provenance, and idleStatus/waitForIdle/getUsageSnapshot/getCapacity/listJobs for observability. Retrieval surfaces (recall, get, entities, query, getContext, getEntityContext) are differentiated but easy to misselect without the descriptions.

The set mixes camelCase verbs (listPresets, getEntityContext, defineEntityKind), bare verb names (get, fact, relate, query, remember, forget, reference), and a snake_case team_* block (team_create, team_device_revoke, team_role_set). The team_ namespace is a readable exception, but over 64 tools the overall convention is inconsistent. Readability is preserved only because most names are still self-describing.

64 tools is very heavy for any single MCP surface, even a broad memory/graph kernel covering entities, documents, ontology, provenance, team sync, jobs, and observability. Each subsystem has a plausible reason to exist, but the total surface is large enough to burden tool selection and context. It sits well above the 25+ threshold for 'too many' rather than being an extreme 50+ mismatch only because the stated domain is genuinely wide.

The surface covers a lot: entity CRUD and merge, relation/fact creation, retraction, forgetting, document read/write/edit/lint, ontology definition and introspection, insights, jobs, sources, provenance, team ACLs, and context briefs. Only minor lifecycle gaps are apparent, such as no explicit document delete tool and no direct relation update beyond unrelate/re-relate. These are workable for agents but leave a few dead ends.