Skip to main content
Glama

orient

Read-only

Get a bounded orientation snapshot. If stale_count > 0, call audit(mode=stale) before filing new memories. If conflicts_count > 0, call audit(mode=conflicts) to review semantically close memory pairs — candidate-surfacing only, not confirmed contradictions. conflicts_count is a density signal, not a monotonically-decreasing queue: connecting a flagged pair suppresses it, but a later substantive revision to either memory lifts the suppression, so the count can rise again without indicating new drift. pass topic when the session has a known purpose — orient will run a semantic search for the topic within the resolved domain and return a relevant section instead of significant. Omit domain (or pass no domain) to get a cross-domain bootstrap snapshot listing all active domains with their per-domain counts (total_nodes, owned_contradiction_count, owned_superseded_count, others_change_count, other_member_count, stale_count) — use this at session start when you do not yet know which domain to work in; call audit(mode=conflicts) for full contradiction pairs. The owned_* fields (owned_contradiction_count, owned_superseded_count, others_change_count, other_member_count) are computed only for authenticated callers with a personal identity (scope=mine or scope=user:); they are always 0 for plain workspace-key sessions (scope=all). stale_count is always populated regardless of scope. Pass a domain to get the full orient response for that domain: rules — up to 20 standing constraints and durable decisions (node_kind='standing') ordered by inbound connection count DESC; always present (empty array when none); rules_count gives the true total — when rules_count > len(rules), call search(node_kind='standing', domain=X) to retrieve the full set. declared_spine — memories with occurred_at set, sorted chronologically (up to 20); these are the curated significant decisions that shaped the domain. significant (when topic is absent) — up to 10 structurally load-bearing memories ranked by recency-weighted importance; these are the memories the domain currently depends on most. Singleton entries carry inline trust_score [0,1] and trust_basis; load_bearing_low_trust counts how many of these are epistemically weak (net-contested or unsupported by a high-tier memory such as a finding, decision, or standing rule) — a non-zero value means the domain's structural backbone has shaky foundations. Call significance(mode=trust, domain=X) to drill into the full trust ranking.relevant (when topic is supplied) — up to 10 memories semantically matched to the topic; replaces significant. recent — the most recently updated memories by the caller (owner-scoped by default; domain-wide when scope=all); shows where your active work is happening. digest (present when scope is personalised) — since-you-were-last-here summary: others_change_count, other_member_count, members list, owned_contradiction_count and owned_contradictions (conflict pairs where the caller owns at least one memory), owned_superseded_count and owned_superseded (archived memories you owned that another member superseded — read from supersedes relationships, not audit_log). summary_hint — a prompt you can pass to an LLM to synthesise the orient data into a narrative paragraph. Overlap between sections is intentional and meaningful: a memory appearing in both significant and declared_spine is both historically important and structurally central. Returns lean results only — id, label, and a truncated why_matters excerpt; call recall(id) for full content. When a list or section has 2 or more results, each is rendered as a single compact text line — "[id] label — excerpt (domain, node_kind)" — instead of a JSON object; exactly one result is returned as a full object.Multi-entry sections (rules, declared_spine, significant/relevant, recent) render as single-line digest strings at 2+ entries. The response always includes server_version — a stable string identifying the current tool surface. If server_version differs from a previously cached value, call tools/list again before issuing any tool calls — the tool surface has changed and your cached schema is stale. Do not call orient again to find more memories — the sections are bounded by design. If you need to find something specific, use search with a targeted query instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoControls whose memories appear in the `recent` section and which contradictions are flagged. 'mine' (default when authenticated) — recent and contradictions scoped to the caller; 'all' — domain-wide, no personalisation (previous default, still the default for plain workspace-key sessions); 'user:<ref>' — view as another member, where ref is a user_id UUID or email address.
topicNoOptional topic for the session. When supplied, replaces the significant section with a relevant section of semantically matched memories (up to 10).
domainNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces a read-only orientation snapshot. It goes well beyond annotations by explaining boundedness, format switching (single-line digest strings at 2+ entries versus full objects), the non-monotonic semantics of conflicts_count, reliance on scope for owned_* fields, and server_version staleness behavior. No contradiction with annotations exists.

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?

The description is front-loaded with the core purpose and immediately actionable guidance, then details each section in a logical order. It is long, but the tool is complex and most sentences earn their place. It loses a point for redundancy: 'Multi-entry sections ... render as single-line digest strings at 2+ entries' repeats the earlier format rule 'When a list or section has 2 or more results, each is rendered as a single compact text line'.

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?

Despite no output schema, the description covers the response shape, all counts and their auth sensitivity, section semantics, overlap meaning, lean result format, pagination-like rules when counts exceed returned lengths, and the server_version contract. It also tells the agent when not to use orient and which sibling to call instead, making it a self-contained guide for correct invocation.

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

Parameters5/5

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

Schema coverage is 67%, and the description fully compensates, especially for the undocumented 'domain' parameter: passing a domain yields a full orient response with rules, declared_spine, significant/relevant, and recent, while omitting it yields a cross-domain bootstrap snapshot. It also explains the conditional behavior of 'topic' (replaces significant with relevant) and the auth-dependent meaning of 'scope' (mine/user:<ref> personalization vs all workspace-key). This adds substantial meaning beyond the input schema.

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 opens with a specific verb and resource: 'Get a bounded orientation snapshot.' It explains exactly what orient returns (per-domain sections, cross-domain bootstrap, bounded lists) and explicitly contrasts it with siblings: 'call audit(mode=stale)', 'use search with a targeted query instead', 'call recall(id) for full content.' An agent can distinguish orient from audit, search, recall, recent, and significance without opening schemas.

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 gives explicit decision rules: when stale_count > 0 call audit(mode=stale); when conflicts_count > 0 call audit(mode=conflicts); omit domain for session-start bootstrap; pass topic when the session has a known purpose; call search when rules_count > len(rules); call significance(mode=trust) for trust drilling; re-run tools/list when server_version changes; and do not call orient again to find more memories. It names alternatives and the conditions that select them, leaving little to inference.

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