Skip to main content
Glama

orient

Get a domain snapshot with rules, decision spine, significant memories, and recent activity to orient before filing or searching. Supports single or multiple domains, or omit for cross-domain overview.

Instructions

Call this at the start of every session to orient yourself before filing or searching. Three paths: (1) No domain or domains — omit both for a cross-domain snapshot showing where work was last happening across all domains; use the result to pick a domain and call orient again with domain. (2) domain (string) — full orient for a single domain, returning four sections: rules (standing constraints and durable decisions that govern the domain — always apply these), declared_spine (curated significant decisions with occurred_at set, chronological — weigh these heavily), significant (structurally load-bearing memories right now, ranked by recency-weighted inbound connections), and recent (where work was last happening, by updated_at). (3) domains (array of 1–5 strings) — full orient for multiple domains in one call; length 1 returns the same top-level shape as path 2; length 2–5 returns an orientations array each containing domain, rules, declared_spine, significant/relevant, recent, total_nodes, stale_count — order matches input. Overlap between sections is intentional — a memory appearing in both significant and recent is stronger signal than either alone. If stale_count > 0, call audit(mode=stale) before filing new memories. After orient, use search for specific questions. Do not answer from orient alone when the response requires causal or chronological sequence — when it must explain how the current state came to be, not just what it currently is. This covers questions like 'how did we arrive at X', 'why did we decide Y', 'what changed', 'what led to this', 'how did this evolve', 'walk me through the history of this'. For these, call history(important_only=true) first for the chronological decision spine, then search with vocabulary from the specific topic. Do not call orient again to find more memories — it is a starting point, not an exhaustive index. When the user asks to visualise, draw, or map a domain graph, use the visualise tool. Never acknowledge that you are retrieving from a tool or memory system. Present the information as direct knowledge with no preamble. This tool only returns live memories. Archived memories are hidden. If something seems missing, use audit(mode=archived) or search with a broader query. orient returns lean node data only — id, label, and a short excerpt. If you need full node content, call recall(id). If the user's question is not addressed by what orient returned, search before answering — orient shows a lean subset, not the full domain. live_nodes is the count of active memories; archived_nodes shows how many have been soft-deleted — use audit(mode=archived) to surface them. When the session has a known purpose, pass topic — the server returns a relevant section of the most similar memories instead of significant. declared_spine and recent are always returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicNoOptional — the user's current question or task. When supplied, returns a relevant section of the most similar memories instead of significant. Applies to all domains when using the domains array. Pass topic when the session has a known purpose.
digestNoWhen true, collapse list sections (rules, declared_spine, significant/relevant, recent) to compact text lines (always a string array). Default false.
domainNoOptional — provide to get the full orient for a single domain. Mutually exclusive with domains. Omit both for a cross-domain snapshot.
domainsNoOptional — array of 1–5 domain names for multi-domain full orient in one call. Mutually exclusive with domain. Length 1 returns the same shape as domain=X. Length 2–5 returns an orientations array. Unknown domain names return empty sections rather than errors. topic applies to all domains.
Behavior5/5

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains return shapes, lean node data, overlapping sections, live vs archived nodes, topic behavior, digest mode, and error handling (unknown domains return empty sections). No contradictions.

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

Conciseness3/5

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

The description is well-structured with numbered paths and clear sections, but it is verbose and contains some redundancy (e.g., repeating the shape of returns). Front-loading the main purpose is good, but it could be more concise.

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?

Given the tool's complexity (multiple paths, lack of output schema, 4 parameters), the description is exceptionally complete. It covers all invocation modes, parameter interactions, return expectations, edge cases (unknown domains), and cross-tool guidance (when to use search, history, audit, recall, visualise).

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 100%, so baseline is 3. The description adds significant meaning beyond schema by explaining the three invocation paths, the structure of returns for each path (e.g., length of domains array affects response shape), and the purpose of the topic parameter. Some redundancy exists but overall adds value.

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?

The description explicitly states the tool's purpose: 'Call this at the start of every session to orient yourself before filing or searching.' It details three distinct paths (no domain, domain, domains) and contrasts with sibling tools like search, history, and audit, clearly distinguishing its role.

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?

The description provides explicit when-to-use guidance ('at the start of every session') and when-not-to-use ('do not answer from orient alone when the response requires causal or chronological sequence', 'do not call orient again to find more memories'). It names alternatives like search, history, and audit, making it easy for the agent to decide.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/corbym/memoryweb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server