Skip to main content
Glama

agent_workspace

Manage LINZA workflows by inspecting workspace, ingesting artifacts, reviewing supervised items, explaining connections, searching memory, exporting context, or running diagnostics with dry-run preview.

Instructions

Main LINZA workflow facade. Choose one action to inspect the workspace, ingest artifacts, review/apply supervised items, explain connections, search memory, export context, or run diagnostics. Safe actions are read-only; apply actions preview by default with dry_run=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesWorkflow action. Setup: doctor, map. Review/growth: teach, grow, review_next, apply_review_items, history, revoke_approval. Artifact flow: ingest_artifacts, analyze_inbox. Graph/context: connect, search_memory, export_context. Trace calibration: record_trace, analyze_trace, review_calibr.
artifactsNoArtifact inputs for ingest_artifacts; each item may include text/content, path/source_uri, title, and metadata.
traceNoAgent trace payload for record_trace; stored as structured sidecar evidence, not raw chain-of-thought.
trace_idNoTrace identifier used by analyze_trace and review_calibr.
source_kindNoOptional artifact/source filter such as chat, document, note, log, web_article, or trace.
batch_idNoOptional batch identifier for grouping ingested artifacts or review intents.
privacyNoPrivacy label stored with artifacts/traces; default private.private
kindNoReview item kind filter for review/history actions; use all for no filter.all
modeNoGrowth mode for grow; default assisted.assisted
item_idsNoStable review intent IDs to preview/apply with apply_review_items.
approval_idNoExisting approval row ID for revoke_approval.
reasonNoReason recorded when revoking an approval or applying a reviewed action.
include_revokedNoInclude revoked approvals in history results.
dry_runNoPreview apply/revoke actions without writing active sidecar changes; default true.
allow_overwriteNoAllow reviewed YAML/frontmatter writes where supported; source note bodies are still protected by LINZA policy.
include_memoryNoInclude memory candidates in teach/grow/review workflows.
sourceNoSource note/path/query endpoint for connect.
targetNoTarget note/path endpoint for connect.
max_depthNoMaximum graph depth for connection/path exploration.
max_notesNoMaximum notes to sample when building workspace maps or growth candidates.
max_domainsNoMaximum domain groups to build in map/growth workflows.
queryNoSearch query for search_memory and export_context.
limitNoMaximum items/cards/results to return for the selected action.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint=false, destructiveHint=false) are general; the description adds specific behavioral context: safe actions are read-only, apply actions default to dry_run=true. This goes beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: purpose, action selection guidance, and safety note. It is front-loaded, concise, and contains no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (23 parameters, many actions), the description is fairly complete. It covers the general workflow and safety. However, it does not mention return values or error handling, which would be useful given the lack of output schema.

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?

Schema coverage is 100% for all 23 parameters, so the description does not need to add per-parameter detail. The description groups actions (e.g., 'Setup: doctor, map') which adds some semantic value, but no additional parameter semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is the 'Main LINZA workflow facade' and enumerates categories of actions (inspect workspace, ingest artifacts, review/apply, etc.), making the purpose explicit. It distinguishes from sibling tools which are more specific (e.g., read_file, search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description instructs to 'Choose one action' and lists action groups, implying when to use it. It also notes that safe actions are read-only and apply actions preview with dry_run=true. While it doesn't explicitly state when not to use it, the sibling list provides alternatives.

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/Semiotronika/LINZA-MCP'

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