Skip to main content
Glama
juyterman1000

entroly-context-engine

by juyterman1000
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

sync_workspace_changes

After code edits, update Entroly's beliefs and verification: detect changed files, recompile, verify, and write a bounded sync report.

Instructions

Reconcile workspace changes into Entroly's local belief and verification layers.

Use this for one explicit synchronization pass after edits. It detects new, modified, and deleted supported source files, marks affected beliefs stale, recompiles changed files, runs verification, and writes a bounded sync report plus listener state under the local Entroly vault. It never writes source files. force requests a full rescan and max_files limits changed files processed in this pass; unprocessed changes remain pending for a later pass. Invalid or outside-root directories return a structured error.

Use start_workspace_listener for periodic background polling, refresh_beliefs when only invalidation is needed, and verify_beliefs when files are already compiled and only verification is required. The JSON result includes status, counts, verification summary, action path, and per-file errors.

Args: directory: Optional root-confined workspace directory. force: Whether to ignore the saved snapshot and rescan. max_files: Positive per-pass changed-file limit (1-10000).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoRescan all discovered source files even when the saved snapshot reports no changes.
directoryNoWorkspace directory to scan; empty uses the server project root and paths stay root-confined.
max_filesNoMaximum changed files processed in this pass; use later passes for the remaining backlog.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.64
    • addedInput schema / properties / directory / description
      Added value: +"Workspace directory to scan; empty uses the server project root and paths stay root-confined."
    • addedInput schema / properties / force / description
      Added value: +"Rescan all discovered source files even when the saved snapshot reports no changes."
    • addedInput schema / properties / max_files / description
      Added value: +"Maximum changed files processed in this pass; use later passes for the remaining backlog."
    • addedInput schema / properties / max_files / maximum
      Added value: +10000
    • addedInput schema / properties / max_files / minimum
      Added value: +1
  2. Addedv1.0.54
  3. Removedv1.0.54
  4. First observedv1.0.42

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It thoroughly explains side effects: marking beliefs stale, recompiling, verifying, writing a sync report and listener state, and never writing source files. It also covers edge behavior for force, max_files, pending changes, and invalid directories.

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?

The description is front-loaded with the core purpose, then moves through usage context, key behaviors, alternatives, and result shape without redundancy. Every sentence contributes meaningful operational guidance.

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?

Despite the tool's complexity and the presence of many siblings, the description covers when to use it, what it does, what it does not do, parameter semantics, error cases, and the JSON result shape. An agent has enough to call it correctly without additional inference.

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 schema already documents each parameter. The description adds useful behavioral context, such as 'unprocessed changes remain pending for a later pass' and 'invalid or outside-root directories return a structured error,' which goes beyond bare parameter definitions. This is a modest improvement over the high-coverage baseline.

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 a specific verb ('Reconcile') and resource ('workspace changes into Entroly's local belief and verification layers'), and it clearly distinguishes the tool from siblings like start_workspace_listener, refresh_beliefs, and verify_beliefs. An agent can immediately understand what this tool does and what makes it unique.

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?

It explicitly says to use this for 'one explicit synchronization pass after edits' and then names the exact alternative tools for polling, invalidation-only, and verification-only needs. This gives unambiguous routing guidance for an agent deciding between similar tools.

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