Memoreei

sync

Idempotent

Refresh memory from the sources configured on the server.

Instructions

Refresh memory from the sources configured on the server.

Runs every connector set up in the server's config, and re-reads any import files that were registered on the server and have changed since. Takes no arguments: it can only refresh what the server's owner has already set up.

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": "sync"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.1Oct 1, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare openWorldHint=false, idempotentHint=true, destructiveHint=false and readOnlyHint=false; the description adds real context by spelling out what it touches (all configured connectors plus changed registered import files) and why it is idempotent (only re-reads files that changed since). It stops short of describing runtime behavior such as blocking/duration or the result of a run.

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?

Three short sentences, the core action front-loaded, and each sentence carries distinct information (what it does, which connectors/files, why it takes no arguments). Nothing is wasted.

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?

For a no-argument tool with no output schema and strong annotations, the description is nearly sufficient: it defines scope, mechanism, and constraints. It could be better if it named the sync_all alternative or hinted at what a run produces (e.g., new-item counts), but nothing essential 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?

There are zero parameters, so the baseline is 4, and the description usefully confirms 'Takes no arguments' and explains why (it can only refresh server-configured sources). No additional param meaning is needed.

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+resource ('Refresh memory from the sources configured on the server') and explains the mechanism (runs every configured connector, re-reads changed import files). However, it never distinguishes itself from the sibling sync_all, which on its face sounds like the same broad operation, leaving the agent to guess which to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies scope with 'it can only refresh what the server's owner has already set up,' which tells the agent this is a config-driven bulk refresh, but gives no explicit when-to-use versus the many alternatives (sync_all, sync_discord, sync_telegram, etc.). Usage is inferable but not directed.

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