How do I use Crownpeak DQM MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Crownpeak DQM MCP Server run a quality check on our homepage and show me any issues found" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Crownpeak DQM MCP Server

by ptylr

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Crownpeak DQM MCP Server

A portable Model Context Protocol (MCP) server that wraps the Crownpeak DQM CMS REST API. This server exposes agent-friendly tools for quality checking, asset management, checkpoint monitoring, and more.

Features

Complete API Coverage: All 15 DQM API endpoints implemented and tested
Dual Transport Support: Run as stdio (desktop clients) or HTTP server (cloud hosting)
Production Ready: TypeScript, error handling, rate limiting, request timeouts
Docker Native: Containerized deployment with health checks
Portable: Deploy anywhere - AWS, Azure, GCP, Netlify, Vercel, Fly.io, Kubernetes
Safe by Default: Read-only operations by default, destructive tools behind feature flag
Agent Optimized: Task-oriented tools designed for AI agents
Fully Tested: 100% integration test coverage against live DQM API

Related MCP server: Concrete CMS MCP Server

Quick Start

Prerequisites

Node.js 20+
npm (included with Node.js)
Crownpeak DQM API key

Installation

# Clone repository
git clone <repository-url>
cd crownpeak-dqm-node-mcp

# Install dependencies
npm install

# Copy environment template
cp .env.example .env

# Edit .env and add your API key
# DQM_API_KEY=your_api_key_here

Build

npm run build

Usage

Local Stdio Mode (Desktop Clients)

For use with desktop MCP clients like Claude Desktop:

# Run directly
npm start

# Or with environment variables
DQM_API_KEY=your_key npm start

Claude Desktop Configuration

Add to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "crownpeak-dqm": {
      "command": "node",
      "args": ["/absolute/path/to/crownpeak-dqm-node-mcp/dist/index.js"],
      "env": {
        "DQM_API_KEY": "your_api_key_here"
      }
    }
  }
}

Claude Desktop Usage Examples

Once configured, you can use natural language to interact with the DQM API through Claude:

Example 1: Quality Check a Website

"Get the content from https://www.crownpeak.com and test it against DQM for quality issues"

Claude will:

Use run_quality_check with your website ID and the URL
Create an asset in DQM
Retrieve and display all quality issues found

Example 2: Check Spelling on a Page

"Run a spellcheck on https://www.example.com using my DQM website"

Claude will:

Use spellcheck_asset to check the URL
Report any misspellings found

Example 3: Review Quality Issues

"Show me all the quality checkpoints configured for my website and then check the homepage against them"

Claude will:

List your websites with list_websites
List checkpoints with list_checkpoints
Run a quality check on your homepage
Present a detailed report

Example 4: Asset Management

"Search for all assets from www.crownpeak.com in my DQM account and show me the ones with the most issues"

Claude will:

Search assets with search_assets
Get issues for each with get_asset_issues
Sort and present the results

Example 5: Get Highlighted Content

"Get the HTML content for asset [ID] with all quality issues highlighted"

Claude will:

Use get_asset_pagehighlight to get highlighted HTML
Display the content with issues marked

HTTP Server Mode (Cloud Hosting)

For remote hosting and API access:

# Start HTTP server
npm run start:http

# Server will start on port 3000 (configurable via PORT env var)

Test endpoints:

# Health check
curl http://localhost:3000/healthz

# List available tools
curl http://localhost:3000/tools

# Call a tool
curl -X POST http://localhost:3000/call \
  -H "Content-Type: application/json" \
  -d '{
    "tool": "list_websites",
    "arguments": {}
  }'

Docker Deployment

Using Docker Compose (Recommended)

# Create .env file with your API key
echo "DQM_API_KEY=your_api_key_here" > .env

# Start the server
docker-compose up -d

# View logs
docker-compose logs -f

# Stop the server
docker-compose down

Using Docker Directly

# Build the image
docker build -t crownpeak-dqm-mcp .

# Run the container
docker run -d \
  --name crownpeak-dqm-mcp \
  -p 3000:3000 \
  -e DQM_API_KEY=your_api_key_here \
  crownpeak-dqm-mcp

# View logs
docker logs -f crownpeak-dqm-mcp

# Stop the container
docker stop crownpeak-dqm-mcp

Cloud Deployment

AWS

AWS ECS/Fargate

# Build and push to ECR
aws ecr create-repository --repository-name crownpeak-dqm-mcp
docker tag crownpeak-dqm-mcp:latest <account-id>.dkr.ecr.<region>.amazonaws.com/crownpeak-dqm-mcp:latest
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/crownpeak-dqm-mcp:latest

# Create task definition with:
# - Image: <ecr-url>
# - Port: 3000
# - Environment: DQM_API_KEY (use Secrets Manager)
# - Health check: /healthz

# Deploy using ECS console or CLI

AWS App Runner

# Use App Runner with ECR source
# Configure:
# - Port: 3000
# - Health check: /healthz
# - Environment variable: DQM_API_KEY

Azure

Azure Container Instances

az container create \
  --resource-group myResourceGroup \
  --name crownpeak-dqm-mcp \
  --image crownpeak-dqm-mcp:latest \
  --dns-name-label crownpeak-dqm \
  --ports 3000 \
  --environment-variables DQM_API_KEY=your_key \
  --cpu 1 --memory 0.5

Azure Container Apps

az containerapp create \
  --name crownpeak-dqm-mcp \
  --resource-group myResourceGroup \
  --environment myEnvironment \
  --image crownpeak-dqm-mcp:latest \
  --target-port 3000 \
  --ingress external \
  --env-vars DQM_API_KEY=secretref:dqm-api-key

GCP

Cloud Run

# Build and push to GCR
gcloud builds submit --tag gcr.io/<project-id>/crownpeak-dqm-mcp

# Deploy to Cloud Run
gcloud run deploy crownpeak-dqm-mcp \
  --image gcr.io/<project-id>/crownpeak-dqm-mcp \
  --platform managed \
  --region us-central1 \
  --allow-unauthenticated \
  --set-env-vars DQM_API_KEY=your_key \
  --port 3000

GKE (Kubernetes)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crownpeak-dqm-mcp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: crownpeak-dqm-mcp
  template:
    metadata:
      labels:
        app: crownpeak-dqm-mcp
    spec:
      containers:
      - name: crownpeak-dqm-mcp
        image: gcr.io/<project-id>/crownpeak-dqm-mcp:latest
        ports:
        - containerPort: 3000
        env:
        - name: DQM_API_KEY
          valueFrom:
            secretKeyRef:
              name: dqm-secrets
              key: api-key
        livenessProbe:
          httpGet:
            path: /healthz
            port: 3000
        readinessProbe:
          httpGet:
            path: /healthz
            port: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: crownpeak-dqm-mcp
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 3000
  selector:
    app: crownpeak-dqm-mcp

Vercel

Create vercel.json:

{
  "version": 2,
  "builds": [
    {
      "src": "dist/http.js",
      "use": "@vercel/node"
    }
  ],
  "routes": [
    {
      "src": "/(.*)",
      "dest": "dist/http.js"
    }
  ],
  "env": {
    "DQM_API_KEY": "@dqm-api-key"
  }
}

Deploy:

vercel --prod

Netlify

Create netlify.toml:

[build]
  command = "npm run build"
  publish = "dist"

[functions]
  node_bundler = "esbuild"

[[redirects]]
  from = "/*"
  to = "/.netlify/functions/server"
  status = 200

Create serverless function wrapper in netlify/functions/server.ts.

Fly.io

Create fly.toml:

app = "crownpeak-dqm-mcp"
primary_region = "iad"

[build]
  dockerfile = "Dockerfile"

[env]
  PORT = "3000"

[[services]]
  internal_port = 3000
  protocol = "tcp"

  [[services.ports]]
    port = 80
    handlers = ["http"]

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]

  [[services.http_checks]]
    interval = 10000
    timeout = 2000
    grace_period = "5s"
    method = "get"
    path = "/healthz"

Deploy:

fly launch
fly secrets set DQM_API_KEY=your_key
fly deploy

Available Tools

Discovery

list_websites: List all websites in your DQM account
get_website: Get details of a specific website

Checkpoints (Quality Rules)

list_checkpoints: List all quality checkpoints, optionally filtered by website
get_checkpoint: Get details of a specific checkpoint

Assets (Scanned Pages)

search_assets: Search for assets with optional filters
get_asset: Get details of a specific asset
get_asset_status: Check the status of an asset scan
get_asset_issues: Get all quality issues for an asset
get_asset_content: Get the HTML content for an asset
get_asset_errors: Get asset errors for a specific checkpoint with highlighted content
get_asset_pagehighlight: (Beta) Get asset content with all page highlightable issues highlighted
update_asset: Update the content of an existing asset
delete_asset: Delete a specific asset from DQM storage

Quality Checking

run_quality_check: Run a quality check on a URL or HTML content
- Accepts: websiteId, url (optional), html (optional), metadata (optional)
- Creates asset, returns issues immediately
- Rate limited to prevent overload

Spellcheck

spellcheck_asset: Run spellcheck on an asset
- Accepts: assetId, websiteId, url, html, language (optional)
- Can use existing asset or create new one automatically

Configuration

All configuration via environment variables. See .env.example for all options.

Required

DQM_API_KEY: Your Crownpeak DQM API key

Optional

DQM_API_BASE_URL: Override base URL (default: https://api.crownpeak.net/dqm-cms/v1)
PORT: HTTP server port (default: 3000)
ENABLE_DESTRUCTIVE_TOOLS: Enable delete operations (default: false)
DQM_REQUEST_TIMEOUT: Request timeout in ms (default: 30000)
MAX_CONCURRENT_QUALITY_CHECKS: Concurrent quality check limit (default: 3)

Testing Configuration

DQM_WEBSITE_ID: Website ID for integration tests
DQM_TEST_URL: URL to test against (default: https://www.crownpeak.com)

Development

Run in Development Mode

npm run dev

Run Tests

# Run unit tests
npm test

# Watch mode
npm run test:watch

# Run integration tests (requires API key and website ID in .env)
npm run test:integration

The integration test suite validates all 15 API endpoints against the live DQM API with 100% test coverage.

Linting

npm run lint

Type Checking

npm run typecheck

Architecture

src/
├── types.ts          # TypeScript type definitions
├── config.ts         # Configuration management
├── dqmClient.ts      # DQM API client
├── tools.ts          # MCP tool definitions
├── server.ts         # MCP server (stdio transport)
├── http.ts           # HTTP server entry point
├── index.ts          # Stdio entry point
└── *.test.ts         # Test files

tests/
└── integration/
    └── api-test.ts   # Integration tests for all 15 endpoints

API Client Features

Automatic dual authentication (x-api-key header + query parameter)
Request timeouts
Error handling with structured errors
Rate limiting for quality checks
Issue normalization
Proper handling of text/HTML and JSON responses
Support for form-encoded POST/PUT requests

Security

API keys loaded from environment (never hardcoded)
Non-root Docker user
Read-only operations by default
Request timeouts prevent hanging
Rate limiting prevents abuse
Comprehensive error handling (no secret leakage)

Troubleshooting

"DQM_API_KEY environment variable is required"

Set your API key in .env or pass it directly:

DQM_API_KEY=your_key npm start

Connection timeouts

Increase timeout:

DQM_REQUEST_TIMEOUT=60000 npm run start:http

Docker health check fails

Ensure the container is running and port 3000 is accessible:

docker logs crownpeak-dqm-mcp
curl http://localhost:3000/healthz

Integration tests fail

Make sure you have set up the test configuration in .env:

DQM_API_KEY=your_api_key_here
DQM_WEBSITE_ID=your_website_id_here
DQM_TEST_URL=https://www.crownpeak.com

Legal Notices

This is an example solution subject to the MIT license.

Disclaimer

This document is provided for information purposes only. Paul Taylor may change the contents hereof without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Paul Taylor specifically disclaims any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The technologies, functionality, services, and processes described herein are subject to change without notice.

Available Tools

15 tools

delete_assetB

Delete a specific asset from DQM storage

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset to delete

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like whether deletion is permanent, requires permissions, or affects related data. This is a significant gap for a destructive operation.

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 a single sentence that is direct and to the point, with no extraneous information.

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

Completeness3/5

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

For a simple delete tool with one parameter and no output schema, the description is fairly complete but misses essential context about permanence and effects. Additional details would improve completeness.

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% for assetId parameter. The description adds no new semantics beyond what the schema provides, so baseline score of 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 explicitly states the action (delete) and the resource (specific asset from DQM storage), clearly distinguishing it from sibling tools like get_asset and update_asset.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as when deletion is appropriate or irreversible. The description lacks context about prerequisites or consequences.

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

get_assetC

Get details of a specific asset

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset to retrieve

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like idempotency or error handling. It only says 'Get details' without explaining what this entails, such as rate limits or response format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words. However, it could be slightly expanded for clarity without losing conciseness.

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

Completeness2/5

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

Given the absence of an output schema, the description should indicate what 'details' are returned. It does not mention return fields, pagination, or error scenarios, leaving the agent underinformed.

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 100% with a clear parameter description for assetId. The description adds no extra meaning beyond the schema, which already explains the parameter. Baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get details of a specific asset' clearly states the verb and resource, distinguishing it from sibling tools like delete_asset or get_asset_content. However, 'details' is vague and could be more specific.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as search_assets or get_asset_content. The description lacks context about intended use cases.

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

get_asset_contentB

Get the HTML content for a specific asset

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, authorization needs, rate limits, or output format, making it insufficient for understanding the tool's full behavior.

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 a single, concise sentence that front-loads the core purpose. No unnecessary words.

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

Completeness2/5

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

Given no output schema, the description should hint at the return value (HTML content). It fails to do so and lacks behavioral details. The tool is simple but the description is incomplete.

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?

The schema already describes 'assetId' as 'The ID of the asset' (100% coverage). The description adds no additional meaning beyond the schema, so baseline score of 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 clearly states the verb 'Get' and resource 'HTML content for a specific asset', distinguishing it from siblings like 'get_asset' (metadata) and 'get_asset_errors'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, or when not to use it. The description assumes the agent knows when HTML content is needed.

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

get_asset_errorsA

Get asset errors for a specific checkpoint, with content highlighting the issues

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset
`checkpointId`	Yes	The ID of the checkpoint to get errors for

TDQS

A3.6/5.0

Behavior4/5

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

Description implies a read operation ('get') and adds output context ('content highlighting'). No annotations, so description carries the burden; it is sufficient for a simple retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no fluff. While concise, it could benefit from a bit more structure (e.g., clarifying output).

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

Completeness3/5

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

Simple tool with no output schema or annotations. Description mentions content highlighting but does not explain return format, error handling, or pagination. Adequate but with gaps.

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 covers both parameters with descriptions (100% coverage). Description does not add meaning beyond schema, so 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?

Clearly states the tool retrieves asset errors for a specific checkpoint, and mentions content highlighting. Distinguishes from sibling like get_asset_issues by specifying 'for a specific checkpoint'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as get_asset_issues. No mention of prerequisites or context.

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

get_asset_issuesB

Get all quality issues found for a specific asset

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, and the description only states the basic purpose. It does not disclose pagination, filtering, or what constitutes a 'quality issue'. The burden is not fully met.

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?

Single sentence, concise, and directly states purpose. No unnecessary words.

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

Completeness3/5

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

Adequate for a simple getter with one parameter and no output schema. Could mention what a quality issue is, but overall sufficient.

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 100% with a clear parameter description. The description adds no additional meaning beyond the schema, so baseline score applies.

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 operation (get), the resource (quality issues), and the scope (for a specific asset). It distinguishes from siblings like get_asset_errors and run_quality_check.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_asset_errors or run_quality_check. The description is minimal and does not provide context for selection.

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

get_asset_pagehighlightB

(Beta) Get asset content with all page highlightable issues highlighted

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior but only states it returns highlighted content. No details on read-only, performance, or output format are provided for a beta tool.

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?

A single sentence front-loads the beta status and action, with no wasted words. Highly concise.

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

Completeness2/5

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

Despite simple schema, the tool is beta and lacks details on output or how it differs from get_asset_content. Incomplete for confident use.

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?

The input schema has 100% coverage for the single parameter. The description adds no extra meaning beyond the schema's parameter description.

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 verb 'get' and the resource 'asset content with...highlights', making the tool's function unambiguous. It distinguishes from siblings like get_asset_content by specifying the highlighted output.

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?

No explicit guidance on when to use this tool versus alternatives like get_asset_content or get_asset_issues. The 'Beta' label is mentioned but not elaborated.

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

get_asset_statusC

Get the current status of an asset scan

ParametersJSON Schema

Name	Required	Description	Default
`assetId`	Yes	The ID of the asset to check

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavior. It merely states 'Get the current status' without elaborating what 'status' entails, whether it's a lightweight read, what the response format is, or if the operation has side effects. This lack of detail undermines the agent's ability to assess safety and expected outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, succinct sentence that front-loads the verb and resource. No information is wasted, though slightly more detail on output would not harm conciseness.

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

Completeness2/5

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

For a simple status-checking tool, the description lacks essential context: What does 'status' mean? What values can it return? Is there any pagination or staleness? Without output schema, the description should compensate by clarifying the return value, but it does not.

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?

The single parameter 'assetId' is described in the schema as 'The ID of the asset to check,' which matches the tool's purpose. Since schema coverage is 100%, the description adds no new meaning beyond reinforcing the required field.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('status of an asset scan'), making the primary action clear. However, it does not differentiate this tool from siblings like 'get_asset' or 'get_asset_errors', which might also involve status information, leaving some ambiguity about scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives (e.g., get_asset for broader details, or get_asset_errors for error specifics). The context of asset scanning is implied but not explicitly tied to a workflow.

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

get_checkpointB

Get details of a specific checkpoint (quality rule)

ParametersJSON Schema

Name	Required	Description	Default
`checkpointId`	Yes	The ID of the checkpoint to retrieve

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits, but it only states 'Get details' without mentioning side effects, permissions, rate limits, or response structure. It implies a safe read operation but provides no explicit behavioral clarity.

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 a single, clear sentence that efficiently conveys the tool's purpose. Every word earns its place, and it is front-loaded with the key verb and resource.

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 simple get-by-ID tool with one required parameter and no output schema, the description is sufficiently complete. It clarifies the resource type (quality rule), which adds value. Minor gap: no explanation of returned data, but acceptable for minimal complexity.

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 baseline is 3. The description adds no extra meaning beyond the schema, merely restating 'specific checkpoint'. It does not elaborate on the checkpointId format or provide additional context.

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 tool retrieves details of a specific checkpoint (quality rule) by ID. It distinguishes effectively from sibling tools like list_checkpoints (listing) and run_quality_check (running checks).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as using list_checkpoints to obtain IDs first or when to use run_quality_check instead. The description lacks any context for optimal usage.

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

get_websiteC

Get details of a specific website

ParametersJSON Schema

Name	Required	Description	Default
`websiteId`	Yes	The ID of the website to retrieve

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states 'Get details' implying read operation, but no mention of errors, permissions, or response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is efficient and front-loaded, but could include brief additional context without becoming verbose.

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

Completeness2/5

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

Given no output schema or annotations, the description should compensate by explaining what 'details' entails or any usage constraints. It feels incomplete for a retrieval tool.

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 describes the only parameter with a clear description. Description adds no extra meaning beyond the schema, meeting the baseline for 100% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses clear verb 'Get' and resource 'website', distinguishing it from siblings that focus on assets or other entities. However, it could be more specific about what details are included.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like list_websites or get_asset. No context on prerequisites or limitations.

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

list_checkpointsA

List all checkpoints (quality rules), optionally filtered by website

ParametersJSON Schema

Name	Required	Description	Default
`websiteId`	No	Optional website ID to filter checkpoints

TDQS

A3.7/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 carry behavioral context. It correctly indicates a read operation ('list'), but does not specify return format or pagination. For a simple list tool, this is adequate but not exceptional.

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 a single, front-loaded sentence with no wasted words. Every part is essential for understanding the tool's purpose.

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

Completeness3/5

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

Given the tool's simplicity and lack of output schema, the description is minimally complete. However, it does not explain what the returned list contains (e.g., IDs, names, full objects), which could be helpful for downstream tool selection.

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 100% with a clear description for the single parameter. The description adds 'optionally filtered by website', which is redundant with the schema. No additional meaning is provided 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 'List all checkpoints (quality rules)' with a specific verb and resource. It distinguishes from sibling tools like get_checkpoint (singular) and run_quality_check (action-oriented).

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 implies usage via the verb 'list' and mentions optional filtering, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_checkpoint for a single checkpoint).

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

list_websitesA

List all websites in the Crownpeak DQM account

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It states behavior (list all websites) but omits details like return format, pagination, or authentication needs. Minimal but adequate for a simple list tool.

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?

Single sentence, no waste, front-loaded purpose. Efficient and clear.

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

Completeness3/5

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

Given low complexity and no output schema, the description is adequate but lacks details on return values (e.g., fields of each website). Completeness could be improved by mentioning what information is provided.

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?

No parameters, so schema description coverage is 100% trivially. Baseline of 4 applies as no parameter info needed.

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?

Description clearly states it lists all websites in the account. Verb 'list' and resource 'websites' are specific. Distinguishes from sibling 'get_website' which retrieves a single website.

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?

Usage is straightforward for listing all websites. No explicit alternatives or when-not-to-use guidance, but the context is clear given sibling tools; no other tool lists websites.

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

run_quality_checkA

Run a quality check on a URL or HTML content. This will create an asset, scan it, and return the results.

ParametersJSON Schema

Name	Required	Description
`websiteId`	Yes	The ID of the website this asset belongs to
`url`	No	The URL to scan (if checking a live page)
`html`	No	Raw HTML content to scan (if checking HTML directly)
`metadata`	No	Optional metadata for the asset

TDQS

A3.5/5.0

Behavior3/5

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

The description discloses the side effect of creating an asset and scanning it, but lacks details on authorization, rate limits, or what constitutes a 'quality check.' With no annotations, the description carries the burden but covers basic behavioral aspects.

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 concise sentences with front-loaded purpose. No redundant information; every word adds value. Appropriate length for tool context.

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

Completeness3/5

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

With no output schema, the description should explain what results are returned. It only states 'returns the results' without further detail. Creating an asset is mentioned, but overall completeness is moderate.

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 baseline is 3. The description adds minimal value beyond schema by linking 'URL or HTML' to parameters, but does not clarify metadata or provide format details.

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?

Clearly states the tool runs a quality check on URL or HTML, creating an asset and returning results. Verb+resource is specific, and it distinguishes from sibling tools like spellcheck_asset or search_assets by focusing on quality scanning.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., spellcheck_asset, get_asset). The context of when to choose URL vs HTML is implied but not explicit, and no exclusions or prerequisites are mentioned.

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

