Loading ToolBench
MCP server for Novu notification platform, providing tools to manage notifications, workflows, subscribers, agents, environments, integrations, preferences, and conversations via the Novu API
This is a well-structured Novu MCP server with consistently good naming, clear descriptions, and complete input schemas for all 6 tools. Tool names follow verb_noun convention (whoami, create_agent, get_agents, get_agent, connect_agent, update_agent). All tools have substantive descriptions (100+ characters, with rich context). Input parameters are properly typed with Zod schemas and include descriptions for every field. The server demonstrates mature patterns: idempotency key support, environment switching, and thoughtful parameter constraints (e.g., identifier regex validation). However, there are gaps in output schema documentation (tool responses are not formally described in the tool definitions), error recovery guidance is minimal (error messages exist but don't guide LLM retry logic), and some parameter descriptions could be more prescriptive about valid ranges and formats. The `create_agent` and `update_agent` tools have complex, interdependent parameters (e.g., runtime type determines which fields apply) that are documented but could be clearer in preventing misconfiguration. No tool annotations (readOnlyHint, destructiveHint) are present, which would improve protocol readiness. Overall solid production-ready definitions with room for maturity in error guidance and output schema formalization.
Get instructions to connect a channel (Slack, Telegram, Email, WhatsApp, Teams, Agent Chat, iMessage) to an existing Novu agent. Call this after create_agent, or with an identifier from get_agents. Returns the Novu CLI playbook URL plus mandatory flags so you attach a channel to THIS agent — do not create a second agent, and never pass --keyless. Never accept channel secrets (Slack tokens, Telegram bot tokens, Sendblue keys) as tool arguments.
Create a Novu agent in the current environment. Defaults to a managed (Novu-hosted) agent using the demo novu-anthropic integration — no Anthropic API key required. Pass runtime:'self-hosted' for a bridge agent that runs in your app. For managed agents with your own credentials, pass integrationId from get_integrations (entries where kind==='agent'). Never pass an Anthropic API key to this tool. Optional managed fields: systemPrompt, model, tools, mcpServers, skills. After success, call connect_agent with the returned identifier to connect a channel. Do not ask the user for Slack, Telegram, or other channel tokens. To route a workflow through this agent, call update_workflow (or create_workflow) with agent: { identifier: "<slug>" }.
Retrieve a single agent by its identifier (slug), including runtime config when managed.
List agents in the current environment with cursor pagination. Filter by partial identifier when needed.
Output schemas are not formally documented. Tool definitions show input parameters but do not declare what fields, types, or structure the response contains. LLMs cannot plan downstream calls (e.g., what field from create_agent holds the identifier to pass to connect_agent?) without this information.
Error responses lack recovery guidance. Tool handlers catch errors and return generic messages like 'Error: Failed to execute {toolName}'. When an LLM receives a 404 or validation error, it should be told: is this retryable? Should I call a different tool first? What was the constraint I violated?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 83 | <=2025-11-25 | v2 |
Update an existing Novu agent by its identifier (slug). Provide at least one field to change. In production environments only active and bridgeUrl may be modified — name, description, and behavior fields return 403. Behavior fields (acknowledgeOnReceived, reactionOnResolved, subscriberAccess) are flattened and merged on the server.
Show who is currently authenticated (name, email) by verifying the credential (OAuth token or legacy API key) against the Novu API, and report the active server region
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are declared. The MCP spec (2026-07-28) supports annotating tools with risk levels, but this server does not use them. whoami, get_agents, get_agent should be marked readOnly; create_agent, connect_agent, update_agent should be marked destructive; all support idempotency and could declare idempotentHint.
create_agent and update_agent have interdependent parameters (runtime type determines which fields apply) but parameter descriptions do not explicitly state mutual exclusivity or field applicability. For example, 'bridgeUrl is required when runtime=self-hosted' is mentioned in create_agent description but not enforced in the schema or documented in the bridgeUrl parameter itself.
get_agents accepts 'identifier' as a filter for partial matching, but the description does not specify: case sensitivity? Substring vs. prefix matching? Regex? This ambiguity invites LLM errors when filtering.
create_agent description references fields like 'tools', 'mcpServers', 'skills' for managed agents but provides no guidance on their structure, valid values, or format. LLMs cannot construct these arrays without examples or formal constraints.