Entroly
PYPI · ENTROLY · 2 COMPONENTS · SCANNED SEP 20
Context Assurance for AI agents: context engineering, AI cost optimization, verification.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 0 of 31 dependencies flagged as unhealthy. View diagnostics → Pass
Provenance & Transparency35
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 6 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability79
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 9873 tokens (~118/item across 83 items; 81 tools + 2 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management93
- Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety75
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- 0 of 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "execute_flow" implies "execute" and declares no destructiveHint at all, which the MCP spec reads as destructive by default. See how to fix → Fail
- An AI judge read all 83 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the Entroly MCP server?
Entroly runs locally as a PyPI package, launched with uvx entroly. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · entroly
claude mcp add juyterman1000-entroly -- uvx entroly
{
"mcpServers": {
"juyterman1000-entroly": {
"command": "uvx",
"args": [
"entroly"
]
}
}
} {
"servers": {
"juyterman1000-entroly": {
"command": "uvx",
"args": [
"entroly"
]
}
}
} codex mcp add juyterman1000-entroly -- uvx entroly
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"juyterman1000-entroly": {
"type": "local",
"command": [
"uvx",
"entroly"
],
"enabled": true
}
}
} openclaw mcp add juyterman1000-entroly --command uvx --arg entroly
mcp_servers:
juyterman1000-entroly:
command: "uvx"
args: ["entroly"] {
"McpServers": {
"juyterman1000-entroly": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"entroly"
]
}
}
} assistant mcp add juyterman1000-entroly -t stdio -c uvx -a entroly
{
"mcpServers": {
"juyterman1000-entroly": {
"command": "uvx",
"args": [
"entroly"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 16 Sept 26 −2
- Stability: pass → 0.80 functional
- 15 Sept 26 0
- Stability: 0.97 → pass security
- 14 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.
- 13 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 1.0.81 → 1.0.84 functional
- 11 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 9 Sept 26 +1
- Security disclosure: unverified → pass ▲ functional
- 8 Sept 26 0
- Security disclosure: pass → unverified ▼ functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 20 Sept 2026 · Analysed pypi/entroly@1.0.84
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 31 packages
| Packages resolved | 31 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
shared_memory_list ~43
List shared memory entries, optionally filtered by agent or tag.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| limit | integer | – | – |
| tag | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
shared_memory_search ~46
Search cross-agent shared memory by relevance. Returns entries from all agents.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| query | string | yes | – |
| top_k | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
shared_memory_stats ~16
Get cross-agent shared memory statistics.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
shared_memory_write ~57
Write to cross-agent shared memory. Deduplicates near-identical entries via SimHash.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| content | string | yes | – |
| session_id | string | – | – |
| tags | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
smart_read ~594
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: - Blocks matching the query → FULL (complete source) - Related blocks → MEDIUM (signature + docstring) - Peripheral blocks → LOW (name only) - Irrelevant blocks → SKIP (omitted) This reduces output by prioritizing query-relevant blocks. Use ``resolution="full"`` whenever exact source text is required. 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 `resolution` when you already know which kind of question you are asking. 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 `previous_source` and returns a whole-file unified diff. "structure" returns declarations, signatures, and imports while eliding implementation bodies when a useful native outline is available; otherwise it returns full source and reports `structure_backend="full-fallback"`. Pinned output is not demoted to fit the budget; the response reports `over_budget` instead. previous_source: Required baseline when resolution is "diff". line_start: First line of an exact inclusive range (1-indexed). Must be supplied together with `line_end` and cannot be combined with `resolution`. line_end: Last line of an exact inclusive range (1-indexed). fresh: Bypass same-session re-read suppression and return the rendered output in full. read_scope: Optional caller scope f…
| Name | Type | Req | Description |
|---|---|---|---|
| budget | integer | – | – |
| file_path | string | yes | – |
| fresh | boolean | – | – |
| line_end | integer | – | – |
| line_start | integer | – | – |
| previous_source | string | – | – |
| query | string | – | – |
| read_scope | string | – | – |
| resolution | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
start_workspace_listener ~70
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.
| Name | Type | Req | Description |
|---|---|---|---|
| directory | string | – | – |
| force_initial | boolean | – | – |
| interval_s | integer | – | – |
| max_files | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
steer_output ~36
Classify query effort and return output steering directives + max_tokens budget.
| Name | Type | Req | Description |
|---|---|---|---|
| effort | string | – | – |
| query | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
sync_workspace_changes ~82
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/.
| Name | Type | Req | Description |
|---|---|---|---|
| directory | string | – | – |
| force | boolean | – | – |
| max_files | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_hygiene_scan ~139
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)
| Name | Type | Req | Description |
|---|---|---|---|
| contradiction_threshold | number | – | – |
| max_age_days | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_query ~87
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
| Name | Type | Req | Description |
|---|---|---|---|
| entity | string | – | – |
| list_all | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_search ~106
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)
| Name | Type | Req | Description |
|---|---|---|---|
| query | string | yes | – |
| top_k | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_status ~73
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_time_travel ~331
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 `when` diff — what changed between `from_when` and `to_when` timeline — version history for `entity` verify_chain — tamper-check the ledger hash chain seed — backfill the ledger from pre-ledger belief files redact — erase belief bodies (by `entity` or `claim_id`) via a chained tombstone; content is deleted, the hash chain stays verifiable when: ISO-8601 instant for as_of (e.g., '2026-07-14T00:00:00+00:00') from_when: ISO-8601 start instant for diff to_when: ISO-8601 end instant for diff entity: Entity name for timeline time_axis: 'transaction' = what the vault knew at that instant (default); 'valid' = what had been verified as of that instant
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | – |
| claim_id | string | – | – |
| entity | string | – | – |
| from_when | string | – | – |
| reason | string | – | – |
| time_axis | string | – | – |
| to_when | string | – | – |
| when | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_write_action ~116
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)
| Name | Type | Req | Description |
|---|---|---|---|
| action_type | string | – | – |
| content | string | yes | – |
| title | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vault_write_belief ~234
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
| Name | Type | Req | Description |
|---|---|---|---|
| body | string | yes | – |
| confidence | number | – | – |
| derived_from | string | – | – |
| entity | string | yes | – |
| sources | string | – | – |
| status | string | – | – |
| title | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
verify_and_repair ~156
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
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | – |
| context | string | – | – |
| prompt | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
verify_beliefs ~72
Run a full verification pass on all beliefs in the vault. Checks for: - Staleness (beliefs past their freshness window) - Contradictions (conflicting claims about the same entity) - Confidence divergence between same-entity beliefs - Low confidence scores Writes verification artifacts to vault/verification/.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
verify_provenance ~172
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
| Name | Type | Req | Description |
|---|---|---|---|
| code | string | yes | – |
| context | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
verify_response ~254
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: - fused_risk: Combined hallucination probability [0.0 = safe, 1.0 = hallucinated] - verdict: "pass", "warn", or "flag" - per-signal scores (entity_coverage_gap, ece_curvature, epr_rate, spectral_consistency) - flagged_claims: List of specific claims that may be hallucinated - recommendation: Suggested action (accept / review / reject) 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)
| Name | Type | Req | Description |
|---|---|---|---|
| context | string | – | – |
| prompt | string | – | – |
| response | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_acknowledge_recovery ~37
Accept responsibility for recovered work state so acting is allowed.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | – | – |
| token | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_claim ~78
Record explicit agent work plus a bounded advisory scope lease.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | yes | – |
| project | string | – | – |
| scope_paths | – | – | – |
| scope_symbols | – | – | – |
| session_id | string | – | – |
| task_id | string | – | – |
| task_title | string | yes | – |
| ttl_seconds | number | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_compile_context ~85
Compile verified code context and record its Work Graph receipt.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| max_fragments | integer | – | – |
| max_hops | integer | – | – |
| project | string | – | – |
| query | string | yes | – |
| session_id | string | – | – |
| token_budget | integer | – | – |
| workstream_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_context_fault ~81
Fault exact omitted code from a context token or verified context object.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| context | – | yes | – |
| context_ref | string | yes | – |
| project | string | – | – |
| recovery_handle | object | yes | – |
| session_id | string | – | – |
| token_budget | – | – | – |
| workstream_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_handoff ~53
Create a graph-bound handoff receipt and complete continuation proof.
| Name | Type | Req | Description |
|---|---|---|---|
| from_agent | string | yes | – |
| project | string | – | – |
| to_agent | string | yes | – |
| workstream_id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_modifications ~77
Modifications recorded between observations by the workspace watcher. A point-in-time refresh shows what a file looks like now. This shows that it changed at 14:02 and again at 14:07, which a refresh cannot. Empty when the watcher is disabled.
| Name | Type | Req | Description |
|---|---|---|---|
| drain | boolean | – | – |
| project | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_record_context ~50
Attach a canonical ContextReceipt to its exact WorkScope.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| project | string | – | – |
| receipt | object | yes | – |
| session_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_record_execution ~57
Atomically record route, observable execution and exact-head verification.
| Name | Type | Req | Description |
|---|---|---|---|
| invalidated_commitments | – | – | – |
| outcome | object | yes | – |
| project | string | – | – |
| route | object | yes | – |
| verification | object | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_record_memory ~48
Attach provenance-bearing memory without trusting raw model prose.
| Name | Type | Req | Description |
|---|---|---|---|
| memory | object | yes | – |
| now_ms | integer | – | – |
| project | string | – | – |
| superseded_ids | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_resume ~53
Recover unfinished work and optionally seal a no-handoff proof.
| Name | Type | Req | Description |
|---|---|---|---|
| max_evidence | integer | – | – |
| project | string | – | – |
| to_agent | string | – | – |
| workstream_id | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_session_status ~26
Report the automatic takeover performed when this server started.
| Name | Type | Req | Description |
|---|---|---|---|
| project | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
work_state ~35
Inspect persisted shared work state without appending a polling event.
| Name | Type | Req | Description |
|---|---|---|---|
| now_ms | integer | – | – |
| project | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
What is the Entroly MCP server?
Entroly is an MCP server listed in the public MCP registry as io.github.juyterman1000/entroly. Context Assurance for AI agents: context engineering, AI cost optimization, verification. This page covers its PyPI package (entroly).
Is the Entroly MCP server safe to use?
Entroly scores 63 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Entroly MCP server expose?
Entroly exposes 81 tools: remember_fragment, optimize_context, entroly_retrieve, recall_relevant, record_outcome, and 76 more. Their descriptions and schemas cost roughly 9,740 tokens of context every time the server is loaded.
Is the Entroly MCP server still maintained?
Entroly is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.