| startupA | Start the openclaw-brain agent. Must be called before other tools. |
| shutdownA | Shut down the openclaw-brain agent. |
| ingest_pdfA | Ingest a PDF document into the knowledge graph. Extracts concepts, equations, and parameters, matches them against
existing knowledge, reasons about relationships, and commits changes.
Args:
file_path: Absolute path to the PDF file.
extraction_model: Model name for extraction (optional, uses default).
reasoning_model: Model name for reasoning (optional, uses default).
Returns:
Summary of ingestion results.
|
| analyze_circuit_imageA | Analyze a circuit schematic (or any technical image) using VLM + knowledge graph. Workflow:
1. Classifies the image (circuit, plot, block_diagram, layout, etc.)
2. Extracts circuit topology, components, signal flow, and design features
using the frontier vision model (e.g. grok-4.20).
3. Cross-references the extracted description against the knowledge graph
(Razavi, ingested papers) to surface related concepts, equations,
principles, and open hypotheses.
Use this when a user sends a circuit schematic and wants engineering insights
grounded in the knowledge base — NOT for ingesting the circuit as new knowledge.
For PDFs/papers to be stored permanently, use ingest_pdf() instead.
Args:
image_path: Absolute path to the image file (PNG, JPG, etc.).
Typically the Telegram download path on disk.
Returns:
Formatted text with: figure type, visual analysis, and knowledge context.
|
| query_knowledgeA | Query the knowledge graph and memory for relevant information. Searches both the Neo4j knowledge graph and the memory system.
Args:
query: Natural language query (e.g., "MOSFET amplifier gain").
Returns:
JSON envelope:
context — human-readable markdown of concepts/edges/memories
concepts — [{id, name, confidence, layer, domain, cite}] —
pass these ids to
record_hypothesis(related_concepts=[...]),
record_decision, reinforce_concept, etc.
Each concept carries cite.level — 'chunk' claims can
be verified verbatim via get_evidence(chunk_id);
when you use a 'derived' item in an answer, label
that part of your answer as derived/unverified.
open_hypotheses — [{id, statement, status, confidence}] — ids usable
in record_bench_result(tests_hypothesis=...) and
record_decision(motivated_by=[...])
active_decisions — [{id, choice, status}]
|
| answer_questionA | Answer a question grounded in the knowledge graph, with citations. Cited chunk ids are verifiable via get_evidence(chunk_id). Returned concepts
contain ids that feed the design-reasoning write tools for hypotheses and
decisions. If the context is insufficient, returns a clean abstention.
|
| get_evidenceA | Read SourceChunk evidence for citation verification. citation 검증용 — query_knowledge가 준 chunk id의 원문 열람.
Args:
chunk_id: SourceChunk ID returned by query_knowledge context/citations.
Returns:
JSON evidence payload with chunk_id, source_id, text, verbatim,
section_title, and pages.
|
| recall_memoryA | Search memories only (without knowledge graph). Useful for recalling past conversations, lessons, or facts.
Args:
query: What to search for in memories.
Returns:
Matching memories formatted as text.
|
| reinforce_conceptA | Strengthen a concept's confidence in the knowledge graph. Call this when a concept is confirmed during conversation,
or when new evidence supports an existing concept.
Args:
concept_id: The concept ID to reinforce.
evidence: Description of the confirming evidence.
Returns:
Confirmation message.
|
| find_bridgesA | Find potential cross-domain connections in the knowledge graph. Discovers concept pairs in different domains that share neighbors
but aren't directly connected — candidates for new insights.
Args:
limit: Maximum number of bridges to return.
Returns:
List of potential cross-domain bridges.
|
| start_sessionA | Start a new episodic memory session. Events recorded during the session are linked together and can
be summarized at session end.
Args:
session_id: Optional custom session ID.
Returns:
The session ID.
|
| end_sessionB | End the current session with an optional summary. Args:
summary: Brief summary of what happened in the session.
Returns:
Confirmation.
|
| record_eventA | Record an event in the current session. Args:
event_type: Type of event (user_message, agent_response, observation, etc.).
content: The event content.
Returns:
The memory ID of the recorded event.
|
| upsert_entityB | Create or update a semantic entity (person, project, tool, etc.). Args:
entity_id: Unique ID for the entity.
entity_type: Type (person, project, tool, system, concept).
name: Display name.
summary: Brief description.
Returns:
The entity ID.
|
| record_lessonB | Record a durable lesson learned. Lessons are stored as curated semantic memories that persist
across sessions.
Args:
lesson: The lesson text.
tags: Comma-separated tags (optional).
Returns:
The memory ID.
|
| run_maintenanceA | Run maintenance tasks: memory promotion and confidence decay. Should be called periodically (e.g., daily) to keep the
knowledge graph and memory system healthy.
Returns:
Summary of maintenance actions.
|
| get_statsA | Get system-wide statistics. Returns node counts, memory stats, reinforcement metrics,
available skills, and configured models. |
| route_and_executeA | Route a natural language input to the best matching skill. The agent analyzes the input, selects the most appropriate skill,
and executes it automatically.
Args:
user_input: Natural language instruction.
Returns:
Execution result or fallback message.
|
| get_pipeline_configA | Get the current pipeline configuration: stage models, fallback chains, and model catalog. Returns a human-readable summary of:
- Default model for each pipeline stage (extraction, reasoning, matching)
- Fallback chain for each stage
- Available models in the catalog
- Resilience settings (retry, backoff)
No arguments needed. Call startup() first.
|
| update_stage_modelA | Change the default LLM model for a pipeline stage. The model must exist in the catalog. Changes are applied immediately
(in-memory) and persisted to config/default.toml.
Args:
stage: Pipeline stage — "extraction", "reasoning", or "matching".
model_name: Name of a model from the catalog (e.g. "claude-opus-4-6", "gpt-5.4").
Returns:
Confirmation of the change.
|
| update_fallback_chainA | Set the fallback chain for a pipeline stage. When the primary model fails (after retries), the system tries each
fallback in order. All models must exist in the catalog.
Args:
stage: Pipeline stage — "extraction", "reasoning", or "matching".
models: Comma-separated model names in fallback order
(e.g. "gpt-5.4, minimax-m2.5"). Empty string clears the chain.
Returns:
Confirmation with the new chain.
|
| add_catalog_modelA | Add a new model to the catalog. Once added, the model can be used as a stage default or in fallback chains.
Args:
name: Short name for the model (e.g. "gpt-5.4", "llama-70b").
provider: "anthropic", "openai", "google", or "local".
model_id: The actual model ID for the API (e.g. "gpt-5.4", "claude-opus-4-6-20250514").
tier: "frontier", "fast", or "local".
endpoint: API endpoint URL (required for "local" provider, e.g. "http://localhost:8000/v1").
Returns:
Confirmation with the updated catalog.
|
| remove_catalog_modelA | Remove a model from the catalog. Cannot remove a model that is currently set as a stage default
or in a fallback chain.
Args:
name: Name of the model to remove.
Returns:
Confirmation or error if model is in use.
|
| record_hypothesisA | Record a testable hypothesis about a circuit or design issue. Hypotheses are tracked in the knowledge graph and can be confirmed
or falsified by bench results. Use this when exploring root causes,
predicting behavior, or proposing explanations.
Args:
statement: The hypothesis (e.g., "Body effect causes Vth shift > 50mV at SS-cold").
assumptions: Comma-separated assumptions underlying this hypothesis.
test_plan: How to verify this hypothesis via simulation or measurement.
related_concepts: Comma-separated concept IDs to link to.
Returns:
The hypothesis ID.
|
| record_decisionA | Record a design decision with rationale, alternatives, and constraints. Captures WHY a particular design choice was made, what was considered,
and under what constraints. Enables re-evaluation when specs change.
Args:
choice: The selected design choice (e.g., "Folded cascode OTA").
alternatives: Comma-separated alternatives considered.
rationale: Why this choice was made.
constraints: Comma-separated constraints (e.g., "VDD=1.2V, area<100um2").
related_concepts: Comma-separated concept IDs this decision applies to.
motivated_by: Comma-separated hypothesis IDs that motivated this decision.
Returns:
The decision ID.
|
| record_bench_resultA | Record a simulation or measurement result, optionally confirming/falsifying a hypothesis. Links bench results to hypotheses to close the hypothesis→bench→feedback loop.
When a hypothesis is tested, its status is automatically updated.
Args:
setup: Testbench setup description (e.g., "CS amp, W/L=10/0.18, VDD=1.8V").
metric: Measured results (e.g., "gain=22dB, BW=150MHz").
conclusion: What this result means.
bench_type: "simulation", "measurement", or "calculation".
corner: Process/temperature corner (e.g., "SS -40C").
tests_hypothesis: Hypothesis ID to confirm or falsify (optional).
confirms: True if the result confirms the hypothesis, False if it falsifies.
Returns:
The bench result ID.
|
| list_open_hypothesesA | List all open (unresolved) hypotheses, ordered by confidence. Use this to review pending hypotheses that need bench verification,
or to find hypotheses related to a current issue.
Args:
limit: Maximum number of hypotheses to return.
Returns:
JSON list of open hypotheses with linked concepts.
|
| merge_conceptsA | Merge a duplicate concept node into the primary, re-wiring all edges. Use when the LLM extracted the same concept twice with slightly different names
(e.g. "MOSFET" and "MOSFET Transistor") and you want to consolidate them.
Steps performed automatically:
1. Gap-fill: properties present on duplicate but absent on primary are copied.
2. All outgoing edges from duplicate are re-created on primary (idempotent MERGE).
3. All incoming edges to duplicate are re-pointed to primary (idempotent MERGE).
4. Duplicate node is permanently deleted.
To find candidates: use query_knowledge to search for near-duplicate concepts,
or check find_bridges for concepts that reference each other indirectly.
Args:
primary_id: concept_id of the node to keep (the canonical one).
duplicate_id: concept_id of the node to absorb and delete.
Returns:
JSON summary with rewired edge counts and deletion confirmation.
|
| retract_nodeA | Retract (soft-delete or hard-delete) a knowledge node. Use when a node was incorrectly extracted, is factually wrong, or is
a hallucination that slipped through grounding checks.
Soft delete (default, hard_delete=false):
Sets retracted=true on the node. It remains in the graph for audit purposes
but is excluded from all searches, retrieval, and concept matching.
Recoverable: set retracted=false manually if needed.
Hard delete (hard_delete=true):
Permanently removes the node and ALL its edges. Irreversible.
Use only for nodes with zero useful relationships.
Supported labels: Concept, Equation, Principle, CircuitTopology, Parameter,
Assumption, Insight, Hypothesis, DesignDecision, BenchResult.
Args:
node_id: The ID value (e.g. the concept_id, equation_id, etc.).
label: Node type — "Concept", "Equation", "Parameter", etc.
reason: Human-readable reason (stored on the node for audit trail).
hard_delete: If True, permanently delete. Default: False (soft-delete).
Returns:
JSON with action taken and whether the node was found.
|
| export_obsidianA | Export the knowledge graph to an Obsidian vault as Markdown files. Each concept, equation, principle, etc. becomes a note with YAML
frontmatter and [[wikilinks]] for relationships. Open the vault in
Obsidian to browse and visualize the graph.
Args:
vault_path: Path to the Obsidian vault directory.
Defaults to ~/Semiconductor.
Returns:
Summary of exported nodes.
|
| query_executableA | Read the executable-circuit substrate: simulation-VERIFIED circuit specimens and their
claim-cards. Each claim-card is a falsifiable mechanism claim whose verdict was produced by a
DETERMINISTIC oracle re-running a real ngspice simulation (sky130 PDK) under stated R1
conditions (corner/temp/vdd). This is the evidence layer for teaching: the QUANT assertion
(direction / elasticity / invariance / value) is oracle-certified; the mechanism NARRATIVE is
interpretive and must NOT be taught as oracle-certified fact. Specimens link into the
knowledge graph (REALIZES a CircuitTopology, GROUNDS a Parameter). Args:
topology_class: restrict to one class (e.g. "miller_ota_2stage_nmos_in"), or "" for all.
Returns:
JSON {topology_class, count, specimens:[{spec_id, topology_class, realizes, pdk, tool,
claims:[{claim, knob, metric, verdict, narrative, conditions:{corner,temp_c,vdd},
grounds}]}]}.
|
| project_executableA | Build + project the validated executable-circuit specimens (two-stage Miller OTA, simple
NMOS current mirror) onto the knowledge graph. Runs REAL ngspice (sky130) to produce
verdicted specimens, then ADDS Specimen/ClaimCard nodes + REALIZES/GROUNDS links to existing
graph nodes — additive (existing nodes never modified) and NO-PHANTOM (a link forms only to a
resolved existing node). LONG-RUNNING: simulations take minutes. Dry-run by default
(apply=False simulates + reports verdicts but writes nothing); apply=True writes. Args:
apply: True to write the projection; False (default) for a dry-run preview.
Returns:
JSON {apply, specimens:[{topology_class, spec_id, verdicts:{claim_id: verdict},
written?:{nodes, internal_edges, links_resolved, links_total}}]}.
|
| retract_executableA | Reverse a project_executable apply: DETACH DELETE the Specimen + its ClaimCards (and their
REALIZES / HAS_CLAIM / GROUNDS edges) for one spec_id. The existing graph nodes the links
pointed at are untouched. Use this to undo a bad projection. Args:
spec_id: the content-hash id of the specimen to retract (from query_executable).
Returns:
JSON {spec_id, specimens, claim_cards} — counts of nodes deleted.
|
| whyA | Grounding for one executable-substrate claim-card — the evidence behind a citation. Use it
to inspect (or cite) a specific sim-verdicted claim. Remember the boundary: the claim's QUANT
verdict is oracle-certified, but its narrative is interpretive (a mechanism the engineer
narrates, NEVER an oracle-certified fact). Args:
claim_card_id: the id from query_executable, format {spec_id}:{claim}.
Returns:
JSON {claim_card_id, found, claim, knob, metric, verdict, narrative, grounds,
conditions:{corner,temp_c,vdd}, spec_id, topology_class}.
|
| audit_citationsA | Advisory self-check for a lesson before you teach it. Submit your LessonPlan and this
verifies the ONE boundary that matters: a claim you marked tier="certified" must cite an
existing certified claim-card (so you never present a simulation-verified number you don't
actually have), and every claim must carry a tier label (so an interpretive mechanism is
never disguised as certified fact). It is NOT a hard gate and judges nothing else — your
lesson's structure, ordering, depth, and selection are entirely yours. Args:
lesson_plan_json: JSON of {topology_class, spec_id?, title?, claims:[{text, tier:
"certified"|"interpretive", cites: claim_card_id (required when certified)}]}.
Returns:
JSON AuditReport {passed, certified_total, certified_ok, interpretive_total,
findings:[{index, ok, reason}]}.
|
