Skip to main content
Glama
Sign In
aspa-mcp

aspa-mcp

by octos-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Adiar até data

aspa_snooze_until
Destructive

Snooze a support conversation until a specific date and time in Brasília time, with an optional internal comment. Use it to pause a chat and bring it back later, only after the user approves the action.

Instructions

Snooze a conversation until a specific date and time (Brasília time, 15-minute steps), with an optional internal comment. This is a real action visible to the customer or the team. Only call it after the user explicitly approved this exact action in the conversation.

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": {
      "contact": "<contact>",
      "date": "<date>",
      "time": "<time>"
    },
    "name": "aspa_snooze_until"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesYYYY-MM-DD
timeYesHH:MM, minutes 00/15/30/45
indexNoIndex from aspa_list_conversations, only to tell apart contacts with the same name.
commentNo
contactYesContact name exactly as listed. Required for every action that changes a conversation.
conversation_idNoconversation_id returned by aspa_read_conversation. When given, the action is refused if the open conversation is a different one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds meaningful context beyond them: the action is genuinely visible to the customer or team, so the agent understands the consequence is externally observable rather than internal bookkeeping. It also documents the timezone and 15-minute granularity as fixed constraints. It stops short of saying whether a snooze can be undone or what happens to an existing snooze.

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

Conciseness5/5

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

Three sentences, front-loaded with what the tool does and its hard constraints, then the approval gate. No filler, and every clause carries either scope, a constraint, or a safety condition.

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?

For a six-parameter mutation with an 83%-documented schema and no output schema, the description covers purpose, timezone, granularity, side-effect visibility, and the approval requirement. The remaining gap is the absence of any hint about what the tool returns or how failures (e.g., conversation_id mismatch) are reported, though that is partly recoverable from the schema.

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 coverage is 83%, so the schema already documents date format, time granularity, contact, index, and conversation_id's refusal behavior. The description adds only the Brasília timezone assumption, which is genuinely useful context the schema lacks, but nothing about how comment is surfaced or how index and contact interact. Baseline 3 applies when the schema does most of the work.

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?

The description gives a specific verb and resource ('Snooze a conversation') plus the defining scope: until an absolute date and time, in Brasília time, on 15-minute steps, with an optional internal comment. That distinguishes it in substance from the sibling aspa_snooze (relative snooze), but the differentiation is only implicit — the sibling is never named.

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 states a hard precondition clearly: call only after the user explicitly approved this exact action in the conversation. That is real when-to-use guidance. What's missing is an explicit rule for choosing between this tool and aspa_snooze, which an agent facing both must infer from the 'specific date and time' phrasing.

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

Deploy Server

Other Tools