Skip to main content
Glama
Sign In

Nevent MCP

by io.github.nevent-dev
OverviewDiscussionsAdmin

nevent_update_segment

Destructive

Modify an existing segment's name and/or filter definition. Call this after nevent_get_segment to inspect the current definition before changing it. At least one of name or definition must be provided. After update, call nevent_segment_preview to confirm the new audience count before scheduling a campaign.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "segment_id": "<segment_id>"
    },
    "name": "nevent_update_segment"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoNew human-readable name for the segment. Omit to leave unchanged.
definitionNoReplacement segment DSL. The full definition is replaced when provided. Criteria in the same stanza are OR-combined: a fan matches the stanza if ANY criterion matches. Stanzas are AND-combined: a fan must match EVERY stanza. Omit to leave the existing definition unchanged.
segment_idYesIdentifier of the segment to update. Use nevent_list_segments to get valid segment IDs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / definition / properties / stanzas / items / properties / criteria / items / properties / modifiers / description
      Previous value: -"ADVANCED: Usually OMIT this field entirely. Only include when the user explicitly asks for:\n- \"at least X times\" → { frequency: { count: X, operator: \"gte\" } }\n- \"in the last X days\" → { time_range: { value: X, unit: \"day\" } } (value MUST be > 0)\nIf not asked for frequency or recency, DO NOT include modifiers."New value: +"ADVANCED: Usually OMIT this field entirely. Only include when the user explicitly asks for:\n- \"at least X times\" → { frequency: { count: X, operator: \"gte\" } }\n- \"in the last X days\" → { time_range: { value: X, unit: \"days\" } } (value MUST be > 0; unit is one of days, weeks, months, years)\nIf not asked for frequency or recency, DO NOT include modifiers."
  2. Changed3 schema fields changed
    • changedInput schema / properties / definition / description
      Previous value: -"Replacement segment DSL. The full definition is replaced when provided. Omit to leave the existing definition unchanged."New value: +"Replacement segment DSL. The full definition is replaced when provided. Criteria in the same stanza are OR-combined: a fan matches the stanza if ANY criterion matches. Stanzas are AND-combined: a fan must match EVERY stanza. Omit to leave the existing definition unchanged."
    • changedInput schema / properties / definition / properties / stanzas / description
      Previous value: -"Array of stanzas (OR logic). Each stanza contains criteria (AND logic)."New value: +"Array of stanzas. Stanzas are AND-combined: a fan must match EVERY stanza. Criteria inside one stanza are OR-combined, so a fan matching ANY of them matches that stanza."
    • changedInput schema / properties / definition / properties / stanzas / items / properties / criteria / description
      Previous value: -"Criteria combined with AND logic within this stanza."New value: +"Criteria in the same stanza are OR-combined: a fan matches the stanza if ANY criterion matches. Stanzas are AND-combined, so a fan must match EVERY stanza."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, so the mutation nature is known. The description adds behavioral context: it notes the update is for existing segments, suggests inspecting before changing to avoid unintended overwrites, and implies partial updates (only name or definition changes if only one is provided). It does not explicitly state that the definition is fully replaced when provided, but that is covered in the schema's parameter description. Given the annotations, this is adequate.

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 two sentences with no filler. It front-loads the primary purpose, then gives the essential workflow and constraint. Every word earns its place, and it avoids redundancy with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a complex nested definition parameter, the description does not explain the DSL, but that is fully covered by the schema. The description provides the necessary workflow (get → update → preview) and the constraint on parameters. It lacks an explicit warning about full replacement, but that is in the schema. Overall, an agent has sufficient information to call the tool correctly.

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 each parameter is fully documented. The description adds a cross-parameter constraint not present in the schema: 'At least one of name or definition must be provided.' This is valuable semantic information that helps the agent avoid invalid calls. It also provides context on how parameters relate (e.g., inspecting before update), which goes beyond the schema.

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 clearly states the action ('Modify an existing segment's name and/or filter definition') with a specific verb and resource, and it distinguishes from siblings like create_segment and get_segment by implying this is for updates only. It also specifies the condition that at least one field must be provided, making the tool's role unambiguous.

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?

Provides explicit workflow guidance: call nevent_get_segment first to inspect the current definition, and nevent_segment_preview afterward to confirm the audience count. It also implies when not to use this tool (when creating a segment) and the constraint that at least one of name or definition must be provided. This is clear and actionable.

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

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