nit: I think tool-chaining and autonomous retries are a bit too generic to include in this parenthetical - maybe we should remove the parenthetical entirely and just rely on (or reuse) the semantics described above this to avoid confusion.

I wonder if we're mixing things here:

It seems what this hint is trying to address is an element of risk that arises from non-determinism of agents. That fact that a tool is "agentic" is an implementation detail: what we care about here is risk levels from non-determinism.

For the progress/logs, etc. that feels like a separate thing from agency (or non-determinism). That's just something you'd like with any long-running tasks with intermediate output.

I wonder if nondeterminismHint would get more at what this is trying to achieve.

My worry is that (1) "agency" is quite a vague concept, so people will be unsure when to set this hint, and (2) you may have tools that are risky/nondeterminstic without having agentic implementation, and those might not be shown appropriately in UI even though they should.

Or maybe a simple "riskLevelHint" would be sufficient...

I'd like to understand two things:

• does an agentic tool that uses sampling requests for its inference in an agent loop count?
• in GitHub MCP we trigger Copilot Coding Agent via 2 tools, and I would like to know if they should be annotated, the response is deterministic (just job information like the PR the coding agent opens) but the side-effect is an autonomous agent working on code in the cloud, using whatever access and MCPs it is granted.

I'm not sure nondeterminism covers the second case

I think for annotations they need to be very clear:

• why does a client/end user need to know this
• why is it not covered by other annotations
• is it clear to server authors when it should be used

And I am not certain in clear on answers to those questions.

@pja-ant Nondeterminism doesn't fully capture the risk at play, here, and we shouldn't confuse the two concepts. If I have (as a contrived example of a non-risky, nondeterministic tool) a tool that can either search the web or read a file, and it randomly does one action or the other, that's probably not a very risky tool to use, but it is a nondeterministic one.

If, on the other hand, I have a tool that can either do nothing or create a costly compute resource at random, that is then a risky, nondeterministic tool. Risk is tied to both what the most costly action that can be taken is, in addition to how likely that action is to occur. In the case of agency, that's a special case where I don't necessarily know the full range of actions that may occur, but I'm fairly certain they lie in a particular range of reasonable actions, and with a relatively low (but non-zero) probability of negative actions.

@SamMorrowDrums This sounds like a partial refutation of @pja-ant's comments, if I'm reading this right, but to answer your questions in the context of agencyHint specifically:

does an agentic tool that uses sampling requests for its inference in an agent loop count?

Yes, it would.

in GitHub MCP we trigger Copilot Coding Agent via 2 tools, and I would like to know if they should be annotated, the response is deterministic (just job information like the PR the coding agent opens) but the side-effect is an autonomous agent working on code in the cloud, using whatever access and MCPs it is granted.

This also sounds like a use case for agencyHint.

• why does a client/end user need to know this

So that I know how likely it is for negative outcomes to occur as a side-effect of a tool being invoked, and can review the inputs more carefully.

• why is it not covered by other annotations

• readOnlyHint should be self-explanatory
• destructiveHint is technically-correct, but not in a useful way when it comes to agents; they may take destructive actions, but the destructive actions they may take are a function of their own capabilities and the input prompt they are provided with.
• idempotentHint should also be self-explanatory
• openWorldHint is also technically-correct, but again not in a useful way when it comes to agents. A tool-agent's domain of interaction may be closed and yet still "open enough" for it to cause damage if unconstrained or given sensitive information.

• is it clear to server authors when it should be used

From the Semantics section of this proposal:

• When present and set to true, this signals that the tool may perform:
  • Multi-step reasoning or planning,
  • Goal-directed behavior that may result in multiple underlying actions.

I'm not sold on adding this without having specific examples of how clients would want to use it, ideally from client developers themselves.

A strong signal would be if we saw clients already treating this category differently by doing things like hard coded lists for popular servers they cared about or resorting to string matching on tool names or classifying tool descriptions to come up with these hints themselves.

Absent a signal like that, it seems like we're introducing complexity for a category that's not well understood or in demand from its target audience.

Responsible AI policies often require human-in-the-loop, an elevated level of transparency, audit trails, and proper handling of user intent end-to-end. It's a matter of finding out what's on the otherside of the line. The proposed agencyHint simply informs the governance of tools, if and when, they become agentic.

Do we have clear definitions on what is an agent vs what is a tool? How does this change messaging patterns...

Feels like we are trying to say that this Tool has a different kind of compute behind it. I'm not sure that information is necessary. We don't distinguish HTTP requests based on whether its a static web page or a giant set of microservices.

While we don't distinguish HTTP requests based on if something is static or not, we do generally distinguish high-cost/risk HTTP requests from low-cost/risk ones, if we know that information ahead of time (that is, it's a use case decision, not a technical one).

In the case of agencyHint, what this means is that because we as the end-users do not necessarily tightly-control the upstream tools or capabilities of the associated agent behind a given tool, we should exercise increased caution regarding when an agentic tool is invoked, and review that tool's inputs/outputs more carefully.

As for a direct answer to the question, the Semantics section addresses this:

• Multi-step reasoning or planning,
• Goal-directed behavior that may result in multiple underlying actions.