CDN.MN

- Analyze website performance— Ask the assistant to runanalyze_websiteon a public site to inspect its image pipeline and delivery setup.
- Estimate image savings— Useestimate_image_savingsto quantify potential bandwidth and cost reductions from CDN-optimized image delivery.
- Create and configure projects— Have the assistant callcreate_projectandconfigure_originto set up a new CDN.MN project with your existing origin.
- Verify and activate domains— Requestverify_domainto confirm origin ownership, thenactivate_hostnameto enable production delivery.
- Purge cached content— Triggerpurge_urlsto invalidate specific cached objects after deploying updated site assets.
- Review analytics and billing— Ask forget_analyticsandget_billingto check usage, savings, and current plan details.

Device-code registration, scoped access, a per-scope approval valve & instant revoke, machine-readable discovery (auth.md, llms.txt, OpenAPI, and the SKILL.md workflow), and the MCP server with 18 tools — the reads, public-site image analysis + savings estimates, project creation, cache purge, domain verification, and every production mutation behind a sensitive scope: hostname activation, adding funds, origin configuration, project archive, and applying the delivery configuration. Each runs on its own for an autonomous agent — except money, which always waits for your approval — or opens an approval card when you ask to be in the loop. The published@cdnmn/cli+@cdnmn/sdklet an agent detect, configure, rewrite, test, and verify straight from the project — honoring the repo’s AGENTS.md.

The integration-planning + preview tool set (integration plans, non-production previews) and the anonymous no-claim registration path are on the roadmap — labelled below wherever they appear.

Authentication and discovery are live at well-known locations — an agent can register and hold a scoped token today:

GET /auth.md → the human-readable access guide GET /llms.txt → machine index of the agent surfaces GET /openapi.json → OpenAPI 3.1 for the REST endpoints GET /.well-known/oauth-protected-resource GET /.well-known/oauth-authorization-server POST /api/agent/register → device_code + user_code POST /api/agent/token → poll → cdnmn_at_… bearer token POST /api/mcp → MCP 2025-06-18: tools/list, tools/call

Two live ways in: the plain device-claim path pairs the agent to your account — you open the claim link (/agents/claim) and grant the scopes; or an agent with your email registers with provision_workspace to get a live workspace and tokenimmediately, no human step, which you adopt from an email later. Billing and deletion stay locked until you adopt it.

The install workflow is published at /SKILL.md — a step-by-step playbook over the live tools (verify → activate → fund). The packaged platform references and verification scripts below are still rolling out:

cdn-mn-agent/ ├── SKILL.md ├── scripts/ │ ├── detect-platform │ ├── analyze-images │ ├── create-preview │ └── verify-installation ├── references/ │ ├── nextjs.md · wordpress.md · nuxt.md │ ├── static-sites.md · nginx.md │ └── rollback.md └── assets/ ├── config-templates/ └── report-template.md

Planned packaged layout — the SKILL.md workflow is live today.

Agents request exactly the capability they need. Nothing generic like api.write.

site:analyzeAnalyze a public website or origin

origin:writeConfigure or change an origin

integration:planGenerate an integration plan

integration:previewCreate a non-production preview

integration:applyApply approved changes to production

domain:verifyRun origin-ownership verification for a site

domain:activateActivate production delivery

analytics:readRead usage and savings data

billing:writeChange plan or authorize spend

Scopes in red (origin:write, integration:apply, domain:activate, billing:write, project:delete) are never granted by default. When you do grant one, the agent acts on its own within it — unless you tick “require my approval each time” at connect time to keep a per-use approval card. Money (billing:write) always requires that approval — its valve is locked on and cannot be opted out.

Following the auth.md model — with practical fallbacks, not “works with every agent” claims.

An agent with your email registers with provision_workspace and gets a live workspace + a scoped token immediately — it can analyze, create a project, verify a domain, and serve on a one-time $5 starter credit with no approval to begin. You adopt the workspace from an email later; billing, deletion, and custom origins stay locked until you do.

