Skip to main content
Glama
dipseth

google-workspace-unlimited

by dipseth
OverviewSchemaRelated ServersScoreDiscussions
Python

Execute

execute

Run sandboxed Python to chain Google Workspace tool calls via await call_tool, performing real sends, edits, or deletes in one block and returning a final answer.

Instructions

Run sandboxed Python that calls this server's Google Workspace tools via await call_tool(tool_name, params), chaining calls in one block. Use when: you know which tools to call. To find tool names first use search or tags; for exact parameters use get_schema; to look up past results instead, use semantic_search. Behavior: each call_tool runs the real tool immediately — sends, edits, and deletes take effect; there is no dry-run. Use return to produce output; prefer returning the final answer from a single block. Only call_tool(tool_name: str, params: dict) -> Any is available in scope. Unknown tool names raise NotFoundError; disallowed syntax raises SandboxError.

SANDBOX RESTRICTIONS — these produce SandboxError, avoid them:

  • sorted_(items, key=lambda x: x['k']) → lambda args fail; use builtins like key=len or sort manually

  • import only covers a small stdlib subset (e.g. json); no third-party modules — prefer the built-in helpers listed below

Built-in helpers (import is not available — use these instead):

  • now(tz_offset=0) → current datetime string (UTC by default)

  • today(tz_offset=0) → current date 'YYYY-MM-DD' (UTC by default)

  • days_ago(n, tz_offset=0) → ISO datetime string N days ago

  • hours_ago(n, tz_offset=0) → ISO datetime string N hours ago

  • format_date(iso_str, fmt='%Y-%m-%d %H:%M') → formatted date

  • parse_date(iso_str) → normalized ISO datetime

  • timestamp() → current unix timestamp (int)

  • to_json(obj, indent=None) → JSON string

  • from_json(s) → parsed object

  • url_encode(s) → URL-encoded string

  • url_decode(s) → URL-decoded string

  • url_join(base, *parts) → joined URL path

  • query_string(params) → URL query string from dict

  • re_find(pattern, text) → list of matches

  • re_match(pattern, text) → bool

  • re_sub(pattern, repl, text) → substituted string

  • truncate(text, n=80) → truncated with '...'

  • dedent(text) → remove common leading whitespace

  • wrap_text(text, width=72) → word-wrap to width

  • pad_left(s, width, char=' ') → right-justify / zero-pad

  • pad_right(s, width, char=' ') → left-justify

  • join(items, sep=', ') → joined string

  • html_escape(s) → HTML-safe string

  • sqrt(n), ceil(n), floor(n) → math

  • round_(n, digits=2), abs_(), min_(), max_(), sum_() → math

  • sorted_(items, key=None, reverse=False) → sorted list

  • unique(items) → deduplicated list (preserves order)

  • flatten(lists) → flat list from nested lists

  • counter(items) → dict of {item: count}

  • chunk(items, size) → list of chunks

  • zip_(*iterables) → zipped as list of lists

  • dict_get(d, 'a.b.c', default=None) → nested dict access

  • md5(s), sha256(s) → hash hex digests

  • gather_tools(calls) → run multiple tool calls sequentially; calls is a list of [tool_name, params] pairs, returns list of results (assign to variable, then index: r = await gather_tools([...]); a, b = r[0], r[1])

  • sleep(seconds) → async sleep

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesPython async code to execute tool calls via call_tool(name, arguments)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv2.3.2

TDQS

A5/5.0
Behavior5/5

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

There are no annotations, so the description carries the full burden, and it does so thoroughly. It discloses that each call_tool runs the real tool immediately with sends/edits/deletes taking effect and no dry-run, plus sandbox restrictions, error types, and disallowed syntax. This is substantial behavioral context beyond what the schema provides.

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 long but well-structured with clear sections: use-when, behavior, sandbox restrictions, and built-in helpers. Core usage and side effects are front-loaded, and every block provides actionable information rather than filler.

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?

Given that annotations and an output schema are absent, the description is remarkably complete. It covers selection criteria, invocation syntax, execution environment, side effects, error modes, restrictions, and helper APIs, so an agent can use this tool without needing additional documentation.

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

Parameters5/5

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

The schema already describes the single `code` parameter at 100% coverage, but the description adds far more semantic value: valid async syntax, `call_tool` signature, use of `return`, restrictions on `import`, sandbox errors, and a full list of available built-in helpers. This gives the agent everything needed to construct valid code.

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 names a precise verb and resource: running sandboxed Python that calls this server's Google Workspace tools via `await call_tool(tool_name, params)` and chaining calls in one block. It also distinguishes itself clearly from discovery/search siblings by framing this as the execution step once tool names are known.

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?

It gives an explicit 'Use when' condition: when you know which tools to call. It also names alternatives for other cases: `search` or `tags` for finding tool names, `get_schema` for exact parameters, and `semantic_search` for past results, providing clear routing to sibling tools.

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/dipseth/google_workspace_fastmcp2'

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