A good tool hint leads to consistent and unambiguous client/server behaviors. Like idempotentHint clearly indicates to client that "this tool can be retried without side effects on the world state". However in this proposal, many hints are not "clearly, unambiguously actionable". Client could implement very different behaviors on the same hint from the server, leading to inconsistency.

Also some of the hints could be substituted by existing MCP mechanisms:

• slowExecutionHint - This should be implemented as a Task
• privilegedAccessHint - A proper way is to use out of band elicitation to acquire auth info.
• reversibleHint: Reverting is usually harder to implement and error prone. A better design pattern is to implement a tool with idempotentHint, so that client could retry when failure. This is often more robust than asking client to revert.

A good tool hint leads to consistent and unambiguous client/server behaviors. Like idempotentHint clearly indicates to client that "this tool can be retried without side effects on the world state". However in this proposal, many hints are not "clearly, unambiguously actionable". Client could implement very different behaviors on the same hint from the server, leading to inconsistency.

@pwwpche fair point, is there an established process to make "hints" / trial hints in a structured manner to establish whether the UX and Governance around it is consistent? Would be nice if we had an extension/hint-test-bed for adoption. Also if hints should be all independent seps or not.

Also some of the hints could be substituted by existing MCP mechanisms:

• slowExecutionHint - This should be implemented as a Task

I think long running and Task semantics can be independent from one another. This is different than the TaskHint originally proposed in #1938 and is more towards UX of long running operations. I think this will especially come into play with the stateless transport work.

• privilegedAccessHint - A proper way is to use out of band elicitation to acquire auth info.

This is intended to manage governance around this: what are the tools in this chain that CAN access privileged data. Even if we can guarantee auth around this, how do we have auditability.

I think long running and Task semantics can be independent from one another. This is different than the TaskHint originally proposed in #1938 and is more towards UX of long running operations. I think this will especially come into play with the stateless transport work.

Can you elaborate on this a bit more? Transports generally wouldn't be able to leverage hints at all, and the host application already knows which transports each server is using.

I think long running and Task semantics can be independent from one another. This is different than the TaskHint originally proposed in #1938 and is more towards UX of long running operations. I think this will especially come into play with the stateless transport work.

Can you elaborate on this a bit more? Transports generally wouldn't be able to leverage hints at all, and the host application already knows which transports each server is using.

Yeah, do not intend this to be used for transports. I meant that Task-implementing servers may not be long running operations but simply enable reconnects, multiple task/result retrieval. The hint however can be used to establish consistent UX. Additionally for server/receivers that do not implement tasks capabilities, they can still expose slowProcessing hints for appropriate UX.

Couple scenarios for when this hint is useful with and without task capability support.

1. A server with Task capability need not be slow

• Ex. A deep research vs quick research answer tool both may generate a report and implement task capability (enabling async-fetch of its output) but one is clearly slowExecution and one is fast (a Fast mode may choose to select only tools that are slowExecution: false while Thinking mode can enable all tools). Implementing Task will not give you information sufficient to make these UX decisions. In both cases, I may fetch this reposrt asynchronously or multiple times from task/result.

2. A server without Task capability may be slow

• Ex. In the case of slow tools that are not implementing tasks I would like to use notifications for updating a progress bar in my application rather than being fully async.