Skip to main content
Glama

Duvo MCP

by io.github.duvoai

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

TableJSON 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. Dates show when Glama detected each change.

  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"
-]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"
+]
  2. 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"
+]
  3. 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"
+]
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses important non-obvious behavior: it requires the Notification Center feature, and returns 404 in four distinct cases, including the subtle case where no live member matches the given filters. It also clarifies the default counting behavior versus filtered counting.

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 three dense sentences with no filler. It leads with the core action and result, then explains filtering semantics, then error conditions. Each sentence carries meaningful behavioral or contextual information.

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 read-only tool with six parameters and no output schema, the description is thorough: it identifies the output components, explains filter behavior and defaults, states ownership/team constraints, lists all relevant 404 cases, and clarifies the feature prerequisite. Nothing an agent needs to select or invoke this tool correctly is missing.

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 parameters are already well documented. The description adds value by explaining that type/severity/minSeverity narrow the live-member counts rather than changing which batch is returned, and that counts include every live member by default. It does not deeply annotate agents or team_id because the schema already covers them well.

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 names a specific verb and resource ('Get a single notification batch by id') and details the returned derived values: per-type live-member counts, unread count, and worst severity. It also positions the tool against the feed by stating it serves batches the caller can no longer see there, which distinguishes it from 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?

The description clearly states when this tool is used: for cold deep links and sidebar retention of batches that are no longer visible in the feed. It does not explicitly name sibling tools or give a 'use X instead when...' rule, but the context signals and 'feed' references make the intended usage reasonably clear.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation2/5

Despite detailed descriptions, many tool names are highly ambiguous, with multiple tools covering the same conceptual actions (e.g., acceptClarityCaptureSuggestion vs. acceptClarityTeamAssignmentSuggestion, or the many deleteClarity*Interview tools). The set is so large that distinguishing between, say, listClarityFolders, listClarityProcesses, and listClarityProcessSummaries requires reading deep into descriptions, reducing agent selection accuracy.

Naming Consistency4/5

The naming convention is predominantly verb_noun (e.g., createClarityProcess, listAgents, deleteQueue), and is remarkably consistent across the 316 tools. There are only minor deviations, such as 'fileSuggestedClarityProcesses' (verb + adjective noun) and 'bulkUpdateCasePriority' (where 'bulk' could be seen as a prefix), but overall the pattern holds strongly.

Tool Count1/5

With 316 tools, this server is extremely oversized for any single agent to manage effectively. The massive number of tools suggests poor modularization—many of these tools likely belong in separate, smaller servers focused on specific domains (e.g., Clarity, Pulse, Agent management). The cognitive load for an agent to choose from 316 options is very high, leading to frequent misselection.

Completeness4/5

The tool surface covers an extraordinarily wide range of operations across the Duvo platform: agents, runs, cases, queues, Clarity processes, skills, integrations, notifications, teams, and more. Most resource types have full CRUD and lifecycle management. Notable minor gaps exist (e.g., no tools for managing specific notification batch severities dynamically, and some interview management is missing batch operations), but for the platform's scope, coverage is impressively thorough.

Resources