Skip to main content
Glama
Sign In

Nevent MCP

by io.github.nevent-dev
OverviewDiscussionsAdmin

nevent_segment_execute

Read-only

Execute a segment definition and retrieve matching contacts with pagination. SEMANTICS: 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. To require A AND B, put them in separate stanzas; to accept A OR B, put both in the same stanza.

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": {
      "definition": "<definition>"
    },
    "name": "nevent_segment_execute"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoZero-based page index (default 0)
page_sizeNoResults per page (max 100, default 20)
definitionYesSegment DSL. 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. To require A AND B, put them in separate stanzas; to accept A OR B, put both in the same stanza.

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: -"Segment DSL: stanzas are OR-combined, criteria within each stanza are AND-combined"New value: +"Segment DSL. 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. To require A AND B, put them in separate stanzas; to accept A OR B, put both in the same stanza."
    • 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/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, lowering the bar for behavioral disclosure. The description adds value by explaining the OR-within-stanza / AND-across-stanzas semantics and confirming the tool returns contacts, which is meaningful behavioral context beyond what the annotations express.

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 compact and well-structured: it front-loads the primary purpose, then explains the crucial boolean semantics in a few short sentences. Every sentence earns its place, and the examples clarify without bloating the text.

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 schema, the rich input schema plus the description's semantic explanation make the invocation requirements clear. Pagination is mentioned and the parameters are documented. The main gap is not addressing when to use this over the sibling preview or analytics tools, but the essential calling context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description repeats the OR/AND semantics also present in the schema descriptions, and adds a helpful 'A AND B vs A OR B' example, but it does not introduce meaning that is absent from 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 uses a specific verb and resource: 'Execute a segment definition and retrieve matching contacts with pagination.' This clearly distinguishes the tool from sibling segment tools like nevent_get_segment, nevent_list_segments, nevent_create_segment, and nevent_update_segment, which all have different intents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear operational context: run a segment definition and get matching contacts, optionally using pagination. However, it does not explicitly state when to prefer this tool over closely related siblings such as nevent_segment_preview or nevent_analytics_query, nor does it mention any exclusions or alternatives.

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