ShareWatch

Open File by Link

access_file_by_url

Read-onlyIdempotent

When a user shares a Google Drive URL or asks you to access a specific file, use this tool. Accepts any Google Drive, Docs, Sheets or Slides URL and resolves it against the Google Drive API (https://developers.google.com/drive/api/reference/rest/v3). If the file is already accessible, returns its content. If not, returns a grant link the user can open to select it. If the user mentions the file's name, pass it as file_name_hint so the picker can search for it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	A Google Drive, Docs, Sheets, or Slides URL
`file_name_hint`	No	The file's name if mentioned by the user. Extracted from conversation context. Used to pre-fill the file picker search.

Output Schema

TableJSON Schema

Name	Required	Description
`advice`	No	what to tell the user when the file could not be returned — relay this rather than paraphrasing
`offset`	No	where this slice of the text starts, when the file was read in chunks
`content`	No	the file's text — this is what the tool exists to return, present whenever outcome is 'granted'
`file_id`	No
`outcome`	Yes	which outcome this is: 'granted' (file resolved, details populated), 'too_large' (file exists but must be read in chunks — see size_chars), 'not_shared' (ShareWatch has no grant for it yet — give the user action_url), 'not_a_drive_link' (the URL points somewhere other than Google Drive — relay advice, there is no action_url and no grant can help), or 'unrecognized' (nothing in the input looked like a Drive link or ID). All of these are successes; a genuine failure arrives as an error.
`version`	No	Drive's revision counter for the file at the time it was read
`file_name`	No
`mime_type`	No
`truncated`	No	true when content is only part of the file — read the rest with read_file using offset
`action_url`	No	the page the user opens to grant access to this specific file; give them this link
`size_chars`	No	length of the file's text, when it was too large to return inline
`total_chars`	No	total length of the file's text, which may exceed what content holds
`approx_tokens`	No	rough token cost of the whole file, to help decide how to chunk it

Schema Changelog

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

First observedSep 5, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable conditional behavior: if the file is accessible it returns content, otherwise it returns a grant link. It also explains the file_name_hint parameter's role in the picker.

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 compact, front-loads the usage trigger, and every sentence adds necessary context about behavior or parameters. The API reference link is supplementary, not 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?

Coupled with the annotations and output schema, the description covers what the tool does, when to use it, what inputs matter, and what happens in both accessible and inaccessible cases. Nothing critical is missing for correct invocation.

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?

Schema description coverage is 100%, so the parameters are already well documented. The description restates that file_name_hint is used when the user mentions a file name, but does not add meaningful semantic detail beyond the schema.

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?

The description clearly states the tool resolves a user-provided Google Drive URL and returns either file content or a grant link. It is specific about the resource and action, though it does not explicitly contrast itself with sibling tools like read_file or request_file_access.

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?

The description gives explicit triggers: when a user shares a Google Drive URL or asks to access a specific file. It does not state exclusions or name alternatives, but the URL-focused guidance is clear enough to route the agent correctly.

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

All ShareWatch tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools target a distinct resource and action, and the detailed descriptions separate similar-sounding ones. A few pairs could still be confused: access_file_by_url vs request_file_access, and create_document vs format_document, but their trigger conditions are described clearly enough to avoid frequent misselection.

Naming Consistency4/5

The set mostly follows a verb_noun pattern with consistent snake_case, e.g. create_document, update_spreadsheet, delete_file. Minor deviations like build_presentation instead of create_presentation, and format_document alongside create_document, break the pattern slightly but remain readable and predictable.

Tool Count3/5

25 tools is at the heavy end of the scale, though the domain spans Drive, Docs, Sheets, and Slides, which justifies a large surface. Some consolidation is possible — access_file_by_url and request_file_access overlap, as do create_document and format_document — so the count feels slightly bloated rather than tightly scoped.

Completeness4/5

The server covers the core file lifecycle well: create, read, update, delete, move, list, search, upload, and access control across all major Google Workspace document types. Minor gaps exist, such as no rename, copy, export, or direct sharing tool, but agents can work around these without major failures.

Resources

Need Help?