Jonathan Hefner

> * `schema` property left blank: implies that the content follows the `outputSchema` on the tool definition > * `schema` property is a string: treat it as a URI for...

@briancripe > To provide an example of the benefits: for advanced "tool call planning" for a complex task, the Agent may want to understand what kinds of expected outputs and...

@lukaswelinder > the `outputSchema` could be a collection of definitions that are referenced by the `content.schema` Ah, I see. You're saying to forgo the top-level `type: "object", properties: {}` and...

> It's helpful for chaining tools to create workflows (either via LLM or just calling them from code). Particularly when calling/chaining tools from code, having a schema defining the potential...

> I was thinking of situations where the client might have gotten a first progress notification on some longer-lasting server operation but then gets disconnected. Or the connection drops after...

> UUID `Event-Id` / `Last-Event-Id` ? Or maybe using the request ID (if it's a UUID) and appending an incrementing integer for event IDs? [@jonathanhefner](https://github.com/jonathanhefner) may have some thoughts on...

> the questions above about server capabilities changing would probably be solved by sending server capabilities in every response I'm not sure that would work. Generally, server capabilities dictate what...

> To fulfill this goal, I think: > > * the server must document which requests are "stateful", that is, have special behavior when executed within a session. > *...

> There's a `server/discovery` call, which the client (I assume) does first. The questions about server capabilities changing were really "how often do I poll `server/discovery` to see if anything...

> My question is how the client is supposed to _reply_. If the client sends a subsequent POST with the reply, it won't reach the same server without some sort...