What You Can Actually Ask Claude Once It Can Read Your Files

Connecting a local search tool to Claude changes what is worth asking. The instinct at first is to keep naming files, because that is what every previous search tool required. It takes a few conversations to notice you can stop doing that.

Below are five scenarios that cover the shapes most questions fall into, including one where the honest answer is that there is nothing to find.

Scenario 1 — A question about a contract you did not open

The situation: a counterparty asks about a liability clause. You negotiated it months ago across several drafts and you remember the outcome roughly, not exactly.

What you type:

What did we end up agreeing about liability in the supplier contract? I remember we pushed back on something.

What happens: Claude searches by meaning, not filename. It gets back the drafts and the mail thread around them, with several passages from each — enough to see the clause and the argument about it, not just a title. It answers with the outcome and cites which file each part came from.

Why this works better than a filename search: you did not know the filename. You knew a fact about the content. Keyword search would need you to guess the exact wording used in the document, and "liability" may never appear in the draft that matters if it was written as "limitation of damages".

Scenario 2 — The email you half remember

The situation: someone sent you a schedule change. You remember reading it, not who sent it or when.

What you type:

Someone told me the review meeting moved. Find that message and tell me the new date and who sent it.

What happens: mail is indexed alongside documents, so this is one search, not two. Results identify themselves by subject, sender and date — not by the opaque filenames mail exports actually have on disk. If several messages match, Claude can walk the reply chain to find the latest one rather than answering from the first hit.

The failure mode this avoids: answering from an early message in a thread that was later superseded. Getting the thread, not the hit, is what makes the answer trustworthy.

Scenario 3 — A number in a spreadsheet

The situation: you need a figure from a workbook you have not opened in months.

What you type:

In the Q2 budget workbook, what did we put down for contractor costs, and which sheet and cell is it in?

What happens: spreadsheets are read as structure rather than flattened into a wall of text, so cell coordinates, sheet names and merged ranges survive. Claude can tell you the value and where it sits, which is what makes the answer checkable.

Worth knowing: a date stored as a date comes back as a date, not as the raw serial number spreadsheets keep underneath. That sounds like a detail until an AI confidently tells you a deadline is in 1900.

Scenario 4 — How something changed over time

The situation: a document went through many versions and you need to know what moved.

What you type:

Show me how the payment terms changed across the versions of this agreement, oldest to newest.

What happens: versions of the same document are recognised as related rather than treated as unrelated files that happen to share a name. Claude can line them up in order and describe what changed between them, citing each version.

The move that helps here: ask for the order explicitly. "Oldest to newest" is a cheap instruction that turns a pile of matches into a narrative.

Scenario 5 — When there is nothing to find

This is the scenario people skip, and it is the one that decides whether you can trust the other four.

What you type:

Find our policy on expense reimbursement for contractors.

What happens if you have no such document: the response says what it searched, how it read the query, and that nothing matched — rather than returning the nearest thing and letting Claude narrate it as if it were the policy. If the query was interpretable but produced nothing, that is stated. If the query itself did not hold up — every word was a stop word, say — that is stated too, instead of a plausible-looking list.

Why this matters more than any success case: a search tool that always returns something teaches an AI to always say something. The failure you cannot see is the expensive one.

The one move that fixes most disappointing results

If the first attempt comes back thin — many files, a sentence from each, no real answer — the usual cause is that the connector was asked to locate rather than to answer. Those need different amounts of material: locating wants many documents with short excerpts, answering wants few documents with long ones.

You do not need special syntax. Saying what you want is enough:

Don't just list files — read them and answer the question.

On our own test set, the difference between those two modes was roughly 176 characters of document text per result versus about 1,850 — the difference between a teaser and a page. That is usually the gap between "it found something" and "it answered me".

Steering when the results are the wrong kind

Sometimes the search is fine but the mix is wrong — you wanted internal documents and got mostly email, or vice versa. The response includes the axes it did not filter along with real counts, for example eleven documents and nine emails, so the ambiguity is visible rather than silently resolved.

Then you just say which one:

Only the emails, and only this year.

Claude re-runs with that constraint. The point of surfacing the split is that neither of you has to guess: the connector reports the shape of what it found, and you pick.

What stays on your machine

Worth being precise, because "local" gets used loosely. The index and the search run on your computer; your files are not uploaded anywhere to be searched. What does travel is the conversation — your question, and the passages Claude decided to reason over, which are sent to the model exactly as they would be if you had pasted them yourself. The distinction that matters is that you no longer have to know which file to paste.