owner_email + provision_workspace → token on the first poll · adopt by email · unadopted swept ~72h

device-code ceremony on a CDN.MN-owned page · tokens stored hashed

The read-only preview scopes an agent may request before any human is involved — analyze a public site, but touch nothing a customer owns. The no-claim path and its plan/preview tools are still rolling out.

site:analyze · analytics:read · billing:read (plan/preview scopes reserved until their tools ship)

Where the agent provider supports identity assertion, the agent will request an audience-specific assertion after your consent; CDN.MN verifies it and returns a scoped credential. Planned, and never the only path.

arrives as providers adopt it — the paths above always work

High-level, idempotent MCP tools 18 tools live

18 tools are callable today at /api/mcp — the reads, public-site image analysis, project creation, domain verification, cache purge, and every sensitive production mutation. A sensitive tool runs on its own for an autonomous agent — except adding funds, which always waits for your approval — or opens an approval card when you asked to be in the loop; the integration-plan + preview tools are still rolling out, and the agent never assembles low-level configuration blindly:

green = callable now · grey = rolling out

Designed so it’s hard to accidentally create duplicates, route to the wrong origin, or produce an unbounded bill. Live today on every sensitive tool (activate_hostname shown here): dry_run and idempotency_key are accepted and bound to the action, and a repeated call with the same key never runs twice.

accepted on every sensitive tool (example: activate_hostname): site_id: "s_..." dry_run: true idempotency_key: "..." → returns now, when autonomous: status: executed · execution.hostname (the action ran inline) → returns now, when you require approval: approval_required · approval_id poll_with: get_approval_status → every sensitive action returns a self-describing contract: proposed_changes · warnings rollback_plan · verification_steps (on the tool response, on get_approval_status, and on the owner's approval card)

These appear on the homepage, code repository, agent skill, and framework guides.

Add CDN.MN to this website. Keep the current origin and existing application behavior. Analyze the image pipeline, estimate potential savings, detect the safest integration strategy, create the CDN.MN project, configure responsive image delivery and modern formats, run the project tests, and ask me before changing DNS, billing, or production deployment.

Optional AGENTS.md snippet for your project

AGENTS.md is the emerging convention for giving coding agents persistent project guidance. If your agent honors it, add this section so every CDN.MN change follows your project’s rules — your direct instruction always takes priority.

## CDN.MN image delivery - Read the current CDN.MN project configuration before changing image URLs. - Keep the existing image origin as the fallback unless explicitly instructed. - Never commit CDN.MN access tokens, claim tokens, or API credentials. - Create integration changes in a separate branch. - Run the project build, tests, and broken-image verification before completion. - Use a CDN.MN preview before requesting production activation. - Do not modify DNS, billing, or production deployment without explicit approval. - Report all changed files, configuration changes, verification results, and rollback steps.

Navigate your Aiven projects and interact with the PostgreSQL®, Apache Kafka®, ClickHouse® and OpenSearch® services

Yunxiao MCP Server provides AI assistants with the ability to interact with the Yunxiao platform.

Get prescriptive CDK advice, explain CDK Nag rules, check suppressions, generate Bedrock Agent schemas, and discover AWS Solutions Constructs patterns.

This AWS Labs Model Context Protocol (MCP) server for CloudTrail enables your AI agents to query AWS account activity for security investigations, compliance auditing, and operational troubleshooting.

Core AWS MCP server providing prompt understanding and server management capabilities.

Analyze CDK projects to identify AWS services used and get pricing information from AWS pricing webpages and API.

Query and analyze your Axiom logs, traces, and all other event data in natural language

Manage and interact with Microsoft Azure services.

Bastion: External Attack Surface Monitoring

Ask your AI assistant about your attack surface: run scans, catch expiring certificates and domains, triage findings, and generate reports.

Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows