Adobe VIP Marketplace Docs MCP Server

List VIPMP API endpoints

list_vipmp_endpoints

Read-onlyIdempotent

Get a complete Markdown table of all HTTP endpoints (method and path) documented in the Adobe VIP Marketplace Partner API docs, grouped by resource area for quick reference.

Instructions

Extract every HTTP endpoint (method + path) documented across the whole VIPMP docs. Returns a Markdown table grouped by resource area.

Served from the pre-built index (milliseconds) when available. Falls back to live extraction across the sitemap (~30s cold, ~5s warm) if no index is present. Call rebuild_vipmp_index to refresh locally.

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": "list_vipmp_endpoints"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.17.0Sep 1, 2026
Removedv0.13.1Jul 27, 2026
First observedv0.9.0Jun 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already signal read-only, idempotent, non-destructive behavior. The description adds valuable beyond-annotation context: it discloses the pre-built index fast path, the fallback to live extraction with realistic latency estimates (~30s cold, ~5s warm), and how to refresh the local index. This is rich, honest behavioral detail.

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?

Three tightly written sentences, each earning its place: outcome and output format, performance and fallback behavior, and cache refresh guidance. The most important information is front-loaded, with no redundant phrasing.

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 zero-parameter tool with an output schema and strong annotations, the description covers everything needed for correct selection and invocation: what is returned, how it is sourced, expected latency, fallback behavior, and how to improve freshness. No critical information is missing.

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?

The tool accepts zero parameters, so there are no parameter semantics to document. The schema is empty and description coverage is effectively 100%, making this baseline appropriate; the description's scope language further clarifies what the parameterless call does.

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 action and resource: extract every HTTP endpoint (method + path) across the VIPMP docs. It also specifies the return format, a Markdown table grouped by resource area, which clearly distinguishes it from sibling tools like describe_vipmp_endpoint or list_vipmp_error_codes.

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 scope 'every HTTP endpoint documented across the whole VIPMP docs' provides clear context for when to use this tool. It doesn't explicitly name alternatives or exclusion conditions, but the phrase 'whole VIPMP docs' and the mention of calling rebuild_vipmp_index to refresh imply the appropriate usage context.

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