Google Drive over MCP, or an assistant reading documents

Google Drive over MCP, or an assistant reading documents

Company knowledge rarely sits in a database. Far more often it lies in documents, spreadsheets, and decks nobody remembers, which hold answers to half the questions people ask.

A server in the protocol describing how tools attach to language models is meant to expose that to an assistant. Google publishes one such server per product: Drive, documents, spreadsheets, presentations, calendar, mail, and chat each have their own. This text covers the Drive one, since that is what finds files and reads their contents.

Before going further, two things to state immediately, since without them the whole text would mislead: the server is in an early version aimed at developers, and its scope is deliberately narrow.

Preview status and a narrow scope

The official server has not reached general availability and exposes eight tools oriented mostly towards reading: file search, a recent files list, file metadata, file permissions, content reading, content download, copying, and creating a new file. That is not an oversight but a deliberate decision, and its consequences deserve understanding.

The server can read files, copy them, and create new ones. It cannot update existing ones, delete them, move them, change permissions, or subscribe to changes. Those operations remain available only through the programmatic interface.

Writing content works differently from what Drive alone suggests, and that is the commonest misunderstanding around this family of servers. The documents server has a tool that updates a document, the spreadsheets server changes cell values, sets formulas, and inserts rows, and the presentations server updates slides. An assistant will therefore update a spreadsheet, just not through the Drive server: it takes attaching that product's own server, with its own set of permissions.

The consequence is practical. An assistant built on this server answers questions about document contents and creates new files holding summaries. It will not tidy a folder, delete or move a file, or share one with a colleague.

Preview status also means tool descriptions can change when Google updates its hosted service. With a remote service that is a change beyond your control, so instructions relying on a particular tool's exact behaviour may stop working without your involvement.

The conclusion is not "do not use it" but a statement of the right use. This is a tool for reading and summarising rather than for managing files. For the latter you need something else, covered below.

Permission scopes, the most important part

Here lies the most underrated part and simultaneously the one deciding the whole deployment's safety.

The server operates on two permission scopes. The first grants read access to a user's entire Drive. The second is considerably narrower and deserves separate understanding.

That narrower scope covers only files the application created plus those the user explicitly opened with it. That means the assistant does not see the whole Drive but exactly those documents it created or that were handed to it.

The difference between those two scopes is enormous and deserves a deliberate decision. The first is more convenient, since the assistant searches everything and finds an answer wherever it lies. The second is safer, since performance reviews, contracts, and private notes stay beyond reach even if the model were persuaded to read them.

For a company deployment, start with the narrower scope and widen it only once it proves insufficient. The reverse order means that for the first month the assistant read everything and nobody noticed.

Authentication runs through the standard mechanism with browser confirmation, separately for each user. That is good news, since the assistant's permissions are a specific person's permissions rather than the whole organisation's.

What it suits

Describing the uses concretely pays off, since they determine whether the narrow scope is a limitation or an advantage.

The most useful is finding information. A question about contract terms with a particular supplier leads the assistant to the right document and passage, rather than to a list of twenty files with similar names.

The second is summarising. A forty page document reduced to a list of decisions saves an hour and incidentally reveals what is not in it.

The third is working with spreadsheets. Reading data, computing something, and explaining where the result came from is often faster than building a formula, particularly in a sheet you did not create.

The fourth is combining with other sources. An assistant with simultaneous access to documents and company conversations, covered in the piece on the Slack server, can link a decision from a discussion to the document that came out of it.

What it will not do: tidy a Drive, delete or move a file, or change a file's permissions. If you need that, the Drive server is not the right tool, and for writing content itself the spreadsheets or documents server is the right choice.

Alternatives

Since the official server's scope is narrow, the other routes and their costs deserve knowing.

Community servers cover considerably more operations in one place: full file management, shared drives, permissions, version history, document and presentation editing. That solves the missing write capability and introduces another problem: you run somebody else's code with access to company documents, and nobody reviewed that code. The principles from the piece on the server catalogue apply here in full.

Google's programmatic interface offers the full range of capabilities and requires writing an intermediate layer. For a narrow, repeatable use, appending a row to a spreadsheet after an event for instance, that is usually the right route: a few dozen lines of code, full control, and no model in the loop.

Your own protocol server is the middle option. You expose a few named operations you wrote yourself, and the model calls them with parameters. The tools for that are covered in the piece on the protocol's toolkit.

Remember service accounts with organisation wide delegation too. They grant access to every employee's documents without their involvement, which solves the authentication problem and creates serious risk, since a configuration mistake means an assistant reading the whole company.

Document size and the model's context

A practical problem that with documents appears faster than with any other source.

