How a Shared Drive Became a Source-Cited Research Tool

Where the research process broke

A shared Drive held the material needed for research, delivery, and internal questions. The problem was not a lack of documents. It was the repeated work of locating the relevant project, opening likely files, finding the right passage, and preserving enough context to cite it accurately.

That workflow produced inconsistent research trails. Two people could approach the same question through different folders and documents. A useful source found once could be difficult to rediscover. A response could sound grounded while leaving the reader without a fast path back to the supporting material.

The goal was a research layer that kept the source library in its existing home while making evidence easier to retrieve. The system needed to respect project boundaries, return the actual supporting text, and give the person asking the question a link they could inspect.

Why a generic chatbot was not enough

A generic chat window can summarize text placed in front of it. It does not provide a durable operating model for a growing Drive with multiple projects, changing files, and a requirement to show where an answer came from.

The useful unit of work was a passage inside a known source file. That meant retrieval needed metadata for the project, source location, and citation URL alongside the text embedding. The assistant also needed a narrow tool surface. Search found relevant passages, and fetch returned source text for review. Read-only access kept research and source inspection separate from document modification.

This is the kind of implementation that benefits from a focused MCP server development layer. The official MCP specification separates server features such as tools, resources, and prompts. This assistant exposed narrow tools shaped around evidence retrieval instead of broad access to a document system.

The architecture that shipped

The system ingested Drive material on a project-scoped basis. During ingestion, files were extracted, divided into searchable chunks, embedded for vector retrieval, and stored with the metadata needed to identify their source.

The first verified run indexed more than 200 source files. The index contained about 3,900 searchable chunks, enough to retrieve passages at a useful level of detail instead of treating an entire document as one match.

A multi-project dashboard made the indexed material visible for review. Access controls limited the assistant to read-only search and source-fetch operations. The handover package documented the architecture, checks, and operating decisions for the next person maintaining it.

How project-scoped retrieval worked

Project scope came first. A research request selected the relevant body of material before searching, which reduced the chance that a passage from one project would be presented as support for another.

Within that project scope, vector retrieval ranked chunks by relevance to the question. Search results included enough information to identify the source and follow a citation URL. When a result needed closer review, the fetch tool returned the supporting source text. That split matters because a short result preview helps discovery, while source fetch gives the researcher the surrounding material needed to validate a claim.

The assistant did not need write permissions to provide this value. A read-only boundary reduced the chance that an exploratory question would alter source files or ingestion settings. It also kept the work legible during review: the tools searched and fetched evidence, then the person using the system could decide what to do with it.

What was verified

Historical deployment checks covered the ingestion flow, project-scoped retrieval, read-only search and source fetch, citation links, and the dashboard handover. The first verified index provides the bounded file and chunk counts used here.

The implementation also verified that search results could lead researchers back to supporting source text through citation URLs. That is the core operational behavior: discover a relevant passage, inspect the source material, and retain a direct path back to it.

What was not measured

This work did not measure research time saved, answer accuracy, user adoption, return on investment, or ongoing service health. The evidence supports the delivered architecture and historical end-to-end checks. It does not support claims about later use or business impact.

Those measures would require a separate evaluation plan. For example, a team could sample recurring research questions, score whether the returned sources supported the final answer, and compare the resulting workflow with their prior manual process.

Who this pattern fits

This pattern fits teams with internal document libraries that need grounded answers from their own material. It is useful where research must stay organized by project, source review matters, and the person receiving an answer needs a direct route to the underlying evidence.

It also fits teams that want to add AI assistance without turning their document library into an opaque black box. Start with the documents already used for delivery, define project boundaries clearly, and make source retrieval part of the answer path.

If your team has the documents but no reliable way to turn them into inspectable answers, scan the current workflow to identify where source discovery and citation work are breaking down.

What I would revisit

I would introduce source-quality scoring earlier in the design. A retrieval system can find passages efficiently while still surfacing outdated, duplicated, or weak source material. Those issues belong in the source layer before they become a research-quality problem.

A practical next pass would score freshness, duplication, source type, and project ownership during ingestion. Retrieval could then use that score as an additional signal beside semantic relevance. The result would keep the current evidence path while giving researchers clearer context about why a source earned its place in the answer.