Skip to main content
Glama

Change a saved browser task

well_update_browser_skill

Change one of the user's own saved browser tasks: rename it, change its steps, move its start page within the same site, or unpublish it (status "draft") and publish it again (status "published"). Call it when the user asks to edit, rename, unpublish or republish a saved task ("modifie ma tâche relevé Banque A : prends aussi le PDF", "unpublish Supplier A invoices"), with the browser_skill_id that well_list_browser_skills gave. When no list was read in this conversation, call well_list_browser_skills first; when several saved tasks could match, ask which one as a numbered list.

Pass only what changes. A new name, new steps or a new start page make a new version, and the earlier version stays in the history. Unpublishing keeps the task and its versions; the person can no longer rerun it in one word until it is published again.

A saved task always stays on its site: a start page on another site, or another subdomain, is refused, and nothing changes. To run a task on another site, the person saves a new task from a run there. Its inputs come from the run it was saved from and cannot change here. Deleting is well_delete_browser_skill.

The result has the saved task's name, its version and its status: say what changed in one line, with the version, and never show the id. A refusal means nothing changed: say so in one line, and do not retry.

Input Schema

NameRequiredDescriptionDefault
nameNoThe new name, on one line. Omit it to keep the name.
statusNo"draft" unpublishes the saved task, "published" publishes it again. Omit it to keep the status.
start_urlNoThe new start page, an https page of the same site. Omit it to keep the start page.
instructionsNoThe new steps of the saved task, in full, as the person asked. Omit them to keep the steps.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.
browser_skill_idYesThe saved task to change, as well_list_browser_skills returned its id.

Output Schema

NameRequiredDescriptionDefault
codeNo
nameNoThe saved task's name after the change.
errorNo
statusNopublished or draft, after the change.
successYes
versionNoThe saved task's version after the change.
reply_linesNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
near_candidatesNo
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
browser_skill_idNo
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
near_candidates_truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / code
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / near_candidates
      Added value: +{
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "company_id": {
      +        "type": "string"
      +      },
      +      "name": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "company_id",
      +      "name"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / near_candidates_truncated
      Added value: +{
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / reply_lines
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations: new name/steps/start page create a new version while the earlier one stays in history, unpublishing retains task and versions but blocks one-word reruns, cross-site or subdomain start pages are refused with nothing changed, inputs inherited from the originating run are immutable, and refusals must not be retried. This is exactly the non-obvious behaviour an agent needs for a mutation that annotations only label as non-destructive.

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 with purpose and trigger phrases, then constraints, then result-handling instructions. Dense but long (five paragraphs, bilingual example utterances); every paragraph carries distinct information, though the versioning and unpublish-retention points are each restated slightly.

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?

Covers triggers, prerequisite lookup, field-level mutation semantics, refusal behaviour, and response handling (report in one line with the version, never surface the id). With an output schema present and 9 parameters at full coverage, nothing an agent needs to invoke this correctly 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; the description still adds meaning by stating "Pass only what changes" (omit-to-keep semantics across fields), tying status "draft"/"published" to unpublish/republish, and constraining start_url to the same site/subdomain — a rule the schema only gestures at with "an https page of the same site".

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?

Opens with a specific verb and resource ("Change one of the user's own saved browser tasks") and enumerates the exact mutation surface: rename, change steps, move start page within the same site, unpublish/republish. No sibling update tool overlaps, and it explicitly separates delete (well_delete_browser_skill) from update.

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?

States when to call it with two concrete user utterances, names the prerequisite source of browser_skill_id (well_list_browser_skills), tells the agent to call the list first if none was read in this conversation, and instructs to disambiguate with a numbered list when several tasks match. Routes deletion to well_delete_browser_skill.

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