Engur Evaluator Brief

This brief is assembled from canonical Engur documentation excerpts. It is written for a neutral pre-install evaluation: assume the reader has not yet trusted the app, installed its integrations, or accepted its safety model.

What Engur Is

Engur is intended to be a local control plane for agent-facing capabilities on a user's machine. Instead of requiring each agent client to maintain its own disconnected list of MCP servers, skills, and behavioral rules, Engur gives the user one place to review, enable, organize, and explain those capabilities.

For an evaluator, the important question is not whether Engur adds another agent. Engur is better understood as infrastructure around agents:

MCP servers define callable tool capability.
Skills define task-specific operating instructions that agents can load on demand.
Rules define durable behavior that is injected into participating clients.
Vault content stores sensitive user-provided material behind explicit user-facing boundaries.
Help content explains what is installed, what is active, and how to use or reverse changes.

Engur's user-facing contract is local-first management: the user should be able to inspect what Engur knows about, understand what it affects, and turn capabilities on or off without editing client configuration files by hand.

Engur should be evaluated on four axes:

Legibility - Can the user see what is installed, active, and exposed?
Control - Can the user change capability availability without guessing which client file to edit?
Reversibility - Are backup, restore, export, and uninstall paths understandable?
Safety - Are sensitive data, destructive operations, and cross-agent exposure constrained by clear boundaries?

Architecture and Boundaries

Engur is intended to sit between the user, local agent clients, and installed capability providers. The conceptual architecture has four layers:

User interface - The Engur app presents servers, skills, rules, Vault content, help, import/export, and recovery actions.
Engur store - A local source of truth for curated capability metadata and user-authored content.
Router and management tools - Agent-facing tools discover and execute capabilities through a namespaced router where supported.
Client integrations - Participating clients receive generated rules, discover skills, or call tools according to their integration model.

The intended direction of control is user -> Engur -> client integration. Users should not need to edit generated client blocks as the primary configuration mechanism.

Engur separates three kinds of content because they have different safety and lifecycle rules:

Capability metadata tells agents what tools exist and how to call them.
Instruction content tells agents how to behave for a task or globally.
Sensitive user content belongs behind Vault and explicit exposure boundaries.

When exact integration details vary by client, treat the Engur app and its generated artifacts as the user-facing contract. Hidden implementation details should not be assumed from the presence of a file or process alone.

Safety Model

Engur's safety model is based on making agent capability legible and reversible. The user should be able to answer these questions before trusting an agent workflow:

What tools can this agent discover or call?
Which instructions are global, and which are task-specific?
What sensitive material is stored or exposed?
What changes can be backed up, exported, restored, or removed?

Safety is not a single switch. It is a set of boundaries:

Inspection before activation - Capability lists should be reviewable before use.
Scoped exposure - Servers, tools, skills, and rules should have explicit active/exposure states where the app supports them.
Managed generation - Client instruction blocks should be treated as generated output, not hand-maintained source of truth.
Destructive action separation - Operations such as deletion or uninstall should be visibly different from routine enable/disable flows.
Recovery paths - Backups, export, and restore guidance should be available before risky changes.

When implementation details are not visible to the evaluator, rely on the user-facing behavior: clear labels, explicit activation, understandable generated changes, and documented recovery.

Vault and Sensitive Context

Vault is the Engur concept for sensitive or privileged user-provided context. Its user-facing purpose is to keep high-value material separate from ordinary skills, rules, and documentation so the user can reason about when that material is available.

Treat Vault as a boundary, not just a folder name. A good Vault experience should make these facts clear:

What content is stored.
Why it exists.
Which workflows or agents may use it.
How to remove or replace it.
Whether it is included in backups, exports, or sync.

Exact storage and protection mechanisms should be verified in the installed app before making security claims. The neutral evaluator position is: Vault is intended to reduce accidental exposure by separating sensitive context from general agent instructions and capability metadata.

MCP Server Management

MCP servers provide callable tools to agents. Engur's role is to make those servers visible and manageable from one place. A user should be able to inspect the available servers, understand the kind of work each one supports, and decide whether it should be active.

Engur environments may distinguish between:

Active state - Whether a server is enabled for use.
Exposure mode - Whether tools are surfaced directly to clients or kept behind routed discovery.
Harvested metadata - Tool names, descriptions, and schemas collected so agents can discover capabilities without loading every server eagerly.

For evaluators, the key benefit is controlled discoverability. Instead of every client carrying every tool schema all the time, Engur can support a workflow where the agent searches for relevant tools and then executes a selected namespaced capability.