search_assetsB

Search for assets (pages that have been scanned)

ParametersJSON Schema

Name	Required	Description
`websiteId`	No	Filter by website ID
`query`	No	Search query
`limit`	No	Maximum number of results to return

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description only states what the tool does. It does not disclose behavioral traits like read-only nature, pagination behavior, or error handling, leaving the agent with limited information.

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 a single, clear sentence with no unnecessary words. It is appropriately sized for a simple search tool and front-loads the core purpose.

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

Completeness3/5

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

Given the low complexity (3 optional params, no output schema), the description is somewhat adequate but lacks details on return format or result behavior. It could be improved by mentioning what is returned or how results are ordered.

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?

The input schema has 100% description coverage, so each parameter's purpose is clear from the schema. The description adds no additional meaning beyond what the schema already provides, so it meets the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for assets, which are scanned pages. It's specific about the resource and action, and it distinguishes from sibling tools like get_asset that retrieve individual assets.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, such as when to prefer search_assets over get_asset or other tools. It does not mention prerequisites or context.

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

spellcheck_assetA

Run spellcheck on an asset. Either provide an existing assetId, or provide websiteId + (url or html) to create a new asset first.

ParametersJSON Schema

Name	Required	Description
`assetId`	No	The ID of an existing asset to spellcheck
`websiteId`	No	The ID of the website (required if creating a new asset)
`url`	No	The URL to scan (if creating a new asset from a live page)
`html`	No	Raw HTML content to scan (if creating a new asset from HTML)
`language`	No	Language code for spellcheck (e.g., en, es, fr)

TDQS

A3.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full behavioral burden. It only states the action and input modes, but does not disclose whether the asset is modified, what the output or side effects are, any permission requirements, or rate limits. This is a significant gap for a tool that likely triggers a background check.

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 a single sentence that front-loads the purpose and then concisely explains the two input modes. No superfluous words or repetition.

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

Completeness3/5

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

Given the lack of output schema, annotations, and required parameters, the description is adequate but incomplete. It omits what the spellcheck returns (results stored or returned?), any prerequisites like website permissions, and the role of the language parameter. More context about the workflow would be helpful.

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?

While schema coverage is 100% with basic parameter descriptions, the tool description adds higher-level meaning by explaining the two usage modes (assetId vs. websiteId+url/html), which the individual parameter descriptions do not convey. This helps an agent understand the logical grouping.

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 verb 'Run spellcheck' and the resource 'asset', and explicitly distinguishes between using an existing assetId or creating a new asset via websiteId+url/html. This differentiates it from sibling tools like delete_asset or get_asset, none of which perform spellcheck.

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?

It provides clear conditional guidance on when to use each input mode (existing asset vs. create new), but does not explicitly state when not to use the tool or mention any alternative tools. The context is clear but lacks exclusions.

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

update_assetB

Update the content of an existing asset (URL or HTML)

