Serving Real Files From a Tool Handler

A real project can have hundreds of files. A useful list_files tool accepts a prefix (like "src/") and returns only matching paths, so a model exploring a project can narrow its view instead of receiving an unusable wall of every file at once.

Inside dispatch, an uncaught exception from a handler would crash the whole request — one bad path argument shouldn't take down the server process handling every other tool call too. Returning a descriptive error string (or a structured error object) keeps a single failed call contained and reportable back to the client.

A Real Project to Serve. DevAssist needs to serve more than one hardcoded file. This lesson gives read_file and list_files a small simulated project — a few real files with real content — and asks list_files to actually filter by a path prefix, the same way a real client browsing a folder would expect.

Return Real File Contents. list_files_handler and the missing-file guard are done. Finish read_file_handler so that when a path really exists, it returns the file's actual contents instead of falling through to None.

Why does read_file_handler return a plain error string for a missing file instead of letting Python raise a KeyError?

• →So the MCP server can package the failure as a normal tool result sent back to the client, instead of an unhandled exception crashing request handling.
• →Because Python is incapable of raising exceptions inside a function called from a dictionary.

Files Done, Tasks Next. read_file and list_files now serve a real, if small, project. DevAssist's second job is managing tasks — next lesson, create_task and list_tasks, backed by real in-memory state that changes as tools are called.