Demander les racines du client

Knowing roots exist is step one. Step two is actually asking the client for its current list so your server can decide where to read or write. 📨

Here the direction flips: your server sends the request and the client answers. The method it calls is roots/list, asking for everything the client currently exposes.

In the Python SDK you do not craft raw JSON. You use the request context object handed to your tool, which wraps the live session to the client.

From that context you call list_roots() and await it. The SDK sends roots/list for you and returns the client's answer as a typed result.

The reply holds a roots list. Each item has a uri and an optional name, exactly the small shape you saw before, ready for you to loop over.

A valid answer can be an empty list. That means the client offers no roots right now, so plan a sensible fallback rather than assuming a folder exists.

Calling list_roots only makes sense if the client supports roots. A polite server checks the declared capability before asking, avoiding errors on hosts that lack it.

Fetch roots when you need them, like at the start of a file tool. Asking lazily keeps you current if the user has since opened a different folder.

A root's uri is a string like file:///home/ada. To use it, parse the file:// URI into a real filesystem path before opening anything inside it.

If the client supports it, it can send a notification when roots change. Catching that lets you re-fetch the list instead of working from a stale view.

The request can still fail or time out. Wrap the call so a missing answer leaves your tool with a clear message instead of a crash. 🛟

Pick the right way to get the client's roots in the SDK.

You await list_roots() on the session, loop over the returned roots, parse each file:// uri, and handle empty or failed replies. Re-ask when roots change. ✅