Skip to main content
Glama

Soclo

by app.soclo
OverviewDiscussionsAdmin

Mark notifications as read

soclo_notifications_mark_read
DestructiveIdempotent

Mark one notification (pass id) or all unread notifications (omit id) as read. Without confirm:true this returns a preview and marks nothing; pass confirm:true only after the owner agrees. Free. Needs manage:settings. After an uncertain result read soclo_notifications_list before any further write.

Input Schema

NameRequiredDescriptionDefault
idNo
confirmNo
clientRequestIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / definitions
      Added value: +{
+  "s1": {
+    "format": "uuid",
+    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+    "type": "string"
+  }
+}
    • addedInput schema / properties / clientRequestId / $ref
      Added value: +"#/definitions/s1"
    • removedInput schema / properties / clientRequestId / format
      Removed value: -"uuid"
    • removedInput schema / properties / clientRequestId / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • removedInput schema / properties / clientRequestId / type
      Removed value: -"string"
    • addedInput schema / properties / id / $ref
      Added value: +"#/definitions/s1"
    • removedInput schema / properties / id / format
      Removed value: -"uuid"
    • removedInput schema / properties / id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • removedInput schema / properties / id / type
      Removed value: -"string"
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses the preview-without-confirm behavior, the required owner consent gate, cost (Free), authorization scope (manage:settings), and a recovery path after uncertain results. It does not contradict the destructive/write annotations.

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?

The description is front-loaded with the core action and confirm gate, then adds short operational notes. Every sentence carries useful selection or safety information without waste.

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?

For a mutating notification tool with rich annotations and no output schema, the description supplies the critical safety, permission, cost, and recovery context. The only minor gap is clientRequestId, which does not undermine correct invocation.

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 0%, so the description must carry parameter meaning. It explains id (single notification vs omit for all) and confirm (preview vs actual write), but leaves clientRequestId undocumented.

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: mark notifications as read, with explicit single-id vs all-unread modes. It is clearly distinguishable from sibling read-oriented tools such as soclo_notifications_list.

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

Usage Guidelines5/5

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

It explicitly says to omit id to mark all unread, that confirm:true should be passed only after owner agreement, and that soclo_notifications_list should be read after an uncertain result before further writes. These are concrete when/when-not and recovery instructions.

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

All Soclo 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