Skip to main content
Glama
Sign In

ShortSync

by app.shortsync
OverviewDiscussionsAdmin

Mark conversations as seen

mark_conversations_seen

Marks one or more inbox conversations as seen for the workspace by setting last_seen_at = now. Same effect as scrolling the rows into view in the inbox UI. Local by default; set send_read_receipt to also show the participant a read receipt on eligible Instagram DMs. Rows not in the workspace are silently ignored. Returns the ids that were actually updated.

Input Schema

NameRequiredDescriptionDefault
workspace_idYesWorkspace whose inbox to update. Required — get one from list_workspaces.
idempotency_keyNoOptional client-generated key (e.g., a UUID) to make retries safe. Identical calls with the same key within 10 minutes return the original result instead of running the write twice.
conversation_idsYesList of dm_conversations.id values to mark as seen (max 500). Get ids from list_inbox_conversations.
send_read_receiptNoAlso send Instagram's read receipt, so the participant sees their message was seen. Applies to Instagram DMs whose last message is theirs and under 24 hours old; others are skipped. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / send_read_receipt
      Added value: +{
+  "description": "Also send Instagram's read receipt, so the participant sees their message was seen. Applies to Instagram DMs whose last message is theirs and under 24 hours old; others are skipped. Default false.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the write and non-destructive annotations, it discloses that the default effect is local, that the optional receipt is participant-visible on eligible Instagram DMs, and that out-of-workspace rows are silently ignored. It also explains the concrete timestamp behavior and states that only IDs actually updated are returned, which is especially useful without an output schema.

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?

Five short sentences front-load the operation and then cover the UI equivalent, optional external effect, ignore behavior, and result. There is no filler or redundant recitation of the parameter list.

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

Completeness5/5

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

Together with the schema's ID sources, 500-item cap, receipt eligibility criteria, and idempotency-window details, the description is sufficient to select and invoke the tool correctly. Although there is no output schema, the description supplies the essential return contract: the IDs that were actually updated.

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?

Schema description coverage is 100%, so the schema already documents every parameter. The description still adds useful cross-parameter semantics: workspace_id scopes conversation_ids, mismatched rows are ignored, and leaving send_read_receipt false keeps the operation local, while the schema supplies the remaining size, eligibility, and retry details.

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?

It uses a specific verb and resource—marking one or more workspace inbox conversations as seen—and identifies the exact state change, setting last_seen_at to the current time. The seen-state semantics and inbox UI analogy distinguish it from sibling actions such as liking conversations, marking them spam, or retrieving their messages.

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?

The UI analogy and local-by-default behavior make the intended use clear, and the description explicitly says to set send_read_receipt when the participant should also see a read receipt. It does not provide explicit when-not guidance or route the agent to alternatives such as mark_conversations_spam or sync_inbox.

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

All ShortSync toolsInspect
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.

Resources