Cellar provides a structured, multi-source computer use platform for AI agents to perceive, interact with, and automate tasks across desktop and browser environments through 4 composable tools.
cel_see — Screen Observation
Read structured UI elements with types, labels, bounds, and confidence scores
Capture screenshots, list windows/monitors, get cursor position
Inspect elements by ID or coordinates, create resilient element references
Retrieve browser (CDP) page content, debug targets
Wait for elements to appear (with timeout) or screen to stabilize (idle detection)
Watch for 18 event types: tree changes, network idle, focus/value/window/menu/selection changes, and more
cel_act — Screen Interaction
Click (single, right, double), move mouse by coordinates or element reference
Type text, press keys, execute keyboard combos with modifiers
Perform native accessibility API actions (ax_action) and set values directly on form fields/checkboxes
Write and read spreadsheet cells deterministically (Numbers app)
Scroll, drag & drop, execute JavaScript in browser via CDP
Batch up to 4 sequential actions in one call
cel_think — Planning, Memory & Autonomous Execution
Delegate a natural language goal for fully autonomous see→plan→act execution (run_goal)
Generate LLM-powered step-by-step plans (with optional vision/screenshot)
Store and search persistent knowledge via FTS5 full-text search
Get/set per-workflow working memory (scratchpad)
Record observations with priority levels, track runs with confidence scores
Send text or image+text directly to the LLM (passthrough)
cel_perceive — Always-On Continuous Perception (Cortex)
Start a continuously-updated mental model of the screen with a goal
Get instant snapshots kept warm by background event streams
Report actions and receive verification (screen diff + settlement detection)
Checkpoint completed work and reset action history between task phases
Check Cortex health: confidence score, uptime, cycle count, element stability
Stop the Cortex and receive a session summary
Additional Capabilities
Multi-source fusion: Combines accessibility tree, CDP, vision, network, and app-specific adapters (Apple Calendar, Mail, Numbers; planned for Excel, Slack, Figma) into structured JSON with confidence scoring
Agent & model agnostic: Works with LangGraph, Mastra, Claude Code, Cursor, n8n and LLMs including OpenAI, Anthropic, Gemini, and local Ollama
Hybrid runtime: Prioritizes structured sources (accessibility, native APIs) and escalates to vision only when needed; prevents infinite loops via impossible-action detection
CLI: Commands for init, setup, context viewing, screen capture, actions, MCP server, workflows, and training mode
Platform support: Full macOS support (AXUIElement, Cortex, MCP); Linux via AT-SPI2; Windows UI Automation planned
Provides a first-party adapter for SAP GUI, enabling structured interaction with SAP applications through accessibility and input injection.
CEL is the open context and trust data plane for AI agents.
CEL gives agent builders reusable contracts for four things every serious agent runtime needs:
fuse many sources into one canonical context snapshot
persist cross-turn memory locally or behind your own backend
assemble governed model briefs with receipts
inspect what the agent saw, remembered, sent to the model, and later claimed
The open project is intentionally not the full Cellar runtime. The live cortex engine, policy enforcement, monitoring, compliance workflows, hosted workers, and GUI surfaces are the commercial Cellar/Dilipod operating layer built on these contracts.
Each crate is published on crates.io and maintained in a
standalone repository. This workspace (cellar-oss) mirrors them for integrated
examples and shared docs.
Crate | Repository | Role | Start here |
| |||
Memory trait, sessions, scopes, write hooks | |||
Local SQLite + vector + FTS backend | |||
Brief assembly, budgeting, governance, receipts | |||
Action, planning, and execution receipt schemas | |||
LLM summarizers for session rollups (Anthropic + Ollama) |
Current release line: 0.2.0 on crates.io. Upgrading from 0.1.x? See docs/migration-0.2.md.
See docs/crates.md for the full crate matrix.
Related MCP server: native-devtools-mcp
+------------------------------------------------------------+
| Agents LangGraph | Mastra | Claude Code | Cursor |
| Codex | GPT | Gemini | n8n | MCP clients |
+------------------------------------------------------------+
| Cellar live cortex runtime, policy, monitoring, |
| runtime compliance, hosted execution, GUI workflows |
+------------------------------------------------------------+
| CEL OSS context snapshots, memory, brief assembly, |
| contracts transport schemas, receipts |
+------------------------------------------------------------+
| Sources browser | desktop apps | logs | traces | APIs |
+------------------------------------------------------------+Use the OSS contracts without the full runtime. Clone a standalone crate repo, or run from this workspace:
# standalone repo (from repo root)
cargo run --example context_snapshot -- --json
cargo run --example basic
cargo run --example standalone
cargo run --features memory --example with_memory
# this workspace
cargo run -p cel-context --example context_snapshot -- --json
cargo run -p cel-memory --example basic
cargo run -p cel-memory-sqlite --example basic
cargo run -p cel-brief --example standalone
cargo run -p cel-brief --features memory --example with_memoryFor a guided path, read docs/quickstart.md.
The top-level examples are organized by job-to-be-done:
examples/merge-context — emit or capture multiple sources into one ContextSnapshot.
examples/memory-provider — store and retrieve memory through the MemoryProvider trait.
examples/build-brief — build a governed prompt bundle and inspect its receipt.
examples/receipt-inspection — understand action and brief receipts.
examples/context-to-brief — connect context, memory, and brief assembly end-to-end.
Open CEL provides the contracts. Cellar/Dilipod operates those contracts in a live environment:
Open CEL | Commercial Cellar/Dilipod |
Context schema and merge contracts | Live cortex runtime |
Memory and SQLite backend | Policy enforcement and approvals |
Brief assembly and brief receipts | Monitoring, alerting, audit timeline |
Receipt and transport schemas | Compliance exports and hosted workers |
See docs/oss-boundary.md and docs/commercial-model.md.
Open CEL crates and docs are Apache-2.0 unless a subdirectory states otherwise.
Execute actions on the screen: mouse clicks, keyboard input, accessibility actions, drag & drop, and direct value setting. Always use cel_see first to understand the screen.
For click/move: provide (x, y) coordinates or a target_ref from cel_see make_reference. For form filling: prefer set_value over type — faster and more reliable. For buttons/checkboxes: prefer ax_action over click — uses native accessibility API.
Coordinate Actions (x,y or target_ref): click, right_click, double_click, mouse_move.
Keyboard: type (text string), key_press (single key: Enter, Tab, Escape, etc.), key_combo (modifier combinations: ['Ctrl','C'], ['Cmd','Shift','S']).
Accessibility API (preferred for reliability): ax_action — native a11y actions on element_id: click, activate, press, increment, decrement, cancel, show_menu, scroll_to_visible, raise, pick, delete. set_value — direct value injection on element_id: text for fields, 'true'/'false' for checkboxes.
Deterministic spreadsheet actions: write_cells (atomic Numbers cell writes with optional readback verification), read_cells (read Numbers cell values from the document model instead of guessing from AX text).
Other: scroll (dx,dy at optional x,y), drag (from_x,from_y to to_x,to_y), cdp_eval (execute JavaScript in browser via CDP — best for cookie banners, iframes, overlays, and elements invisible to the accessibility tree).
Batching: pass array of 1-4 actions for sequential execution (100ms default delay). Re-observe with cel_see after each batch to avoid stale-state cascading failures.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes each action type, mentions deterministic spreadsheet actions, batching with default delay, and warns about stale-state cascading failures. Side effects (UI mutation) are implied, and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with bullet points and sections. It front-loads purpose and general guidance. Some redundancy exists (e.g., repeating 'prefer'), but overall it is organized and earn its detail for the variety of actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the tool returns. Additionally, the input schema is empty, creating a mismatch with the description that implies parameters. The missing return value and schema inconsistency reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is 4 per instructions. The description adds substantial meaning by detailing all action types and their required coordinates, target_ref, element_id, etc., far beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool executes actions on the screen including mouse clicks, keyboard input, accessibility actions, drag & drop, and direct value setting. It also distinguishes itself from siblings by advising to use cel_see first, making its purpose distinct and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Extensive guidelines are provided: always use cel_see first, prefer set_value over type for form filling, prefer ax_action over click for buttons/checkboxes, and detailed recommendations for each action type. Batching and re-observing instructions are also given, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Always-on perception engine (Cortex). Maintains a continuously-updated mental model via background event streams with periodic accessibility tree refreshes on significant changes, and vision/screenshots when flagged as needed.
IMPORTANT: Singleton — only one perception session can be active at a time. cel_see 'watch' mode is unavailable during an active session.
Modes:
start: Boot the cortex with a goal. Set enable_suggestions=true (default) for LLM-powered next-action recommendations on each read.
read: Get the mental model snapshot (instant — model is kept warm by background events).
feed: Report an action you took (action, target, expected outcome). Cortex waits for screen to settle, diffs against current model, returns verification.
checkpoint: Summarize completed work and reset action history. Use between phases of multi-step tasks.
configure: Update goal or enable_suggestions mid-session.
status: Cortex health — confidence score, uptime, cycle count, element counts (stable vs volatile), temporal state (loading, errors, focus trail).
stop: Shutdown the cortex and get a summary.
The model includes temporal awareness (loading states, error persistence, focus trail) and element stability classification (stable vs volatile targets).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the tool is always-on, maintains a background mental model, uses event streams, accessibility refreshes, and optional screenshots. It explains each mode's behavior and side effects (e.g., feed waits for screen settle, diffs model). Minor ambiguity about whether feedback modifies state, but overall highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-organized with a clear mode list and important constraints upfront. Every sentence adds information, though some details could be tightened. Front-loading the singleton note is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers all essential information: purpose, modes, constraints, sibling differentiation, and behavioral model. It is fully adequate for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% documented by schema), so baseline is 4. The description adds value by explaining the modes which act as sub-operations, but no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is an 'always-on perception engine' that maintains a mental model, and explicitly lists all modes (start, read, feed, etc.) with specific verbs and resources. It effectively distinguishes from siblings like cel_see by noting that 'watch' mode is unavailable during active session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode, including when not to use certain modes (e.g., 'cel_see watch mode is unavailable during an active session'). It also highlights the singleton constraint, aiding the agent in choosing this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and observe the current screen state. Returns structured UI elements, window lists, screenshots, CDP page content, accessibility element details, and screen change events. Always use this BEFORE acting to understand what's on screen.
Screen Context: context (elements with filter/compression — use detail 'compact' to save tokens), screenshot (PNG capture), windows (visible window list), monitors (display list).
Element Inspection: focused (high-fidelity detail for one element_id), element_at (hit-test x,y coordinates), is_settable (check if set_value works), make_reference (resilient ref that survives across snapshots), cursor_position.
Browser (CDP): cdp_status (debug targets & connection state), cdp_page (full page content as text).
Observation Recall: observation (load a persisted context snapshot by observation_id).
Waiting & Watching: wait_for_element (poll for element by type/label, default 10s timeout), wait_for_idle (poll until screen stabilizes — requires 2 consecutive stable polls), watch (event-driven — 18 event types: tree_changed, network_idle, focus_changed, value_changed, window_created, menu_opened, menu_closed, sheet_created, layout_changed, title_changed, app_activated, app_deactivated, window_moved, window_resized, window_minimized, window_restored, selection_changed, row_count_changed). Note: watch is unavailable during an active cel_perceive session.
Limits: CDP enrichment caps at 50 text_blocks, 50 interactive_elements, 3000 char body_text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description provides rich behavioral details: default timeout for wait_for_element (10s), requirement for wait_for_idle (2 consecutive stable polls), 18 event types for watch, CDP limits (50 text_blocks, etc.), and conflict note about cel_perceive. This goes far beyond simple annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (Screen Context, Element Inspection, Browser, Observation Recall, Waiting & Watching, Limits). Each sentence adds value, providing necessary detail without redundancy. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists categories of returned data but does not fully specify output structure. However, it covers key aspects like limits and sub-function behaviors. It feels complete for a read tool, though a more structured output spec would be even better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, and the description compensates by thoroughly explaining all the tool's sub-functions (Screen Context, Element Inspection, etc.). According to guidelines, 0 params = baseline 4; this description exceeds that with detailed breakdown of capabilities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Read and observe the current screen state' and lists many capabilities. It distinguishes from siblings by saying 'Always use this BEFORE acting', making clear this is the observation tool while cel_act is for actions and cel_perceive for perception.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage advice: 'Always use this BEFORE acting'. It also notes a limitation (watch unavailable during cel_perceive session). However, it does not explicitly state when not to use or provide direct comparison with cel_perceive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CEL's cognitive layer: delegated autonomy, planning, knowledge, run tracking, and LLM passthrough.
Efficiency rule: if the MCP host already reasons well step-by-step, prefer cel_see + cel_act and keep planning in the host. Use run_goal only when you intentionally want CEL to take over the control loop.
Delegated Autonomous Execution: run_goal — give a natural language goal, CEL runs a full internal see→plan→act loop autonomously. This can be convenient, but it adds an internal planner loop and may be slower or more expensive than host-driven execution. Only goal, max_steps (default 80), and timeout_ms (default 900_000) are tunable — vision, self-healing, decomposition, and notebook are implicit in the canonical loop and no longer per-invocation knobs (see docs/canonical-agent-plan.md).
Planning: plan (LLM-powered step planning with optional history for multi-step context), plan_with_vision (plan with screenshot — use for visual/spatial tasks).
Knowledge Store (persisted to ~/.cellar/cel-store.db): store_knowledge (save facts with source and optional tags), search_knowledge (FTS5 full-text search, default 10 results, scope by workflow).
Working Memory: memory_get, memory_set (per-workflow scratchpad, not persisted across sessions).
Observations: observe (record insight with priority high/medium/low), get_observations (retrieve, default 50).
Run Tracking: run_start, run_finish, run_log_step (per-step with confidence score), run_history, run_steps.
LLM Passthrough: llm_complete (text, 4096 tokens default), llm_complete_with_image (vision, 4096 tokens default).
Maintenance: eviction (TTL cleanup — default 90 days runs, 365 days knowledge).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details many capabilities but fails to disclose what happens on invocation without arguments. No annotations are provided to clarify behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and poorly structured, lacking front-loading. It lists many sub-functions without clear organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the described features and the lack of parameters or output schema, the description is incomplete for an agent to know how to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema-description coverage is 100%. No parameter semantics are needed, baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists many sub-operations but does not state what the tool does when invoked with no parameters. The purpose is vague and ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes efficiency guidance preferring cel_see+cel_act in some cases, but does not clarify how to invoke any of the listed sub-operations since the tool takes no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cel_actcel_perceivecel_seecel_thinkScored across 4 tools
Each tool has a distinct role: cel_act for executing actions, cel_perceive for continuous perception, cel_see for reading screen state, and cel_think for cognitive planning. Descriptions clarify boundaries despite some perceptual overlap.
All tool names follow the consistent pattern 'cel_verb' (act, perceive, see, think), using lowercase with underscores throughout. No deviations or mixed conventions.
With only 4 tools, the set is compact but each encapsulates many sub-operations via parameters and modes. The count is slightly low but appropriate for the server's focused domain of screen automation and perception.
The tools cover perception, action, and cognitive planning comprehensively for UI automation. Minor gaps exist (e.g., no explicit system-level operations), but core workflows are well supported and no obvious dead ends.
Melaya is a remote MCP server. It gives an assistant hands on your own Android phone and browser: it reads the screen through the accessibility tree, then taps, types and navigates inside the apps and sites you allow-list, with no per-app API. It also builds, schedules and runs agent pipelines across 6k+ connected tools. OAuth 2.1, nothing to install.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
