Skip to main content
Glama

Duvo MCP

by io.github.duvoai

Get Notification Feed

getNotificationFeed
Read-onlyIdempotent

List the notification feed for the authenticated user's current team, most recent activity first. Each item is either an individual notification or a notification batch (a per-agent group of job_issue/eval_issue/job_done/schedule_issue notifications). Filter with type, unread, and either severity (exact match) or minSeverity (threshold; the two are mutually exclusive); paginate with limit/cursor. Either severity filter also narrows a surfaced batch's counts to its qualifying members, and hides a batch with no qualifying live member. The feed is eventually consistent — a batch's counts can lag a concurrent write by one page fetch. Requires the Notification Center feature; returns 404 when it is not enabled for the team.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoOnly return individual notifications of this type and batches with at least one live member of it.
limitNo
agentsNoWhen 'mine', only return notifications for agents the authenticated user created. connection_broken notifications are always returned regardless, because they are not about an agent: a broken connection is only notified to the people who can act on it or escalate it, so filtering by agent authorship would hide it from the reader it was addressed to.
cursorNo
unreadNoIf true, only return unread individual notifications and batches with at least one unread live member.
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.
severityNoOnly return individual notifications with exactly this severity, and batches with at least one live member of it. A batch's counts then describe only those members. Mutually exclusive with minSeverity. One of: info, warning, critical, success.
minSeverityNoOnly return individual notifications at or above this urgency, and batches with at least one live member at or above it. A batch's counts and worst severity then describe only its members at or above the threshold. Least to most urgent: success < info < warning < critical. Mutually exclusive with severity.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description does not contradict - it describes a list operation. Beyond that, the description exposes genuinely valuable non-obvious behavior: the batch semantics (per-agent grouping, counts narrowing, hiding batches with no qualifying live member) and eventual consistency lag. It also states the 404-when-feature-not-enabled case. This is strong disclosure that goes beyond the annotation surface, though it does not detail the exact return shape (no output schema exists, so shapes remain unstated).

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 economical and information-dense without padding. It front-loads the core purpose in the first sentence, then packs the filtering and batch behavior into a few sentences. No wasted clauses; each sentence adds a distinct fact (purpose, filtering modes, batch count narrowing, eventual consistency, feature requirement/404).

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, idempotent list operation with no output schema and complex filtering behavior (8 parameters, enums on 4, mutual exclusion, batching), the description covers what an agent needs: what is listed, ordering, filter semantics, batch narrowing, pagination, eventual consistency, and the 404 edge case. The return format remains unspecified, but absent an output schema that is a gap; however given the strong parameter-level detail in the schema (75% coverage) and the description's own coverage, the tool is effectively fully specified for correct invocation.

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 75%, so the schema documents fields like type, unread, severity, minSeverity, agents, and team_id fairly well. The description still adds important cross-parameter semantics: the mutual exclusivity of severity and minSeverity, the meaning of minSeverity ordering (success < info < warning < critical, which also appears in the schema property description but is reinforced), and the order of results ('most recent activity first'). The description also clarifies the interplay between filters and batch counts, which the schema property text covers for some parameters but the description ties together. A 4 rather than 5 because team_id and cursor semantics are best explained in the schema and the description does not add much beyond what is there.

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 clear verb ('List') and resource ('notification feed for the authenticated user's current team'), specifies order ('most recent activity first'), and explains item types. It is distinct from siblings like listNotifications and getNotificationCounts, and the opening sentence alone lets an agent understand what it returns.

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 gives explicit filtering semantics (type, unread, severity vs minSeverity mutual exclusion, pagination with limit/cursor) and the eventual-consistency caveat. It does not name sibling tools like listNotifications or getNotification as alternatives, but the filtering guidance is clear enough that an agent knows when to use it; a small deduction for not mentioning 'use getNotification for a single notification' or 'use getNotificationCounts for counts only.'

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