Skip to main content
Glama

notion_switch_workspace

Switch the active Notion window to another workspace or account by name, then return to the original after completing tasks.

Instructions

Switch the Notion window to another workspace/account by name. Tell the user, and switch back when done.

Input Schema

NameRequiredDescriptionDefault
nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full load. It does disclose a meaningful behavioral trait — this mutates shared UI/session state and the agent is expected to notify the user and restore the prior workspace. It says nothing about what happens if the name is unknown, whether credentials/session change, or how subsequent calls are affected.

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?

Two short sentences, front-loaded with the action and followed by the workflow obligation. Nothing is padded, though 'switch back when done' is slightly vague about what 'done' means.

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

Completeness3/5

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

With no annotations, no output schema, and an undocumented parameter, the description covers the core action and the restore obligation but omits failure behavior and side effects on the session. For a state-changing tool this leaves real gaps an agent would want filled.

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?

One required parameter ('name') with 0% schema description coverage, so the schema contributes nothing. The description clarifies that the value is a workspace/account name, which is genuinely useful, but gives no format, casing, matching rules, or example.

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

Purpose4/5

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

States a specific verb and resource: 'Switch the Notion window to another workspace/account by name.' That is clear and distinct from all listed siblings (launch, open, read, etc.), none of which change workspace context. It stops short of explicitly naming a sibling it differs from, so a 4 rather than a 5.

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

Usage Guidelines3/5

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

The description implies when this is needed (when work must happen in a different workspace/account) and adds a lifecycle instruction: tell the user, and switch back when done. But it names no alternative tool and gives no precondition or failure guidance, so usage is only implied.

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