Skip to main content
Glama
Sign In
apex-memory

apex-memory

by Shaurya-GitH
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

list_domains

Lists memory domains with descriptions, note counts, last activity, system-failure flags, and owner preferences, helping agents choose the right domain before calling brief.

Instructions

Every domain: its description (what it holds and when to choose it), note count, last log activity, and ops: true for the domain that records the memory system's own failures. Choose domains by description, then call brief. description_missing: true means the index has no summary; the first paragraph of the index stands in for it. preferences: the owner's active preferences for every domain (e.g. "No knowledge base for ": do not ask again to create one).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_domains"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description must carry the full behavioral burden. It discloses the output fields (description, note count, last log activity, ops flag, description_missing, preferences) and explains some semantics (e.g., ops: true for the failure-recording domain). However, it does not explicitly state that the operation is read-only, has no side effects, or requires no special authentication—gaps that are important given the lack of annotations.

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 informative but not optimally structured. It opens with a list of fields rather than a clear statement of the tool's primary action, and the phrasing 'Every domain: its description...' is somewhat cryptic. The usage instruction appears mid-description rather than front-loaded, making the text feel slightly dense and less scannable.

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

Completeness4/5

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

Given the absence of an output schema and annotations, the description does a good job explaining the returned fields and their meanings (e.g., description_missing, ops, preferences). However, it omits details such as ordering, whether all domains are returned in one call, or what 'last log activity' represents, leaving minor gaps for a tool that returns a potentially large list.

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?

The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics, and it adds no conflicting or extraneous parameter information.

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 states that the tool returns every domain with its description, note count, last log activity, ops flag, and preference information. It also explicitly tells the agent to 'Choose domains by description, then call brief,' clearly distinguishing this listing tool from the sibling 'brief' tool. An agent can immediately understand what the tool does and how it fits with alternatives.

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 usage guidance: 'Choose domains by description, then call brief.' It also includes a when-not directive: if a preference says 'No knowledge base for <topic>', do not ask again to create one. This gives both the intended workflow and a clear exclusion condition, leaving little ambiguity.

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