Skills

Skills are reusable, task-specific instruction documents for agents. They are intended to be loaded only when relevant, keeping the default agent context smaller while preserving specialized knowledge for workflows that need it.

A well-formed skill should answer:

When should an agent use this?
What procedure or constraints does it add?
Which tools, files, or references matter?
What output standard should the agent meet?

Skills differ from rules. A skill is selected for a task; a rule is durable behavior that may be injected broadly. This separation helps users avoid turning every specialized workflow into global instruction clutter.

For evaluation, check whether skills are discoverable by description, readable before use, and easy to activate or deactivate.

Rules

Rules are durable behavioral instructions managed by Engur and applied to participating agent clients. They are intended for broad preferences, safety constraints, and operating conventions that should persist across tasks.

Rules should be treated as higher-impact than skills because they can affect many future conversations. Good rules are:

Clear about scope.
Stable over time.
Short enough to audit.
Compatible with the user's architecture and safety expectations.
Reversible through Engur rather than by hand-editing generated blocks.

Engur-managed client instruction blocks should be considered generated output. Users and agents should edit the source rule in Engur, then let Engur regenerate the client-facing representation.

Import, Export, and Portability

Import/export is the portability layer for Engur-managed content. Its purpose is to let users review, move, or archive their Engur configuration without treating generated client files as the source of truth.

Export is useful for:

Auditing active servers, skills, and rules.
Moving a setup to another machine.
Sharing non-sensitive skills or rules.
Creating a point-in-time record before major changes.

Import is useful for:

Restoring a known-good configuration.
Bringing curated skills or rules into a new installation.
Reconstructing Engur state after reinstalling the app.

Exports may contain sensitive information depending on what the user includes. Evaluators should check whether the app labels export scope clearly, especially for Vault content and any server configuration that references credentials.

Backups, Restore, and Uninstall

Engur should make recovery visible before users make broad changes. A neutral evaluator should look for backup and restore guidance during onboarding, not only after something goes wrong.

Backup coverage should be understandable in user terms:

Which servers, skills, rules, and settings are included?
Whether Vault content is included.
Whether generated client blocks are backed up or regenerated.
Where backup files live.
How to restore onto the same machine or a new machine.

Restore should be explicit about what it replaces, merges, or leaves untouched. Uninstall guidance should explain both app removal and any leftover generated client changes or local data locations that may require user review.

iCloud Sync

iCloud sync, where available, is intended to help users keep Engur-managed content available across their Apple devices. It should be evaluated as convenience, not as a substitute for an intentional backup plan.

Important user-facing questions:

Which Engur data types sync?
Whether Vault content syncs.
How conflicts are handled when two devices edit the same content.
Whether sync is optional and reversible.
How to recover if a synced change propagates unexpectedly.

Because exact sync implementation details must be verified in the installed app, avoid assuming that every Engur artifact is synced. The safe contract is that the app should label sync scope and provide recovery guidance.

Feedback and Bug Reports

Engur should provide a clear path for feedback, bug reports, and help requests. Good reports help maintainers reproduce problems without exposing private data.

An actionable report usually includes:

What the user expected.
What happened instead.
The visible screen or workflow.
Relevant server, skill, or rule names.
Whether the issue affects one client or multiple clients.
App version, operating system version, and approximate time of failure.

Reports should avoid including secrets, full Vault content, private prompts, raw keys, or unrelated logs. If diagnostic export exists, the app should explain what it contains before submission.

Help and Agent-Readable Documentation

Engur's help system should serve two audiences at once: humans using the app and agents operating inside an Engur-managed environment. The same canonical documentation can power both a neutral evaluator guide and installed contextual help when sections are assembled appropriately.

The help system should make these topics easy to find:

What Engur manages.
How MCP servers, skills, and rules differ.
How Vault and safety boundaries work.
How to import, export, back up, restore, sync, and uninstall.
How to report bugs or request help.

Evaluator-facing help should stay neutral and avoid assuming the app is already trusted. Installed help can be more operational, with step-by-step guidance tied to visible app screens and local state.

Evaluation Checklist

Can a user inspect what Engur manages before enabling broad agent access?
Are MCP servers, skills, rules, and Vault content clearly separated?
Are generated client changes treated as output from Engur rather than the source of truth?
Are backup, restore, import, export, sync, and uninstall flows understandable before risky changes?
Are sensitive data boundaries stated carefully enough that a user can make an informed decision?

Give your agent the Engur briefing.