Skip to main content
Glama

Approve slides agent proposal

approveReportMessageProposal
Destructive

Approves the proposal of a settings_proposal or email_send_proposal reply, as its Approve button in the app's chat does: Rollstack makes the change, or sends the email. Only approve what the user approved after seeing the reply's proposal. Answers the reply with the proposal's status: applied once the change is made, and queued for a send, which getReportMessage then follows through sending to sent, partially_sent, failed or unconfirmed, with its counts. Needs also slide_decks:email for an email change or send, and slide_decks:write for the rest. Approving a send answers 409 while the report is updating, such as after a filter change the same message asked for, and counts against the 5 email sends a minute, as sendReportEmail does. Only the user who sent the message may, while they can edit the report. A proposal already decided answers 409. From an AI client, approving a send only asks the user to confirm it in Rollstack: it answers confirmation-required and runs once they confirm.

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": {
      "params": "<params>"
    },
    "name": "approveReportMessageProposal"
  }
}

Input Schema

NameRequiredDescriptionDefault
paramsYes
idempotencyKeyNoA unique value, such as a UUID, that makes retrying this call safe. A retry with the same key within 24 hours answers the first call's result instead of running it again. Use a new key for each new call. From 1 to 255 printable ASCII characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / idempotencyKey
      Added value: +{
      +  "description": "A unique value, such as a UUID, that makes retrying this call safe. A retry with the same key within 24 hours answers the first call's result instead of running it again. Use a new key for each new call. From 1 to 255 printable ASCII characters.",
      +  "pattern": "^[\\x20-\\x7e]{1,255}$",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With annotations already declaring destructiveHint=true and openWorldHint=true, the description adds rich context: the required scopes (slide_decks:email, slide_decks:write), the 409 conditions for an updating report or already-decided proposal, the 5-email-per-minute rate limit, and the confirmation-required behavior for AI clients. This is exactly the kind of behavior beyond annotations that helps an agent decide when to call or wait.

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

Conciseness3/5

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

The description is a dense, run-on block that mixes scope, rate limits, 409 conditions, and AI-client confirmation into long clauses. Every sentence is relevant, but the information is not structured well and is hard to scan; front-loading the core purpose is good, but the rest is crammed.

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

Completeness4/5

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

Given the mutation tool with no output schema and the complexity of approval flows, the description covers a lot: scopes, 409s, rate limits, and a follow-up tool (getReportMessage). It stops short of describing the response shape, but with no output schema and the reference to getReportMessage, it is fairly complete.

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

Parameters4/5

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

The schema only documents the nested params object at 50% coverage. The description adds meaning for the proposal flow and references required scopes, though it doesn't re-explain id/replyId/messageId beyond the schema. The addition of idempotency behavior is slight, but the description still adds value beyond schema basics. Because the schema is moderately covered and the description doesn't explain parameters in depth, a 4 is appropriate.

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

Purpose5/5

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

The description states a specific verb and resource: 'Approves the proposal of a settings_proposal or email_send_proposal reply', and explains the effect ('Rollstack makes the change, or sends the email'). This makes it clearly distinct from rejectReportMessageProposal and the various send/get tools.

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

Usage Guidelines4/5

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

It provides a strong usage fence: 'Only approve what the user approved after seeing the reply's proposal', which effectively distinguishes approve from reject and from re-driving decisions. However, it does not explicitly state when to choose rejectReportMessageProposal over this tool, though the sibling name helps.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources