Skip to main content
Glama
gordonkjlee

Facthouse

by gordonkjlee
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_stats

Check knowledge-base size and memory health: active and historical facts, entity/domain counts, fact distribution, and reclaimable log space.

Instructions

Get knowledge base statistics — how many facts are currently true, how many are held in total including superseded history, entity and domain counts, how facts are distributed across domains, and how much raw log can be reclaimed.

Call this when the user asks what you know or remember about them, how much you have stored, or whether their memory is working. This answers "how much do you know", not "what do you know" — use search_knowledge, get_entity or get_context for actual recall.

semantic is present when this store is configured for meaning search. semantic.stored is how many currently-true facts already have a vector for the working model (and dimension, when known). embeddings lists every vector group the store holds, including leftovers from a previous model — leftover rows do not serve meaning search. No semantic object means keyword-only, which is the default, even if embeddings still lists leftover rows. When semantic is present and semantic.stored is well below facts.active_latest, facts are findable by wording but not yet by meaning — call consolidate. Search does not wait for full coverage: unembedded facts still match on words.

extract.unextracted_events is how many transcript lines extract has not examined. pending_facts is I not yet integrated. A large unextracted count with a healthy fact count means capture is writing D that extract has not examined.

intelligence is billed consolidation spend (calls, tokens, elapsed), broken down by stage and provider for the last 24 hours, all time, and the last few runs. Embeddings are not this number — they are a separate API. Token fields are omitted when the provider did not report them, not shown as zero.

token_budget is remaining room under optional intelligence.token_budget caps (per billed provider, rolling hour / day / week / month). Unset means unlimited. Over the cap, consolidate skips extract, holds the watermark, and does not fall back to the heuristic.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.30.1

TDQS

A4.1/5.0
Behavior3/5

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

The description reveals the core behavior — it returns all calls, unpaginated, with no filtering — which is valuable given the readOnlyHint annotation. However, it does not disclose full output shape, potential size limits, or whether the endpoint accepts optional filters. The safety profile is partially covered by the annotation, but pagination and response structure are left unspecified.

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

Conciseness5/5

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

Two sentences, no filler, and the critical scoping constraint ('no user/workspace filtering – use the other tool') is front-loaded. The warning about timezone is a single short clause. Very efficient.

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

Completeness3/5

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

No output schema exists for this tool, and the description does not describe the response shape, pagination, or failure modes. The tool's main behavioral constraint, unbounded date range, is stated, but an agent cannot fully anticipate what comes back. Since annotations are absent too, the description must carry more weight than it does.

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

Parameters3/5

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

Both parameters are trivially explained by their names and types in the schema (date/time strings), and the description does not add much beyond restating them. The one genuinely useful addition is the timezone expectation, which the schema does not convey. This raises the score slightly from a baseline of 3.

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 precise verb and object: 'List ALL calls in date range – no user/workspace filtering.' It not only states what the tool does but immediately distinguishes it from the filtering alternative, search_calls_extensive. The name alone would be ambiguous; this description removes all doubt.

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 explicitly tells the agent when this tool is appropriate ('no user/workspace filtering') and when it is not, pointing directly to the sibling tool that does filter. This is clear routing guidance that an agent can act on without opening any schema.

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