ParametersJSON Schema

Name	Required	Description
`assetId`	Yes	The ID of the asset to update
`url`	No	The new URL for the asset
`html`	No	The new HTML content for the asset
`metadata`	No	Optional metadata for the asset

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits like whether update replaces or merges, or side effects. It only says 'update' with no specifics on behavior.

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?

Single sentence, concise, and front-loaded with action and target. No wasted words.

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

Completeness2/5

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

For a 4-parameter tool with nested objects and no output schema, the description is too brief. It omits return format, update behavior, and interaction between url/html parameters.

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 covers 100% with descriptions. The tool description adds 'URL or HTML' context but doesn't clarify mutual exclusivity or update semantics beyond 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 explicitly states it updates the content of an existing asset and specifies the content types (URL or HTML). It clearly distinguishes itself from sibling tools like delete_asset or get_asset.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., get_asset for checking content first). No prerequisites or when-not-to-use advice provided.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct aspect of the DQM domain: asset details, content, errors, issues, highlights, status, along with separate tools for checkpoints and websites. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in lowercase snake_case (e.g., delete_asset, get_asset_content, list_websites). The naming is predictable and uniform.

Tool Count5/5

With 15 tools, the server covers essential CRUD and query operations for assets, checkpoints, and websites without being bloated. The count feels well-scoped for the domain.