A forty page document is tens of thousands of tokens. Loading three such files fills a large share of the available context, and the model must still fit the question, the conversation history, and room for an answer inside it.

There are two symptoms and both mislead. The first: the model answers from a fragment without signalling it did not see the rest. The second: the answer is correct and omits something written on page thirty, because the context ran out there.

Three things limit that. The first is asking about a specific part rather than a whole document, a chapter or a section for instance. The second is naming one file rather than letting the assistant load everything it finds. The third, on larger collections, is building a document search layer instead of passing files in full.

That last approach is the right one on an archive measured in hundreds of files. Splitting documents into fragments, computing vectors, and searching by meaning answers questions spanning a whole archive, which attaching a Drive alone does not provide. A protocol server suits working with individual documents rather than replacing search.

Spreadsheets, documents, and presentations

Three file kinds behave differently, and knowing what to expect from each pays off.

Text documents are the simplest case. The content reaches the model as text with headings preserved, so asking about content works well, and summarising a long document is the most common and most successful use.

Spreadsheets require caution. Flattening a table into text loses some meaning, particularly with merged cells, multiple tabs, and formulas whose result is visible while their content is not. Asking for a specific cell's value works; asking "what follows from this spreadsheet" is often answered confidently and wrongly. The separate spreadsheets server reads cell values and grid properties directly, so for working with data it suits better than reading the file through Drive.

Presentations are the hardest case, since their content lives in visual layout. Slide text can be read, while a chart, a diagram, and a relationship shown with arrows are lost. Speaker notes are often more valuable here than the slides, since they hold full sentences.

The practical conclusion: with spreadsheets and presentations, check the answers to two questions whose answers you already know. That is ten minutes showing whether the assistant genuinely sees what you think it sees.

Google Drive against the alternatives

The first row is the right starting point for most teams, since it removes upkeep and limits scope by default. Reach for the others once you hit its limits rather than before that happens.

The third row deserves honest consideration. Plenty of tasks described as needing an assistant are in fact a repeatable operation performed without a model more cheaply, faster, and without the risk of a different result each time.

Risks with company documents

This section concerns things that weigh more with documents than with any other data source.

The first is permission scope. Read access to a whole Drive covers personnel documents, contracts, and notes whose authors never assumed a model would read them. A narrower scope solves that at source.

The second is content coming back from the tool. A document's contents enter the model's context directly, and a document can hold a sentence phrased like an instruction. With files received from outside, supplier proposals for instance, that is not a hypothesis.

The third is accumulation. An assistant reading documents for a month passes their contents to wherever the client runs, and that is usually an external service with its own retention policy.

The fourth is personal data. Company documents hold names, salaries, and assessments, so processing them falls under the same rules as other employee data.

Three habits limit most of that risk: a narrower permission scope at the start, person level authentication rather than a service account, and checking where content goes on the client's side before the tool is approved.

Common mistakes

The first is granting read access to a whole Drive when the narrower scope covering named files suffices.

The second is expecting the Drive server to tidy a folder or change permissions. It reads, copies, and creates, while writing to a spreadsheet or a document belongs to those products' own servers.

The third is using a service account with organisation wide delegation where authenticating a single person suffices. The former grants access to the whole company's documents regardless of who asked.

The fourth is treating document contents as safe data. A file received from outside can hold an instruction that enters the model's context along with everything else.

The fifth is basing a production process on a tool in preview. Tool descriptions can change without your involvement, so critical automation needs a more stable foundation.

The sixth is running a community server with access to company documents without reviewing the code. Such servers' permission scopes are often considerably broader than the official one's.

FAQ

Is Google's official server production ready?

Not entirely. It remains in an early version aimed at developers, and tool descriptions can change when the vendor updates it. For reading and summarising documents it works well; for critical processes, wait or build your own layer.

What can this server not do?

Update existing files, delete them, move them, change permissions, or subscribe to changes. It can read, copy, and create new files. Updating the content of a document, spreadsheet, or presentation is possible through those products' own servers, while operations on Drive itself run only through the programmatic interface or community servers.

Which permission scope should I choose?

Start with the narrower one, covering only files the application created plus those the user named. The wider one grants read access to a whole Drive, including documents whose authors never assumed a model would read them.

Will the assistant see other people's documents?

Under person level authentication, only what that person can access. With a service account holding organisation wide delegation the situation differs, and such an arrangement should be avoided without a clear reason for it.

When is the programmatic interface better?

For a repeatable, narrow task, appending a row to a spreadsheet after an event for instance. A few dozen lines of code then give a predictable result, the full range of operations, and no model in the loop that might do something other than planned.

Configuration is described in Google's developer documentation, and the other Workspace servers on a separate page.