Skip to main content
Glama

Awareness — Memory, Knowledge & Agent Markets

awareness_init

Start here — call ONCE at the beginning of every session to load your persistent memory.

WHY: Without this call, you have no memory of past sessions. You'll re-discover things
you already know, repeat past mistakes, and lose continuity. This is not optional.

RETURNS:
  - session_id: pass this to all awareness_record calls.
  - context.recent_days: daily summaries (what happened recently).
  - context.open_tasks: pending work items.
  - context.knowledge_cards: key decisions and facts you've learned.
  - active_skills: reusable skill prompts extracted from memory (if any).
    Each skill has: summary (injectable instruction) and methods (step-by-step procedure).
    When a task matches a skill's domain, apply its summary as guidance and follow its methods.
  - agent_profiles: configured agent roles (if any). Use awareness_get_agent_prompt()
    to fetch full activation prompt when spawning a sub-agent.
  - _setup_action: if present, you MUST follow the instruction to write rules to the
    specified file. This enables persistent memory for all future sessions.

AFTER THIS CALL: Review the returned context (including active_skills and agent_profiles),
then call awareness_recall to search for anything relevant to your current task before
starting work.

Args:
    memory_id: Target memory id (auto-resolved from header if omitted).
    source: Your tool name (e.g. "claude-code", "cursor").
    days: Days of history to load (1-90, default 7).
    max_cards: Max knowledge cards (default 20).
    max_tasks: Max open tasks (0 = all, default 0).
    user_id: User identifier for multi-user memories.
    agent_role: Agent role for role-filtered recall.
    client_capabilities: Comma-separated (e.g. "file_write,local_dir").
    rules_version: Version of rules file you already have (e.g. "1"). If current,
        _setup_action is skipped. Omit if you don't have rules yet.
    api_key: Bearer token for authentication.

Input Schema

NameRequiredDescriptionDefault
daysNo
queryNo
sourceNo
api_keyNo
user_idNo
max_cardsNo
max_tasksNo
memory_idNo
agent_roleNo
rules_versionNo
client_capabilitiesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the consequence of skipping it, the side-effecting _setup_action file write, and the conditional skipping of _setup_action when rules_version is current. The main gap is that it doesn't state auth requirements beyond the api_key param or describe failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-organized with WHY/RETURNS/AFTER/Args headers and the essential instruction front-loaded. It is long, but the length is justified by an 11-param tool with no schema descriptions; only the WHY section leans slightly rhetorical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter init tool with no output schema and no annotations, the description supplies the return-value structure (session_id, context fields, active_skills, agent_profiles, _setup_action) and the post-call workflow. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does — the Args section explains ranges, defaults, and conditional semantics (days 1-90 default 7, max_tasks 0 = all, rules_version skipping _setup_action, client_capabilities format). It omits at least one parameter ('query'), keeping it just short of full coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'load your persistent memory' — and frames itself as the session entry point ('Start here — call ONCE at the beginning of every session'). An agent can distinguish it from awareness_recall/awareness_record without opening any schema, since it explicitly names those siblings and their roles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('at the beginning of every session'), a frequency constraint ('call ONCE'), a strong normative signal ('This is not optional'), and a next-step handoff to awareness_recall. It also names awareness_get_agent_prompt as the follow-up for agent activation, so routing is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources