get_context is the MCP tool on the 📝MythOS MCP server that loads a user's augmentation memos — Soul, Style, Human, and Memory — into an agent session as the L0 Identity + L1 Personal context tier. The server exposes it as read-only and requires it to be called before any create_memo or update_memo operation.

Key Facts

Tier: L0 (Soul + Style) and L1 (Human + Memory), loaded together in one call
Inputs: none — the username is injected by the MCP server config
Output format: a single markdown document with ## Mythos Soul, ## Mythos Style, ## Mythos Human, ## Mythos Memory sections, followed by a token-budget footer
Budget footer: reports core tokens used vs. budget, per-section breakdown, and — when present — a prompt to call load_context_tier(tier: "L2") for extended context
Gate: create_memo and update_memo tool descriptions explicitly require get_context to have been called first in the session
Source of the four memos: the user's augmentation settings (each memo is also exposed as an MCP resource at augmentation://soul|style|human|memory)

How It Works

Server startup fetches the user's augmentation data and passes augmentation, contextStats, and templateMetadata into createServer. When an agent calls get_context, the server concatenates whichever of Soul/Style/Human/Memory are populated, prepends a framing paragraph ("Apply the Mythos Style rules to all memo operations. Apply the Mythos Soul values to all interactions."), and appends the budget footer from contextStats. If additional memos tagged #mythos-mcp-context exist beyond the L0/L1 core, the footer advertises an L2 tier that load_context_tier will fetch on demand along with the template catalog.

Why It Matters

The tool is how the scope-locality architecture bootstraps every session: it guarantees the agent enters any task already holding the user's formatting rules, collaboration values, current life context, and durable memory — the four layers every downstream decision depends on. Without it, create_memo would write memos that violate the user's Style rules, and the agent would operate without the preferences recorded in Memory. The L0+L1 / L2 split keeps the default payload small while letting agents pull in project-specific augmentation only when the conversation narrows onto it. See 📝Scope-Aware Collaboration Architecture for the framework this tool serves.

FAQ

When must get_context be called?

Before any write operation (create_memo, update_memo) in a session. Read-only tools do not require it, but calling it first is still the convention so the agent applies Style rules when summarizing or quoting memo content.

What's the difference between get_context and load_context_tier?

get_context loads the mandatory L0+L1 core (Soul, Style, Human, Memory). load_context_tier(tier: "L2") is an opt-in follow-up that adds every memo tagged #mythos-mcp-context plus the template catalog — used when the footer reports extended context is available and the session's task warrants it.

Does get_context accept a username or library parameter?

No. The MCP server is configured per-user via headers (x-mythos-username), so get_context takes no arguments. Other tools accept a library parameter for cross-library reads, but augmentation is always the session user's.

What happens if the user has not configured augmentation?

The tool returns "No augmentation context configured. The user has not set up their augmentation memos yet." Write tools will still run, but without Style rules loaded the output will drift from conventions.

Subjective

This is the single most load-bearing tool in the MCP surface — every memo write in every session routes through the Style rules it delivers. The "must call before write" gate is the right shape: cheap to enforce, impossible to forget, and it makes the augmentation memos the actual governance layer rather than aspirational documentation.