Skip to main content
Glama
Sign In
sessionwiki

sessionwiki

by necroz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Ask the wiki

wiki_query
Read-onlyIdempotent

Answers questions about past work by ranking wiki pages and session transcripts, helping you recover prior decisions and fixes before redoing work.

Instructions

Start here for questions about the user's past work ('what did I decide about X', 'how did I fix Y'), in any language: session pages keep the user's original request. Ranks wiki/ pages by keyword matches, rare words weighted higher (no LLM, no embeddings); service pages are skipped and project overview pages rank below sessions. Sessions that name the same tool or topic as two or more top hits rank too, marked 'via '. If no wiki page matches, it falls back to raw transcripts (see include_raw). Returns up to max_pages paths with a ~400-character snippet each, plus the start of wiki/overview.md; with no match, the start of wiki/index.md. Read-only. Open a full page with wiki_read_page; use wiki_search for exact wording.

Input Schema

NameRequiredDescriptionDefault
questionYesNatural-language question or keyword(s) to search for.
max_pagesNoMaximum pages to return (default 5).
include_rawNoRaw session transcripts: true = always rank them too, false = never. Omit it to read them only when no wiki page matches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.5
    • addedInput schema / properties / include_raw
      Added value: +{
+  "description": "Raw session transcripts: true = always rank them too, false = never. Omit it to read them only when no wiki page matches.",
+  "type": "boolean"
+}
  2. First observedv2.0.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: keyword ranking with rare-word weighting, no LLM or embeddings, service pages skipped, project overviews ranked below sessions, 'via <name>' expansion for tool/topic co-occurrence, and raw-transcript fallback. The only small gap is that it doesn't say what happens when both wiki and raw produce nothing beyond the index.md fallback.

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?

Front-loaded and dense with no filler sentences, but the middle sentences are long and clause-stacked (ranking rules, via-marking, fallback), which makes the ranking paragraph harder to scan quickly. Slight tightening into bullets would improve it.

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?

There is no output schema, and the description compensates fully by describing the return shape (up to max_pages paths, ~400-char snippets, overview.md or index.md appendix). For a three-parameter read-only search tool whose annotations are already complete, nothing an agent needs 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: include_raw's tri-state behavior is restated as a fallback policy tied to matching, max_pages is tied to the ~400-character snippet output, and the question parameter's language-independence and use of stored original requests are explained.

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?

Opens with a concrete verb-plus-resource framing ('Start here for questions about the user's past work') and gives example queries that pin down the intent. It explicitly contrasts itself with wiki_read_page (open a full page) and wiki_search (exact wording), so an agent can distinguish it from siblings without opening any schema.

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?

Says exactly when to use it (natural-language questions about past work, any language), when to use alternatives (wiki_search for exact wording, wiki_read_page for full content), and states the no-match fallback path. Both the selection condition and the exclusions are explicit.

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