Skip to main content
Glama
Sign In
mc-next-mcp-server

mc-next-mcp-server

by supanmaniar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List Marketing Cloud Next / Data 360 API endpoints

mcnext_list_endpoints

Find the right API endpoint by filtering 445 endpoints across families, groups, kinds, methods, or free text search.

Instructions

Browse the 445 endpoints across 3 API families (mc-next: 27, data360: 35, data360-connect: 383) and 44 resource groups. Use this first to discover the endpoint id you need. Filter by family, group, kind, method, or a free-text search.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mcnext_list_endpoints"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoEndpoint kind. "query" = list, "read" = get one, "action" = non-CRUD operation.
groupNoResource group, e.g. "Content", "Activations", "Segments", "Query API V2".
limitNoMax results (default 50).
familyNoAPI family. "mc-next" = Marketing Cloud Next content/CMS, "data360" = Data 360 core, "data360-connect" = Data 360 Connect.
methodNo
searchNoFree-text search over id, name, path and description.
includeDestructiveNoInclude destructive endpoints (DELETE, delete/remove/cancel actions). Default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavior. 'Browse' implies a read-only, non-destructive operation, but the description does not explicitly state it, nor does it mention pagination, response format, rate limits, or any side effects. It does add the counts (445, 27, 35, 383, 44) which are useful context. Given the tool's simplicity, this is adequate but not rich. A 3 reflects the moderate disclosure.

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?

Two sentences with zero waste. The first sentence packs the scope (445 endpoints, families, groups) and the second sentence gives the usage directive and filter options. Front-loaded and to the point.

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?

The description provides the core purpose, scope, and usage direction. It lacks an explicit statement of the return format (e.g., list of endpoint metadata with id, name, path), but that is inferable from the tool type and the mention of 'discover the endpoint id.' For a listing/discovery tool with no output schema, this is sufficient. A 5 would be given if it detailed pagination or response structure, but the tool is simple enough.

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 coverage is 86% (6 of 7 parameters have descriptions), so the schema already documents most parameters. The description adds a summary of filters: 'Filter by family, group, kind, method, or a free-text search.' This helps agents understand the grouping but does not add syntax or format details beyond the schema. The missing parameter (method) is covered by its enum. Baseline 3 is appropriate.

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 specific verb ('Browse') and resource ('445 endpoints across 3 API families... 44 resource groups'), and clarifies its role as a discovery tool: 'Use this first to discover the endpoint id you need.' It clearly distinguishes from siblings like mcnext_query or mcnext_read, which execute operations on specific endpoints. No ambiguity.

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 explicitly states when to use it: 'Use this first to discover the endpoint id you need.' This gives clear context and implies it precedes other mcnext_* tools. It does not explicitly name alternatives or conditions to avoid, but the purpose is unambiguous given the sibling tool names. A 4 is appropriate; a 5 would require explicit exclusions.

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

Deploy Server

Other Tools