Skip to main content
Glama

Show the workspace picker

well_show_workspace_picker
Read-only

Ask the user WHICH workspace to work in, on a card: one tile per authorized workspace, with its logo and the company behind it.

⚠️ ONLY when the token authorizes SEVERAL workspaces and no hint resolves to one. Every other case is yours to settle with well_list_workspaces, which draws nothing: exactly one workspace in the grant, a name or company the user already named, a pin this conversation itself wrote, or no workspace at all. A chooser over a set of one asks nothing, and a chooser you could have answered yourself asks the reader a question you already know the answer to.

⚠️ WAIT ON THE CARD IN THE TURN THAT DREW IT. Write your one line for the user FIRST — the wait holds the turn open for up to a minute, and a user looking at a card with no sentence beside it has been given no reason to click — then call well_wait_for_selection({ kind: "workspace" }), which this result's next_step also states. The click writes the pin server-side, so never follow it with well_switch_workspace.

⚠️ NEVER DEFAULT TO THE PRIMARY WORKSPACE on the user's behalf, and do not restate the workspaces in text under the card.

⚠️ WRITE reply IN THE USER'S LANGUAGE, WITH {picked} WHERE THE WORKSPACE NAME BELONGS. A click sends that sentence into the conversation as the person's own message, and the card puts the workspace they actually picked in place of the placeholder. A sentence left unwritten sends English to a reader who is not writing in English; a sentence that names a workspace itself is refused, because you are writing it before they have chosen.

