Skip to main content
Glama

Duvo MCP

by io.github.duvoai
OverviewDiscussionsAdmin

Get Notification Batch

getNotificationBatch
Read-onlyIdempotent

Get a single notification batch by id for the authenticated user, with per-type live-member counts, unread count, and worst severity. Serves cold deep links and sidebar retention for batches the caller can no longer see in the feed. Counts every live member by default; the optional type/severity/minSeverity filters narrow them to matching members only, exactly as the feed narrows a batch row it returns under the same filters. Requires the Notification Center feature; returns 404 when it is not enabled for the team, the batch does not exist, it belongs to another recipient/team, or no live member matches the given filters.

Input Schema

NameRequiredDescriptionDefault
idYesThe notification batch's unique identifier
typeNoCount only live members of this type. Omit to count every live member.
agentsNoWhen 'mine', 404 unless the batch's agent is one the authenticated user created. Pass it alongside the feed's My agents filter so a retained batch cannot come back narrowed on type and severity but not on ownership.
team_idNoDuvo team UUID to operate on. API keys are pinned to a single team — omit this (it falls back to the key's team) or pass that same team; a different team is rejected. OAuth callers, who can span multiple teams, should pass the target team here.
severityNoCount only live members with exactly this severity. Mutually exclusive with minSeverity. One of: info, warning, critical, success.
minSeverityNoCount only live members at or above this urgency. Least to most urgent: success < info < warning < critical. Mutually exclusive with severity.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "connection_broken",
-  "case_failed",
-  "critical_case_issue",
-  "case_issue",
-  "critical_eval_issue",
-  "eval_issue",
-  "job_issue",
-  "job_done",
-  "background_job",
-  "schedule_issue",
-  "config_proposal"
-]New value: +[
+  "connection_broken",
+  "login_broken",
+  "case_failed",
+  "critical_case_issue",
+  "case_issue",
+  "critical_eval_issue",
+  "eval_issue",
+  "job_issue",
+  "job_done",
+  "background_job",
+  "schedule_issue",
+  "config_proposal",
+  "routine_candidate"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "connection_broken",
-  "case_failed",
-  "critical_case_issue",
-  "case_issue",
-  "critical_eval_issue",
-  "eval_issue",
-  "job_issue",
-  "job_done",
-  "background_job",
-  "schedule_issue"
-]New value: +[
+  "connection_broken",
+  "case_failed",
+  "critical_case_issue",
+  "case_issue",
+  "critical_eval_issue",
+  "eval_issue",
+  "job_issue",
+  "job_done",
+  "background_job",
+  "schedule_issue",
+  "config_proposal"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "connection_broken",
-  "critical_eval_issue",
-  "eval_issue",
-  "job_issue",
-  "job_done",
-  "background_job",
-  "schedule_issue"
-]New value: +[
+  "connection_broken",
+  "case_failed",
+  "critical_case_issue",
+  "case_issue",
+  "critical_eval_issue",
+  "eval_issue",
+  "job_issue",
+  "job_done",
+  "background_job",
+  "schedule_issue"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "connection_broken",
-  "job_issue",
-  "eval_issue",
-  "job_done",
-  "background_job",
-  "schedule_issue"
-]New value: +[
+  "connection_broken",
+  "critical_eval_issue",
+  "eval_issue",
+  "job_issue",
+  "job_done",
+  "background_job",
+  "schedule_issue"
+]
  5. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the readOnly/idempotent annotations: default counting of every live member, filter-narrowing semantics matching the feed, the Notification Center feature requirement, and the exact conditions that produce a 404. This is exactly the kind of context an agent needs before calling a retrieval tool.

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?

Four dense sentences, front-loaded with purpose and return data, followed by use case, filter behavior, and error conditions. No sentence is redundant, and complexity justifies the length.

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?

Given six parameters, rich enum-backed schema, and no output schema, the description covers purpose, return fields, filtering behavior, feature gating, and 404 cases. An agent has enough information to call it correctly without opening the schema.

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 coverage is 100%, so the baseline is 3. The description adds cross-tool meaning by explaining that type/severity/minSeverity filters narrow counts exactly as the feed narrows a batch row, and that counts default to every live member, but it does not add much beyond the detailed schema for agents/team_id.

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?

States a specific verb and resource: get a single notification batch by id, and specifies the returned data (per-type live-member counts, unread count, worst severity). It is clearly distinguishable from feed/count siblings like getNotificationFeed and getNotificationCounts.

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?

Explains the intended context: cold deep links and sidebar retention for batches no longer visible in the feed. This tells the agent when the tool is useful, though it does not explicitly name getNotification or getNotificationFeed as alternatives for other cases.

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

All Duvo MCP 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