entroly-context-engine
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ENTROLY_QUALITY | No | Quality dial (0.0-1.0 or preset name) | 0.5 |
| ENTROLY_MAX_FILES | No | Max files to auto-index | 5000 |
| ENTROLY_NO_DOCKER | No | Skip Docker, run natively | |
| ENTROLY_PROXY_PORT | No | Proxy port | 9377 |
| ENTROLY_RATE_LIMIT | No | Max requests/min (0 = unlimited) | 0 |
| ENTROLY_MCP_TRANSPORT | No | MCP transport (stdio or sse) | stdio |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| remember_fragmentA | Store a context fragment with automatic dedup and entropy scoring. Fragments are fingerprinted via SimHash for O(1) duplicate detection. Each fragment's information density is scored using Shannon entropy. Duplicates are automatically merged with salience boosting. Args: content: The text content to store (code, tool output, etc.) source: Origin label (e.g., 'file:utils.py', 'tool:grep') token_count: Token count (auto-estimated if 0) is_pinned: If True, prioritize exact inclusion within the pinned budget reserve; excess pinned content remains a high-priority compressed candidate so the total token ceiling stays honest. |
| optimize_contextA | Select a high-value context subset for a token budget. Uses 0/1 Knapsack dynamic programming to maximize relevance within the budget. Scores fragments on four dimensions: recency (Ebbinghaus decay), access frequency (spaced repetition), semantic similarity (SimHash), and information density (Shannon entropy). QUERY REFINEMENT: Vague queries like "fix the bug" or "add feature" are automatically expanded into precise master prompts using the files already in memory. This improves context selection accuracy and reduces hallucination from selecting wrong files. The response includes query_refinement.refined_query so you can see what drove selection. Output is ordered for optimal LLM attention: pinned/critical first, high-dependency foundation files early, then by relevance. This is the core tool — call it before sending context to the LLM. Args: token_budget: Maximum tokens allowed (default: 128K) query: Current query/task for semantic relevance scoring (can be vague) |
| entroly_retrieveA | Retrieve exact source content omitted by compressed context. Use the retrieval handle attached to a skeleton/reference fragment for exact historical recovery. A visible source path also works and lazily resolves the latest ingested version. With no argument, lists currently materialized CCR entries without returning their content. Args:
source_or_handle: Source path or content-addressed |
| recall_relevantA | Semantic recall of the most relevant stored fragments. Uses BM25 relevance ranking (recall_auto) with a feedback loop (fragments that previously led to successful outputs are boosted). Returns a slim ranked pointer list by default — source, score, and a
locating snippet — because full fragment bodies overflow the tool
result cap (a Args: query: The search query top_k: Number of results to return full: Return complete fragment bodies instead of the slim view |
| record_outcomeA | Record whether selected fragments led to a successful output. This feeds the reinforcement learning loop: fragments that contribute to successful outputs get boosted in future selections, while unhelpful fragments get suppressed. Args: fragment_ids: Comma-separated fragment IDs success: True if output was good, False if bad NOTE on RAVS v1: this tool's success flag is also recorded into
the RAVS event log as an |
| record_test_resultA | Record that tests RAN and either passed or failed for a request. This is a STRONG signal — distinct from record_outcome which is the agent's self-report. Call this when actual test execution produced a real pass/fail outcome. Args: request_id: the trace_id from the optimize_context call passed: True if all tests passed, False if any failed suite: optional name of the test suite (e.g. "pytest", "cargo test") details: optional short summary of what was tested |
| record_command_exitA | Record the exit code of a command that was generated and executed. STRONG signal: a real subprocess produced a real exit code. Convention: exit_code == 0 → "success", anything else → "failure". Args: request_id: the trace_id from the optimize_context call exit_code: subprocess exit code; 0 = success command: optional short representation of what was run |
| record_ci_resultB | Record CI pipeline pass/fail status for a request. STRONG signal: CI is independent infrastructure that ran the change and produced a verdict. The honest top of the signal hierarchy. Args: request_id: the trace_id from the optimize_context call passed: True if CI green, False if any required check failed pipeline: e.g. "github_actions", "gitlab_ci", "buildkite" url: optional link to the CI run |
| record_edit_outcomeA | Record whether the user accepted, reverted, or retried an AI edit. STRONG signal: user behavior directly indicates whether the generated code was successful. Args: request_id: the trace_id from the optimize_context call outcome: "accepted", "reverted", or "retried" files_modified: number of files touched by the edit |
| explain_contextA | Explain why each fragment was included or excluded in the last optimization. Shows per-fragment scoring breakdowns with all dimensions visible: recency, frequency, semantic, entropy, feedback multiplier, dependency boost, criticality, and composite score. Also shows context sufficiency (what % of referenced symbols have definitions included) and any exploration swaps. Call this after optimize_context to understand selection decisions. |
| create_context_receiptA | Create a Context Receipt from supplied documents.
The receipt records selected context, omitted relevant context, dependency links, fingerprints, token ratio, warnings, and risk controls. It does not call an LLM. Set |
| create_context_receipt_from_pathB | Create a Context Receipt from a local document file or directory. Supports text-like documents currently handled by the local receipt ingester (.md, .txt, .rst). The result is deterministic and local. |
| render_context_receiptB | Render a Context Receipt JSON artifact as a Markdown report. |
| explain_receipt_omissionC | Explain why a chunk was omitted from a Context Receipt. |
| recover_receipt_omissionA | Recover the full text of context a Context Receipt omitted. Receipts explain what was dropped; this hands back the exact content,
byte-for-byte. Works on receipts created with Each result carries |
| prepare_proof_guided_contextA | Prepare a durable proof-guided model request from local documents. This tool performs only local selection, security checks, exact-recovery
commitments, and signed auditing. It does not call a model. Send the
returned |
| advance_proof_guided_contextB | Verify one model round and return exact evidence or a final answer. The operation is durable and idempotent. A continuation response has
|
| inspect_proof_guided_contextA | Inspect the last durable proof-guided response without advancing it. |
| checkpoint_stateD | Save state plus explicit decisions needed for safe continuation. |
| resume_stateC | Resume by task relevance; omit query only for latest-checkpoint behavior. |
| prefetch_relatedA | Predict and pre-load context that will likely be needed next. Combines static analysis (imports, callees, test files) with learned co-access patterns to predict what the agent will need. Args: file_path: The file currently being accessed source_content: The source code content (for static analysis) language: Programming language (python, typescript, rust) |
| get_statsB | Get comprehensive session statistics. Shows token savings, duplicate detection counts, entropy distribution, dependency graph stats, checkpoint status, and cost estimates. |
| entroly_dashboardA | Show the real, live value Entroly is providing to YOUR session right now. Pulls from actual engine state — not synthetic data. Shows: Money saved: exact $ amounts from token optimization Performance: sub-millisecond selection speed vs API latency Bloat prevention: context compression ratio and memory footprint Selection quality: per-fragment scoring and context sufficiency Safety: duplicates caught, stale fragments filtered Call this anytime to see exactly what Entroly is doing for you. |
| scan_for_vulnerabilitiesA | Scan code content for security vulnerabilities (SAST analysis). Uses a 55-rule engine with taint-flow simulation and CVSS-inspired scoring. Detects hardcoded secrets, SQL injection, path traversal, command injection, insecure cryptography, unsafe deserialization, XSS, and authentication misconfigurations. Args: content: The source code to scan. source: File path / identifier (used for language detection and confidence scoring). E.g. "auth/login.py". Returns JSON with: - findings: [{rule_id, cwe, severity, line_number, description, fix, confidence, taint_flow}] - risk_score: CVSS-inspired aggregate [0.0, 10.0] - critical_count, high_count, medium_count, low_count - top_fix: most impactful remediation action |
| security_reportA | Generate a session-wide security audit across all ingested fragments. Scans every fragment in the current session and returns an aggregated report showing: which fragments are most vulnerable, overall risk posture, finding distribution by category, and the single most important fix. Returns JSON with: - fragments_scanned, fragments_with_findings - critical_total, high_total, max_risk_score - most_vulnerable_fragment (fragment_id) - findings_by_category: {category: count} - vulnerable_fragments: sorted list by risk_score |
| analyze_codebase_healthA | Analyze the health of the ingested codebase. Runs 5 analysis passes over all fragments in the current session:
Returns a JSON HealthReport with: - code_health_score [0–100] and health_grade (A/B/C/D/F) - Per-dimension scores: duplication, dead_code, coupling, arch, naming - clone_pairs, dead_symbols, god_files, arch_violations, naming_issues - summary (human-readable) and top_recommendation (most impactful action) |
| ingest_diagramA | Ingest an architecture or flow diagram into the context memory. Converts Mermaid, PlantUML, DOT/Graphviz, or informal diagram text into a structured semantic fragment capturing nodes, edges, and relationships. The result is stored as a normal context fragment and is retrievable by optimize_context and recall_relevant. Args: diagram_text: Raw diagram source (Mermaid/PlantUML/DOT/text description). source: Identifier (e.g., 'arch_overview.mmd', 'db_schema.puml'). diagram_type: 'mermaid', 'plantuml', 'dot', 'text', or 'auto' (default). Returns JSON with ingestion result (same as remember_fragment). |
| ingest_voiceA | Ingest a voice/meeting transcript into the context memory. Converts pre-transcribed text (from Whisper, AssemblyAI, etc.) into a structured fragment capturing decisions, action items, open questions, technical vocabulary, and key discussion excerpts. Args: transcript: The full transcript text. source: Identifier (e.g., 'design_meeting_2026-03-07.txt'). Returns JSON with ingestion result plus: - decisions, actions, open_questions (counts) - tech_terms_identified |
| ingest_diffA | Ingest a code diff/patch into the context memory. Converts a unified diff (git diff output) into a structured change summary: intent classification (bug-fix/feature/refactor), symbols changed, files modified, and line delta. Particularly useful for understanding recent changes and their architectural impact. Args: diff_text: Raw unified diff text (git diff output). source: Identifier (e.g., 'pr_42_auth_refactor.diff'). commit_message: Optional commit message for better intent classification. Returns JSON with ingestion result plus: - intent: bug-fix/feature/refactor/test/security/performance - files_changed, added_lines, removed_lines - symbols_changed: functions/classes modified |
| epistemic_routeA | Route a query through the CogOps Epistemic Ingress Controller. Inspects 4 signals (intent, belief coverage, freshness, risk) and selects one of 5 canonical flows: ① Fast Answer: Belief → Action (fresh, verified, low-risk) ② Verify Before Answer: Belief → Verification → Action (stale/risky) ③ Compile On Demand: Truth → Belief → Verification → Action (no beliefs) ④ Change-Driven: Event → Truth → Belief → ... (PR/commit/incident) ⑤ Self-Improvement: Misses → Evolution → Belief (repeated failures) Call this BEFORE optimize_context to understand how the system should approach your query. Existing tools work exactly as before. Args: query: The user query or event description is_event: True if this is a change-driven event (PR, commit, etc.) event_type: Type of event (pr, commit, release, incident, scheduled) |
| vault_statusA | Show the current state of the CogOps Knowledge Vault. Initializes the vault directory structure if needed, then returns a coverage index: total beliefs, verification status, confidence distribution, and routing statistics. The vault is the persistent Living Exocortex — the system's machine-auditable understanding of your codebase. |
| vault_write_beliefA | Write a belief artifact to the CogOps Knowledge Vault. Beliefs are durable system understanding — what Entroly thinks the codebase is. Each belief carries machine-auditable frontmatter: claim_id, entity, status, confidence, sources, last_checked. Args: entity: The system entity this belief is about (e.g., 'auth::token_rotation') title: Human-readable title body: The belief content (markdown) confidence: Machine-assigned confidence 0.0-1.0 (default: 0.7) status: observed|inferred|verified|stale|hypothesis (default: inferred) sources: Comma-separated source paths (e.g., 'src/auth.rs:142,src/token.rs:58') derived_from: Comma-separated component names that produced this belief |
| vault_queryA | Query the CogOps Knowledge Vault for existing beliefs. Use this to check what the system already knows before compiling new understanding. Supports lookup by entity name or listing all. Args: entity: Entity name to look up (fuzzy match) list_all: If True, return all beliefs with frontmatter summary |
| vault_write_actionB | Write a task output or report to the CogOps Knowledge Vault. Action artifacts are developer-facing outputs: PR briefs, answers, architecture diagrams, slide decks, task reports. They live in actions/ and are timestamped for traceability. Args: title: Title of the output content: Full markdown content action_type: Type tag (report, pr_brief, answer, diagram, context_pack) |
| vault_time_travelA | Query the vault's bitemporal belief ledger — memory time travel. Every belief write is versioned in an append-only, hash-chained ledger. This tool answers questions like "what did the vault know last Tuesday?" and "what changed between two dates?". Args:
action: One of:
as_of — snapshot of beliefs visible at |
| vault_hygiene_scanA | Scan vault beliefs against each other for knowledge decay. Report-only living-context maintenance: pairwise ESG contradiction detection between beliefs, near-duplicate merge suggestions, staleness flags, and confidence flapping (entities whose recorded confidence keeps reversing across ledger versions). Never rewrites or deletes a belief — act on the suggestions explicitly. Args: contradiction_threshold: min ESG contradiction_fraction to flag a belief pair (default 0.5) max_age_days: beliefs unchecked for longer are flagged stale (default 30) |
| prepare_task_dreamA | Prepare an expiring, receipt-backed task skill before agent work. The capsule combines safe cross-session MemoryOS recall, optional hippocampal long-term memory, current repository fragments, non-stale beliefs, and already-promoted skills. Recalled text is evidence rather than authority and is prompt-injection scanned. Root AGENTS.md and CLAUDE.md files are never modified. Args: task: The concrete task the agent is about to perform. agent_id: MemoryOS identity used for scoped recall. token_budget: Approximate maximum capsule tokens (256-8000). persist: Write SKILL.md and receipt.json under .entroly/task_dreams. |
| compile_beliefsA | Compile source code into belief artifacts (Truth → Belief pipeline). Scans a directory for source files (.py, .rs, .ts, .js), extracts code entities (classes, functions, structs, traits, imports), resolves cross-file dependencies, and writes belief artifacts to the vault with full frontmatter (claim_id, entity, status, confidence, sources, last_checked, derived_from). Args: directory: Path to scan. Defaults to the project root. max_files: Maximum files to process (default: 200) |
| verify_beliefsB | Run a full verification pass on all beliefs in the vault. Checks for:
Writes verification artifacts to vault/verification/. |
| blast_radiusA | Analyze the blast radius of file changes on existing beliefs. Given a list of changed files, determines which beliefs need re-verification, which may be invalidated, and the overall risk level (low/medium/high). Args: changed_files: Comma-separated list of changed file paths |
| process_changeA | Process a code change through the Change-Driven pipeline (Flow ④). Full pipeline: Diff → ChangeSet → Review → Blast Radius → Vault Classifies intent (bugfix/feature/refactor/test/security/performance), runs code review (hardcoded secrets, TODOs, broad exceptions, unsafe), computes belief impact, and returns a structured PR brief. Args: diff_text: Raw unified diff text (git diff output) commit_message: Optional commit message for intent classification pr_title: Optional PR title |
| execute_flowA | Execute a full canonical epistemic flow end-to-end. Routes the query through the Epistemic Ingress Controller (4 signals: intent, belief coverage, freshness, risk), then chains the appropriate pipeline steps automatically: ① Fast Answer: Belief → Action ② Verify Before Answer: Belief → Verification → Action ③ Compile On Demand: Truth → Belief → Verification → Action ④ Change-Driven: Event → Truth → Belief → Verification → Action ⑤ Self-Improvement: Misses → Verification → Evolution → Belief Args: query: The user query or event description diff_text: Raw diff for change-driven flows (Flow ④) is_event: True if this is a change-driven event event_type: Type of event (pr, commit, release, incident, scheduled) |
| create_skillA | Create a new skill from a capability gap (Evolution layer). When the system repeatedly fails on a topic, this generates a full skill package in vault/evolution/skills//:
Args: entity_key: The entity this skill handles (e.g., 'protobuf_analysis') failing_queries: Pipe-separated list of failing queries intent: The intent class for this skill |
| manage_skillsA | Manage the CogOps skill lifecycle (Evolution layer). Actions:
Args: action: list | benchmark | promote skill_id: Required for benchmark/promote actions |
| coverage_gapsA | Find source files with no corresponding belief in the vault. Scans a directory for source files (.py, .rs, .ts, .js) and checks which ones have no belief artifact. Useful for identifying blind spots before running compile_beliefs. Args: directory: Path to scan. Defaults to the project root. |
| refresh_beliefsA | Mark beliefs as stale after file changes (Flow ④ doc-refresh). Given changed files, finds related beliefs and marks their status as 'stale' so the next verify_beliefs pass will flag them for re-compilation. Args: changed_files: Comma-separated list of changed file paths |
| sync_workspace_changesC | Synchronize workspace file changes into the belief and verification layers. Detects new, modified, and deleted source files, marks affected beliefs stale, recompiles changed files into fresh beliefs, runs a verification pass, and writes a sync report into actions/. |
| repo_file_mapA | Return the canonical Entroly file map across the Python, Rust core, and WASM repos. Use this to understand ownership boundaries and where logic currently lives. Supported formats: markdown, json. |
| start_workspace_listenerB | Start a background workspace listener that continuously feeds repo changes into CogOps. This is the long-running change-driven bridge from repo activity into Belief CI. |
| vault_searchA | Full-text search across all belief artifacts in the vault. Uses TF-IDF ranking with entity-name boosting (3x) to find the most relevant beliefs. Much cheaper than listing all beliefs — returns only the top matches with excerpts. Args: query: Natural language search query (e.g., "how does knapsack work?") top_k: Maximum number of results to return (default: 5) |
| compile_docsA | Compile markdown documentation files into belief artifacts. Ingests project-level docs (README.md, ARCHITECTURE.md, docs/, CONTRIBUTING.md, etc.) into the vault as documentation beliefs with confidence 0.80 (human-authored > machine-inferred code beliefs). Args: directory: Project root to scan. Defaults to the project root. max_files: Maximum doc files to process (default: 50) |
| export_training_dataA | Export vault beliefs as JSONL training data for LLM finetuning. Generates instruction-following pairs from compiled beliefs: question about entity → belief body as answer. Filters out stale and low-confidence beliefs. Output is OpenAI-compatible JSONL. Uses PRISM scoring dimensions for quality-weighted sampling: only beliefs with confidence >= 0.5 and non-stale status are included in the training set. Args: output_path: Path to write JSONL file (default: training_data.jsonl) format: Output format, currently only 'jsonl' supported |
| verify_provenanceA | Verify that LLM-generated code is grounded in the provided context. Uses BIPT (Byte-level Information Provenance Tracer) to measure how much of each identifier in the generated code originates from the context. Returns an Identifier Provenance Deficit (IPD) score: IPD = 0.0 → fully grounded (all identifiers come from context) IPD = 1.0 → fully invented (no identifiers match context) Use this after an LLM generates code to check for hallucinated APIs, invented function names, or fabricated imports before accepting output. Args: code: The LLM-generated code to verify context: The repository context that was provided to the LLM |
| verify_and_repairA | Verify LLM-generated code and suggest repairs for hallucinations. Combines BIPT verification with rejection analysis to identify hallucinated identifiers and suggest which real APIs/symbols from the context should be used instead. This is a single-shot verification + feedback tool — it does NOT call an LLM. For the full repair loop (FORGE), use the Python SDK: from entroly.verifiers import forge_loop Args: prompt: The original user request that generated the code code: The LLM-generated code to verify context: The repository context provided to the LLM |
| verify_responseA | Verify an AI-generated response for hallucination using the 4-signal fusion cascade. Runs the same hallucination detection pipeline as the proxy (WITNESS + ECE + EPR + Spectral) but callable directly from any MCP client. Use this after generating a response to check for factual claims that aren't grounded in the provided context. Returns a structured verification report with:
All computation is 100% local — zero LLM calls, zero API calls. Args: response: The AI-generated text to verify context: The source context that was provided to the AI prompt: The original user prompt/query (helps calibrate verification) |
| eicv_verify_claimA | Verify a single claim against evidence using the EICV pipeline. Returns a structured EICVCertificate with:
Computed locally with no neural model and no LLM calls. Accuracy on public benchmarks (FEVER, SQuAD v2, HaluEval-QA) is documented in benchmarks/results/. False-positive and false-negative rates are non-zero — review those JSONs before relying on the output for compliance-sensitive decisions. Args: evidence: The grounding context (retrieved passages, source material) claim: The single claim to verify against evidence profile: "rag" | "qa" | "summarization" | "dialogue" | "fact_check" | "default". Selects the abstain decision band. |
| eicv_suppress_hallucinationsA | Verify an LLM response and optionally rewrite hallucinated claims. Returns the (possibly rewritten) output and per-claim audit trail. Computation is fully local — no neural model, no LLM calls. Modes: audit — analyze only; no rewrite. Use for telemetry/dashboards. annotate — keep output; append verification warnings at end. strict — graduated 4-action policy: supported → PASS (no change) abstain → HEDGE (append "[unverified]") hallucinated → SUPPRESS (remove claim sentence) Profiles tune the abstain band: rag (default) — strict, for retrieval-augmented generation qa — moderate-strict for QA outputs summarization — tolerant of paraphrase dialogue — broader abstain band fact_check — hardest (FEVER-like setting) Returns SuppressionResult with:
Accuracy on public datasets is documented in benchmarks/results/. False-positive and false-negative rates are non-zero — a truthful claim can be wrongly suppressed, and a false claim can pass through. Audit-mode is the safe default for compliance- sensitive applications. Args: context: The grounding evidence the LLM was supposed to use output: The LLM's response text to verify and possibly rewrite profile: Suppression profile (default "rag") mode: "audit" | "annotate" | "strict" (default "strict") |
| smart_readA | Read a file at an automatic or caller-chosen resolution. By default SRP selects the optimal resolution per code block from query relevance and token budget:
This reduces output by prioritizing query-relevant blocks. Use
Automatic selection is the right default and cannot be right for every
question. Measured on this repository, a signature-level view answered
12/12 questions whose evidence lives in a signature and 0/20 whose
evidence lives in a function body. Pass Args:
file_path: Path to the file to read
query: What you're looking for (improves relevance scoring)
budget: Target token budget for the output (default: 1000)
resolution: Choose "full", "medium", "diff", "structure", or
"low"; empty means automatic. "full" returns the complete
original text.
"diff" requires An exact repeated delivery returns only an opaque |
| security_scanA | Scan content for prompt injection attacks and security threats. Detects:
Use this to verify untrusted content before including it in prompts. Args: content: The text content to scan source: Source identifier for threat location reporting |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| context_optimization_workflow | Build a safe workflow for selecting the best context for a task. |
| context_verification_workflow | Build an evidence-first verification workflow for an agent task. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| entroly_health_resource | Return a bounded, secret-free Entroly runtime health summary. |
| entroly_stats_resource | Return bounded aggregate counters without source content or paths. |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/juyterman1000/entroly'
If you have feedback or need assistance with the MCP directory API, please join our Discord server