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.

Changed1 schema field changedSep 10, 2026
- removedOutput schema / additionalProperties
```
Removed value: -false
```
First observedSep 5, 2026

TDQS

A4/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 specific behavioral detail beyond annotations: it returns content if accessible, otherwise returns a grant link. It also mentions resolving against the Drive API and the file_name_hint usage. This enriches the agent's understanding without contradicting annotations.

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 three sentences, each earning its place: the first specifies when to use, the second explains the dual outcome, and the third gives an actionable hint. It is front-loaded with the trigger condition and avoids redundancy. Highly concise and well-structured.

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

Completeness4/5

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

Given the tool has an output schema (not shown) and schema coverage is complete, the description does not need to detail return structures. It covers the essential behavior (access resolution, content or grant link) and even links to API docs. It lacks explicit authentication notes, but that is likely not needed for a read-only operation and is implied by the annotations.

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 baseline is 3. The description's explanation of file_name_hint ('so the picker can search for it') adds a subtle purpose clarification, but the schema already covers the parameter's meaning ('Used to pre-fill the file picker search'). Thus the description provides little additional value 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 states the tool's purpose clearly: access a file when the user shares a Google Drive URL or asks to access a specific file. It specifies the resource (URL) and the verb (access). However, it does not explicitly distinguish from sibling tools like read_file or request_file_access, though the URL focus is implicit differentiation.

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 a clear trigger condition: 'When a user shares a Google Drive URL or asks you to access a specific file, use this tool.' It also explains behavior for accessible vs inaccessible files. It does not explicitly mention when NOT to use it or alternatives, but the context is clear enough for most cases. A brief note on when to prefer read_file or request_file_access would improve it.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?