Skip to main content
Glama
nworks3d

thor-memory-bible

by nworks3d
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

lookup

Read-onlyIdempotent

Search THOR's memory across all projects, scopes, and kinds to find existing rules, reports, or chunks before saving, so near-duplicates become revisions.

Instructions

Code lane: searches THOR's memory - every project, archive kinds (Report, Chunk) included - never scoped to only the current project. Call this before remember, so an existing near-duplicate becomes a revise instead. No arguments returns the catalogue of scopes; scope alone lists everything filed there; scope with query narrows a search to it; query alone searches everywhere; key answers only a Lookup item's own exact key (query, scope and kind are then ignored); kind narrows a search to rule, orientation, report or chunk - several at once with a comma, and 'fires' as shorthand for every kind that can fire at a moment, which is what you want when the fact has to steer an action (case-insensitive, an obvious plural such as 'rules' accepted) - without it, Report hits tend to dominate a plain search since their own text runs long, and asking for kind lookup is refused rather than silently answered empty, since a Lookup register only ever answers to its own key. Read-only, and never an injection surface - nothing here reaches you unprompted. Replies with up to 25 matching lines (id, kind, text) and how many more exist, the catalogue, or a plain 'no matches'.

Input Schema

NameRequiredDescriptionDefault
keyNoAn exact Lookup key. When given, this is the ONLY parameter used - `query`, `scope` and `kind` are all ignored - and only a real Lookup item can ever answer it.
kindNoNarrow a search to one kind: rule, orientation, report or chunk - case-insensitive, and an obvious plural ("rules") is accepted too. Applied AFTER the search has already run and AFTER `scope`, so it only ever removes hits, never adds or reorders any. `lookup` (the Lookup kind) is refused outright rather than silently answered empty - see `key` above for the door that actually answers one.
queryNoFree-text search over every live item's text and tags, any project, archive kinds (Report/Chunk) included - never a Lookup item (those answer only to their own `key`, see below).
scopeNoOne scope, by name, as the catalogue lists it. On its own it opens that scope: every item filed under it, one line each, complete. Together with `query` it narrows that search to this scope alone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.6.0
    • changedInput schema / properties / key / description
      Previous value: -"An exact Lookup key. When given, this is the ONLY parameter used -\n`query` and `scope` are ignored - and only a real Lookup item can ever\nanswer it."New value: +"An exact Lookup key. When given, this is the ONLY parameter used -\n`query`, `scope` and `kind` are all ignored - and only a real Lookup\nitem can ever answer it."
    • addedInput schema / properties / kind
      Added value: +{
+  "default": null,
+  "description": "Narrow a search to one kind: rule, orientation, report or chunk -\ncase-insensitive, and an obvious plural (\"rules\") is accepted too.\nApplied AFTER the search has already run and AFTER `scope`, so it\nonly ever removes hits, never adds or reorders any. `lookup` (the\nLookup kind) is refused outright rather than silently answered empty -\nsee `key` above for the door that actually answers one.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the 25-line result cap with a count of remaining matches, the 'no matches' outcome, the catalogue reply, that kind filtering runs after the search and only ever removes hits, and that a 'lookup' kind request is refused rather than silently empty. It also asserts it is never an injection surface and nothing reaches the agent unprompted.

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?

Purpose and the remember-precedence rule are front-loaded, but the rest is a single sprawling run-on sentence dense with em-dashes and parentheticals that is hard to parse in one pass. The content earns its place, yet the packaging is not 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?

With no output schema, the description fully covers the return shapes (matching lines of id/kind/text, a remaining-count, the catalogue, or 'no matches'), the parameter interactions, and the read-only safety profile. Nothing needed to call it correctly 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 100%, so the baseline is 3, but the description adds real meaning: the precedence of key over query/scope/kind, the four search modes, comma-separated multi-kind selection, the 'fires' shorthand, and case-insensitive plural acceptance. These are semantic details the schema does not carry.

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

Purpose4/5

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

States a specific verb and resource ('searches THOR's memory') with an explicit scope statement (every project, archive kinds included, never scoped to the current project) and names the sibling it precedes ('Call this before remember'). It stops short of distinguishing itself from other retrieval siblings like get, resolve or where_used, and the 'Code lane' prefix is unexplained jargon.

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?

Explicitly says when to call it ('Call this before remember, so an existing near-duplicate becomes a revise instead') and routes to the alternative operation (revise) based on the result. It also enumerates every argument combination and what each does, so an agent knows exactly which invocation shape matches its intent.

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

Deploy Server

Other Tools