Summer

Change one channel's autonomy with the expected version

summer_messenger_autonomy_update

Change one channel's autonomy with the expected version. With fast reply on, the assistant handles that channel's messages and starts a plan only when it escalates. A lower threshold gives it more autonomy.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "company": "<company>",
      "environment": "<environment>",
      "channel": "<channel>",
      "version": "<version>"
    },
    "name": "summer_messenger_autonomy_update"
  }
}

Input Schema

Name	Required	Description
`channel`	Yes
`company`	Yes	Summer company ID
`version`	Yes
`environment`	Yes	Environment that owns the resource
`idempotency_key`	No	Reuse the same key when retrying the same change
`auto_run_enabled`	No	Run this channel's plans without waiting for a person when the agent says it would run the plan, all five self-review checks pass and it is at least auto_run_threshold sure. Plans with A/B/C options, money, identity or clinical work always wait for a person. The admin who turns it on is the recorded approver. Default off.
`auto_run_threshold`	No	How sure the agent must be before a plan runs alone, 0 to 100. Lower means more autonomy. Default 95. Auto-run stays off until enabled.
`fast_reply_enabled`	No	The assistant answers this channel's messages.
`fast_reply_threshold`	No	How sure the assistant must be to answer alone, 0 to 100. Lower means more autonomy. Default 50.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

changedInput schema / properties / auto_run_threshold / description

Previous value: -"How sure the agent must be before a plan runs alone, 0 to 100. Lower means more autonomy. Default 50."New value: +"How sure the agent must be before a plan runs alone, 0 to 100. Lower means more autonomy. Default 95. Auto-run stays off until enabled."

Changed3 schema fields changedOct 24, 2026

removedInput schema / properties / auto_run_enabled / const
```
Removed value: -false
```

changedInput schema / properties / auto_run_enabled / description

Previous value: -"Auto-run of approved plans is not available yet."New value: +"Run this channel's plans without waiting for a person when the agent says it would run the plan, all five self-review checks pass and it is at least auto_run_threshold sure. Plans with A/B/C options, money, identity or clinical work always wait for a person. The admin who turns it on is the recorded approver. Default off."

changedInput schema / properties / auto_run_threshold / description

Previous value: -"Saved for auto-run plans. Default 50."New value: +"How sure the agent must be before a plan runs alone, 0 to 100. Lower means more autonomy. Default 50."

AddedOct 24, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), so the description could add more than it does. 'A lower threshold gives it more autonomy' and 'the assistant handles that channel's messages' largely restate the schema text for fast_reply_enabled and auto_run_threshold/fast_reply_threshold. It adds the escalation concept but says nothing about version-mismatch behavior, what changes take effect on other channels, or whether an audit/approver record is produced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, mutation intent front-loaded, no filler. The second sentence is slightly loose ('starts a plan only when it escalates' leaves the antecedent of 'it' ambiguous), but overall efficiency is good.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter, non-idempotent mutation with no output schema, the description omits how to obtain and supply the expected version, what happens on a stale version, and the impact of the idempotency_key parameter. It is adequate to understand the tool's domain but not complete enough to call it correctly under conflict conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 78%, so the schema already documents most of the nine parameters, including detailed text for auto_run_enabled and the thresholds. The description contributes no parameter syntax, defaults, or interaction rules beyond repeating that lower thresholds mean more autonomy, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Change one channel's autonomy') and scopes it to a single channel, which separates it from the sibling summer_messenger_autonomy_read and from summer_messenger_assistant_update. The phrase 'with the expected version' hints at optimistic concurrency, but no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent infers it should call this to mutate autonomy, but the description never says when to prefer it over summer_messenger_autonomy_read, summer_messenger_assistant_update, or summer_messenger_autonomy_backfill_apply. There is also no guidance to read the current version first, which the 'expected version' wording makes necessary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Summer tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.