The rows are the rows of well_list_workspaces, field for field. Its description carries the field reference, and this description does not repeat it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
replyNoOne sentence, IN THE LANGUAGE THE USER IS WRITING IN, that the click sends into the conversation as their own message. Write what the PERSON would say about the workspace they pick, in their words, not an instruction to yourself. You write it BEFORE they click, so you cannot know what they will choose: put {picked} where the pick belongs and the card replaces it with the names they actually picked, one or several. In English it would read "Let's work on {picked}." Write the same shape in the user's language. {picked} is required: a sentence that names a pick itself names the one you guessed, so the card refuses it and sends its own English instead. At most 160 characters. Omitted sends an English sentence the card builds itself, which is wrong for any reader not writing in English.
titleNoHeading for the picker card, framing the step in its flow (e.g. "Which company are we closing?"). At most 120 characters. Omit to keep the default wording; an empty string is rejected rather than rendered as a blank heading.
subtitleNoSupporting line under the picker card's heading. At most 240 characters. Omit to keep the default wording; an empty string is rejected rather than rendered blank.
workspace_idNoTarget workspace. Optional: this tool describes the token itself rather than one workspace's data, so omitting it returns the same answer.
workspace_idsNoScope the tiles to this subset of the authorized workspaces, e.g. the company workspaces under one membership. Every id must be one this token authorizes; an id outside the grant refuses the call. Omit to draw every authorized workspace.
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
sessionNoWhat this conversation's card clicks recorded so far; null/empty fields when nothing was clicked yet.
successYes
next_stepNoWhat to do with the card this result renders. Added by the dispatcher when the card asks for a click.
workspacesYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "The 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.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_note
      Added value: +{
      +  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_source
      Added value: +{
      +  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
      +  "enum": [
      +    "host_meta",
      +    "argument",
      +    "minted"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / session / description
      Previous value: -"What this session's card clicks recorded so far; null/empty fields when nothing was clicked yet."New value: +"What this conversation's card clicks recorded so far; null/empty fields when nothing was clicked yet."
  2. Changed10 schema fields changed
    • addedInput schema / properties / reply
      Added value: +{
      +  "description": "One sentence, IN THE LANGUAGE THE USER IS WRITING IN, that the click sends into the conversation as their own message. Write what the PERSON would say about the workspace they pick, in their words, not an instruction to yourself. You write it BEFORE they click, so you cannot know what they will choose: put {picked} where the pick belongs and the card replaces it with the names they actually picked, one or several. In English it would read \"Let's work on {picked}.\" Write the same shape in the user's language. {picked} is required: a sentence that names a pick itself names the one you guessed, so the card refuses it and sends its own English instead. At most 160 characters. Omitted sends an English sentence the card builds itself, which is wrong for any reader not writing in English.",
      +  "maxLength": 160,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / subtitle
      Added value: +{
      +  "description": "Supporting line under the picker card's heading. At most 240 characters. Omit to keep the default wording; an empty string is rejected rather than rendered blank.",
      +  "maxLength": 240,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / title
      Added value: +{
      +  "description": "Heading for the picker card, framing the step in its flow (e.g. \"Which company are we closing?\"). At most 120 characters. Omit to keep the default wording; an empty string is rejected rather than rendered as a blank heading.",
      +  "maxLength": 120,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / workspace_ids
      Added value: +{
      +  "description": "Scope the tiles to this subset of the authorized workspaces, e.g. the company workspaces under one membership. Every id must be one this token authorizes; an id outside the grant refuses the call. Omit to draw every authorized workspace.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "minItems": 1,
      +  "type": "array"
      +}
    • addedOutput schema / properties / workspaces / items / properties / identity / properties / country_default_fiscal_year_start_month
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The jurisdiction's default fiscal-year-start month for this country, or null when the country has no single confident default (non-null for France only today)."
      +}
    • addedOutput schema / properties / workspaces / items / properties / identity / properties / fiscal_year_start_month_source
      Added value: +{
      +  "anyOf": [
      +    {
      +      "enum": [
      +        "derived",
      +        "registry",
      +        "user"
      +      ],
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Where fiscal_year_start_month came from: \"registry\" from a company registry, \"derived\" from the country fallback, \"user\" from a human. Null when never set. Tells a confirmed fiscal year from one resting on a default."
      +}
    • changedOutput schema / properties / workspaces / items / properties / identity / required
      Previous value: -[
      -  "registered_name",
      -  "trade_name",
      -  "registered_value",
      -  "country",
      -  "domain",
      -  "base_currency",
      -  "fiscal_year_start_month"
      -]New value: +[
      +  "registered_name",
      +  "trade_name",
      +  "registered_value",
      +  "country",
      +  "domain",
      +  "base_currency",
      +  "fiscal_year_start_month",
      +  "fiscal_year_start_month_source",
      +  "country_default_fiscal_year_start_month"
      +]
    • addedOutput schema / properties / workspaces / items / properties / lineage_parent_workspace_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The workspace_id of the membership this workspace was created under, or null when it has no active lineage. Its parent's own row is the membership whose id this points at."
      +}
    • addedOutput schema / properties / workspaces / items / properties / own_company_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "The public id of the company this workspace is anchored to, or null. A row that carries it is a company workspace, the one the close flow runs in; a row without it is a membership workspace."
      +}
    • changedOutput schema / properties / workspaces / items / required
      Previous value: -[
      -  "workspace_id",
      -  "workspace_name",
      -  "is_primary",
      -  "has_bank_transactions",
      -  "identity"
      -]New value: +[
      +  "workspace_id",
      +  "workspace_name",
      +  "is_primary",
      +  "own_company_id",
      +  "lineage_parent_workspace_id",
      +  "has_bank_transactions",
      +  "identity"
      +]
  3. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say read-only and non-destructive; the description adds substantial behavior: the card waits up to a minute, the click writes a pin server-side, no primary workspace default, no restating tiles, and refusal of a reply that names a pick. This is exactly the kind of context annotations cannot convey.

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 main purpose is front-loaded in one sentence, and the warning blocks are scannable and each cover a distinct trap: usage condition, waiting, no default, reply language, and data source. While long, the length is earned by the interactive card flow and the number of high-cost mistakes it prevents.

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 an interactive picker tool with an output schema and complete parameter schemas, the description supplies every piece of orchestration an agent needs: when to draw the card, how to wait for the selection, what not to do afterward, and how to write the reply. There are no obvious missing behavioral or usage details.

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?

Parameter descriptions in the schema already cover 100% of fields in detail, including the reply language, {picked} placeholder, max lengths, and conversation_id behavior. The description mostly reinforces the reply rule already present in the schema, so the baseline of 3 is appropriate; the row-definition handoff to well_list_workspaces is useful but does not add parameter-level semantics.

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 opening sentence states a specific action and resource: 'Ask the user WHICH workspace to work in, on a card'. It also distinguishes itself from well_list_workspaces by specifying that it applies only when several workspaces are authorized and no hint resolves to one.

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?

The description explicitly gives the only condition for use ('ONLY when the token authorizes SEVERAL workspaces and no hint resolves to one') and names well_list_workspaces for every other case. It also directs the agent to call well_wait_for_selection and never well_switch_workspace after the click.

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