lifeos-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIFEOS_PATH | No | Absolute path to the LifeOS root directory | ~/lifeos |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lifeos__healthA | Check the health of the LifeOS MCP server and LifeOS data availability. |
| lifeos__get_identityA | Read the user's identity profile from LifeOS (identity.md). Returns frontmatter metadata and full content. |
| lifeos__get_preferencesA | Read the user's preferences from LifeOS (preferences.md). |
| lifeos__list_skillsA | List all available skills in LifeOS (~/lifeos/skills/ directories). |
| lifeos__read_skillA | Read the documentation for a specific skill from LifeOS. Use lifeos__list_skills first to see available names. |
| lifeos__list_rulesA | List system rules and guidelines from LifeOS (~/lifeos/system/ markdown files). |
| lifeos__read_ruleA | Read a specific rule/guideline from LifeOS system/ directory. Use lifeos__list_rules to see available names. |
| lifeos__list_projectsA | List all project definition files from LifeOS (~/lifeos/projects/*.md). |
| lifeos__read_projectA | Read a specific project definition from LifeOS. Use lifeos__list_projects to see available names. |
| lifeos__list_wiki_pagesA | List all wiki pages from LifeOS (~/lifeos/wiki/pages/ recursively). |
| lifeos__read_wiki_pageA | Read a specific wiki page from LifeOS. Use lifeos__list_wiki_pages to see available names. |
| lifeos__searchB | Full-text search across all LifeOS files (identity, projects, skills, wiki, rules, etc.). |
| lifeos__read_fileA | Read any file under ~/lifeos/ by relative path. Path is validated to stay within LifeOS root. |
| lifeos__propose_edgeA | Propose a typed semantic edge between two vault nodes. Routes through CitationVerifier and NoveltyScorer. Edge lands in the LifeOS Curator inbox with reviewState=proposed for user review. |
| lifeos__accept_edgeA | Accept a proposed edge in the LifeOS Curator inbox. Optionally edit rationale, type, or citations before accepting. Fires a curator: git commit in ~/lifeos/. |
| lifeos__reject_edgeA | Reject a proposed edge in the LifeOS Curator inbox. Reason is required — it feeds the rejection corpus used to improve future proposals. |
| lifeos__read_pending_queueA | List proposed edges waiting in the LifeOS Curator inbox. Read-only — no write opt-in required. Use since and limit to paginate. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| identity | LifeOS identity profile |
| preferences | LifeOS user preferences |
TDQS
Scored across 17 tools
Each tool targets a distinct entity or action: identity, preferences, projects, rules, skills, wiki, edges, health, file reading, and search. No two tools have overlapping purposes, making it easy for an agent to select the correct one.
Tools follow a consistent 'lifeos__verb_noun' pattern with underscores. Most use 'list_' for listing and 'read_' for reading, but 'get_identity' and 'get_preferences' use 'get_', and 'health' and 'search' are single-word actions. Minor inconsistency but overall predictable.
17 tools is well-scoped for a personal knowledge management system. It covers core reading, edge curation, search, and health check without being overwhelming. Each tool serves a clear purpose.
The tool set provides comprehensive read access and edge management, but lacks CRUD operations for identity, preferences, projects, rules, skills, and wiki pages. Only edges have full lifecycle. This creates gaps for an agent wanting to modify core content.