mcp-google-workspace

Overview Schema Source Related Servers Discussions Admin

Resolve Workspace Resource

resolve_workspace_resource

Read-onlyIdempotent

Resolve a resource URI from an earlier result into a current handle with refreshed metadata, verifying Drive files and Gmail messages still exist before reuse.

Instructions

Turn a resource URI from an earlier result's resource handle back into a handle with current metadata. Drive files are re-read for a fresh name, mime_type, modified_at (account time zone), web_url and etag, and Gmail messages are checked to still exist; threads, events, contacts and tasks are only parsed, without a Google call. Returns resource and verified (true when Google confirmed the resource exists); pass resource.id to the matching service tool for content.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "uri": "<uri>"
    },
    "name": "resolve_workspace_resource"
  }
}

Input Schema

Name	Required	Description	Default
`uri`	Yes	The uri of a resource handle from an earlier result, e.g. 'gdrive:///<file_id>' or 'gmail-message:///<message_id>'; other schemes are rejected.

Output Schema

Name	Required	Description	Default
`resource`	No
`verified`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv2.1.0Nov 6, 2026

removedInput schema / maxProperties
```
Removed value: -10000
```

changedInput schema / properties / uri / description

Previous value: -"Stable Workspace resource URI previously returned in a tool response's 'resource' field."New value: +"The uri of a resource handle from an earlier result, e.g. 'gdrive:///<file_id>' or 'gmail-message:///<message_id>'; other schemes are rejected."

removedInput schema / properties / uri / maxLength
```
Removed value: -1000000
```
changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```

removedOutput schema / description

Removed value: -"Structured response returned by this MCP tool."

removedOutput schema / properties / next_actions

Removed value: -{
-  "description": "Response field: next actions.",
-  "items": {},
-  "type": "array"
-}

removedOutput schema / properties / resource / description
```
Removed value: -"Response field: resource."
```

removedOutput schema / properties / status

Removed value: -{
-  "description": "Machine-readable operation status.",
-  "type": "string"
-}

addedOutput schema / properties / verified
```
Added value: +{
+  "type": "boolean"
+}
```

removedOutput schema / title

Removed value: -"Resolve Workspace Resource response"

Changed1 schema field changedv0.3.10Aug 8, 2026
- addedOutput schema / properties / resource / type
```
Added value: +"object"
```
First observedv0.3.7Jul 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing per-scheme behavior: Drive files are re-read over the network for fresh name, mime_type, modified_at, web_url and etag, Gmail messages are existence-checked, and threads, events, contacts and tasks are parsed locally with no Google call. It also explains the verified flag's meaning, which is real behavioral context an agent cannot infer elsewhere.

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 sentences, front-loaded with the core operation and then the per-scheme behavioral detail and return values. The first sentence is dense with parallel clauses, but every element (fresh metadata, existence check, no-call cases) carries information the agent needs.

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?

An output schema exists, yet the description still notes the returned resource and verified fields, and it fully covers the tricky part of a single-parameter tool: how behavior varies by URI scheme. Nothing an agent needs in order to invoke it correctly appears to be 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% and the uri parameter is well documented there, so the baseline would be 3. The description adds value by tying each URI scheme to different side effects and freshness guarantees, which tells the agent more about the parameter than its type and format alone.

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?

States a specific verb and resource: turning a stale resource URI from an earlier result back into a handle with current metadata. It is clearly distinguishable from siblings like search_workspace or the service tools because it operates on an existing handle rather than searching or fetching content.

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

Usage Guidelines4/5

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

Usage context is clear: this is for handles obtained from an earlier result, and the closing clause directs the agent to pass resource.id to the matching service tool to get actual content. It stops short of naming which sibling tool to use per scheme or stating when refreshing is unnecessary, so it is strong but not fully explicit about alternatives.

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

Deploy Server