Completeness4/5

The tool set provides comprehensive access to asset lifecycle (create, read, update, delete) and various quality-related queries. Minor gaps include lack of checkpoint or website management beyond listing and retrieval.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Web Validator by DigestSEO A
io.github.AKzar1el
Validate HTML/CSS, audit SEO and JSON-LD, check links, and capture responsive screenshots.
Marketing Testing & QA Tools Browser Automation
817
wcagc — accessibility scanning
io.github.WCAG-Compliance
Deterministic axe-core accessibility scans (WCAG 2.1 AA, EN 301 549, PDF/UA) via your account.
Testing & QA Tools Developer Tools
2
BrightSite
io.github.BrightSiteHQ
Manage BrightSite websites: pages, blog posts, components, forms, media, and analytics.
Content Management Systems Marketing
21
deplion
cc.deplion
Create and publish static websites, configure forms, and read leads through Deplion.
Content Management Systems Marketing
2

Related MCP Servers

cascade-cms-mcp-server
Content Management Systems Search Developer Tools
kuklaph
A
license
A
quality
B
maintenance
Enables LLMs to interact with Cascade CMS via REST API, supporting asset CRUD, search, publish, workflow, and more through 37 MCP tools and 4 resources.
Updated 21 days ago (2026-08-12 20:28 UTC)
37
24
MIT
Concrete CMS MCP Server
Content Management Systems Developer Tools
concrete5-community
A
license
C
quality
A
maintenance
Enables interaction with Concrete CMS sites through the Concrete CMS REST API, allowing content management, user operations, and file uploads via natural language.
Updated 15 days ago (2026-08-18 14:35 UTC)
37
6
MIT
Aprimo DAM API MCP Server
Content Management Systems Cloud Storage
dcaelopre
F
license
Not graded
quality
B
maintenance
Enables reading of Aprimo DAM asset metadata, fields, and files through the Aprimo REST API. Designed for deployment on Azure via Docker.
Updated 3 months ago (2026-06-18 06:32 UTC)
mcp-devops-deploy
CI/CD & DevOps Developer Tools
mrchris2000
A
license
B
quality
D
maintenance
Enables automated deployments, environment management, snapshots, and deployment monitoring through DevOps Deploy's REST API.
Updated 10 months ago (2025-11-06 17:06 UTC)
15
23
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ptylr/crownpeak-dqm-node-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server