Feat: Add session/list API for managing and discovering sessions #226
Conversation
This commit introduces the `session/list` capability, allowing agents to list existing sessions with optional filtering and pagination. It includes the `ListSessionsRequest` and `ListSessionsResponse` structures, along with the necessary updates to the protocol documentation and JSON schema. This feature is marked as **UNSTABLE** and may change in future iterations.
| "description": "Unique identifier for the session" | ||
| }, | ||
| "title": { | ||
| "description": "Human-readable title (may be auto-generated from first prompt)", |
There was a problem hiding this comment.
Made a discussion comment here, but wondering
While true it may be auto-generated, the impact is you shouldn't cache this right? Because it might be initially empty or a fake initial value like "Goose ACP". It seems several flows indeed do a lazy one-time update, but I'm not sure if that's only one time always (e.g. should this just be assumed never cacheable unlike the sessionId, which should me immutable?)
There was a problem hiding this comment.
There is nothing in the spec says it should be cached, Its more of an ACP client preference but when using session/list I agree that we should return the latest title
| "type": ["string", "null"] | ||
| }, | ||
| "updatedAt": { | ||
| "description": "ISO 8601 timestamp of last activity", |
There was a problem hiding this comment.
This might be a great place to clarify the impact of the other field.
| "description": "ISO 8601 timestamp of last activity", | |
| "description": "ISO 8601 timestamp of last activity, such as title update", |
There was a problem hiding this comment.
That’s debatable from an experience standpoint. Why should the order of the sessions change just because the title changed? It also depends on each agent’s behavior — some update the session’s updated_at when the title changes, and some don’t.
codefromthecrypt
left a comment
codefromthecrypt
left a comment
There was a problem hiding this comment.
forgive me if there are standards in general we are using which indicate serialize null on a non-required field. this is a bikeshed, just trying to understand if we are intentional on this or if it was just a practice and not too late to discuss it.
| }, | ||
| "title": { | ||
| "description": "Human-readable title (may be auto-generated from first prompt)", | ||
| "type": ["string", "null"] |
There was a problem hiding this comment.
I'm not sure if we have value both marking something optional (not required field) and also nullable. since this is not a required field, should we just simplify to when present, put in a valid string?
| "type": ["string", "null"] | |
| "type": "string" |
2 participants
This commit introduces the
session/listcapability, allowing agents to list existing sessions with optional filtering and pagination. It includes theListSessionsRequestandListSessionsResponsestructures, along with the necessary updates to the protocol documentation and JSON schema. This feature is marked as UNSTABLE and may change in future iterations.