Skip to main content
Glama

CEL Think

cel_think

Performs cognitive reasoning to analyze observations and plan subsequent actions, forming the thinking component of browser and native app automation.

Instructions

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior2/5

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.

Conciseness2/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose2/5

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.

Usage Guidelines3/5

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.

Install Server

Other Tools

Latest Blog Posts

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/dimpagk92/cellar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server