Skip to main content
Glama

Update Workspace

update_workspace

Use this for structured data. To add an agent-specific operational learning, call append_learning instead.

The app reads inputs: excluded, mailbox, entity_type, discovery_mode, watcher_context, content_calendar, destination; outputs: ideas, drafts, published, digests, insights. Values there must fit the app's shape (a rejected write shows it); for your own data, use another key.

operation='read': Name section and key to get back just that entry; section alone returns that section; neither returns the full workspace ({inputs, outputs}). An entry that was never written comes back as an empty section. The full form re-sends every entry, so name the entry when you know which one you want. operation='update': Requires section, key, and a non-null value. Sets workspace[section][key] = value. operation='append': Requires section, key, and a LIST value. Atomically extends the existing list at workspace[section][key] with value's items (creating it if absent). Use this to accumulate into a list — a digest entry, new calendar topics, freshly-created draft records — without reading, concatenating, and rewriting the whole array yourself (which races other writers). Errors if the current value isn't a list (use 'update' to replace it). operation='delete': Requires section and key. ALWAYS confirm with the user before calling — this is destructive. Shape depends on the operation. On read, {'success': True, 'agent_id': ..., 'workspace': {'inputs': {...}, 'outputs': {...}}}, with 'workspace' holding only the section — or only the one section/key entry — you named. On update or delete, {'success': True, 'agent_id': ..., 'workspace_keys': {'inputs': [...], 'outputs': [...]}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoThe key to set, extend, or delete (required for update/append/delete; optional narrowing for read, where it also needs section)
valueNoValue to store (required for update; must not be None — use operation='delete' to remove a key). Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat. For append, a list of items to add to the existing list.
sectionNoWhich workspace section — 'inputs' or 'outputs' (required for update/append/delete; optional narrowing for read)
agent_idYesID of the agent
operationYes'read', 'update', 'append', or 'delete'
on_behalf_ofNoAn agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / value / description
      Previous value: -"Value to store (required for update; must not be None — use operation='delete' to remove a key).\nFor append, a list of items to add to the existing list."New value: +"Value to store (required for update; must not be None — use operation='delete' to remove a key). Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.\nFor append, a list of items to add to the existing list."
  3. Changed3 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "description": "ID of the agent",
      +  "type": "integer"
      +}
    • removedInput schema / properties / task_id
      Removed value: -{
      -  "description": "ID of the task",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "task_id",
      -  "operation"
      -]New value: +[
      +  "agent_id",
      +  "operation"
      +]
  4. First observed

TDQS

A4.2/5.0
Behavior2/5

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

The description itself is unusually rich: it discloses atomicity of append, the list-type error condition, the non-null requirement for update, the shape of read/update/delete responses, and that delete is destructive. However, it explicitly states delete 'is destructive' while annotations declare destructiveHint=false, a direct inconsistency that misleads an agent about the tool's worst-case behavior. This conflict caps an otherwise excellent disclosure.

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

Conciseness4/5

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

Front-loaded summary followed by per-operation bullets, so it is scannable and information-dense. It is on the long side—the `record_search_results` digression is verbose—but nearly every sentence carries operational value for a four-operation tool.

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

Completeness5/5

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

For a multi-operation tool with no output schema, the description closes the gaps: it documents the return shapes for read/update/delete, the section/key narrowing behavior, and the branch conditions. Schema coverage is 100%, so no parameter meaning is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: `value` must fit the app's shape for known keys (a rejected write reveals it) and outside resources must be named by the identifier their tool takes (spreadsheet ID/tab, URL), not just a title. It also clarifies section/key narrowing semantics for read and the list constraint for append.

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?

Names a specific resource (an agent's workspace entries) and the four verbs it supports (read/update/append/delete), and it distinguishes itself from siblings by naming `record_search_results` (for bulk entity sets) and `append_learning` (for operational learnings). The two-section model (inputs/outputs) is spelled out, so an agent knows exactly what it operates on.

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

Usage Guidelines5/5

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

Explicitly routes the agent: use `record_search_results` for any bulk people/company set (with reasons: dedup, pagination, lifecycle), use `append_learning` for operational learnings, and use this tool for structured data. Per-operation guidance (append for accumulation, update to replace, delete requires confirmation) leaves nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources