Waits for one future task notification for a specified role over an authenticated SSE connection, then unsubscribes so agents can receive role-specific work assignments.
Wait for one future role task notification over authenticated SSE, then unsubscribe. Host effects: makes network requests.
| Name | Required | Description | Default |
|---|---|---|---|
| role | Yes | ||
| timeout_seconds | No |
| Name | Required | Description | Default |
|---|---|---|---|
| _meter | Yes | ||
| result | Yes |
Changes observed during successful MCP inspections.
v3.23.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does meaningful work: it discloses blocking semantics, authenticated SSE, automatic unsubscribe after a single notification, and host network effects. It omits critical behavior an agent needs — what happens when the timeout elapses (error vs. empty result) and whether it blocks up to the schema's default of 30s / max of 60s.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core blocking action and followed by the resource lifecycle and host effects. No filler; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers the returned notification shape, so return values need no prose. But for a blocking, network-touching tool with zero annotation coverage, the description should still address timeout behavior and error/empty-result semantics, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it largely does not. The phrase 'role task notification' hints at the required role parameter, but timeout_seconds — with its default 30, range 1–60, and blocking implications — is never mentioned, leaving the most behavior-relevant parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action (wait for one future role task notification), the transport (authenticated SSE), and the lifecycle (then unsubscribe). It is clearly distinguishable from siblings like bernstein_run_status or bernstein_claim by being a blocking single-notification wait, though it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'wait for one future role task notification' — an agent can infer this is for blocking on upcoming work for a role. However, there is no explicit when-to-use vs. alternatives (e.g., poll with bernstein_run_status instead) and no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.