MCP for Builders

The MCP for Builders server exposes AdCritter's build-time surface to coding agents. Connect it like any other MCP server. Every tool name starts with adcritter_ so it's easy to spot which calls are coming from this server in your agent's transcript.

Endpoint

server url
https://mcp.adcritter.com/mcp/dev

Tools vs. actions

This server distinguishes two layers:

  • Tools are the seven adcritter_* MCP calls below. They exist to teach an agent about AdCritter — what entities exist, what the REST contract looks like, how features should behave, and what good UX feels like.
  • Actions are the REST verbs the application your agent generates will call at runtime — create, list, get, update, launch, and so on, on each entity. Actions are discovered with adcritter_get_api_reference(entity) and executed by the application's HTTP client, not by the MCP.

In other words: applications built from this guidance are REST API clients that call /v1/... directly. They are not MCP tool callers.

Tool surface (7 tools)

Start here

  • adcritter_get_platform_overview — entity hierarchy, resource scoping rules, the happy path, and a navigation map for the rest of the tools. Spells out the advertiser-scoping requirement and the auth model up front.
  • adcritter_build_app — catalog of feature guides and their keys (auth, dashboard, campaign-create, campaign-manage, ad-management, reporting, audience, geo-targeting, advertiser, blueprint-plan, whitelabel). Recommended starting point when building an app from scratch.

Build a feature

  • adcritter_guidance(key) — detailed building instructions for a feature key from the catalog. Each guide describes what to build, how users should experience it, and embeds the API contracts the feature touches.

API reference

  • adcritter_get_api_reference(entity, action?) — REST contract for an entity. Without an action, returns the summary of available actions; with an action (e.g., create, list, get, update, delete), returns the full per-action spec: route, method, request schema, response schema, errors, and constraints. Available entities: ad, advertiser, audience, authentication, blueprint, campaign, domain, geo, media-asset, me, plan, report, segment, settings, targeting.
  • adcritter_get_usage_guide(entity) — conceptual model and workflow for an entity: what it is, how it relates to other entities, and the prescribed sequencing for using it.

Design

  • adcritter_get_design_guide(entity, guidance?) — screen experiences and API integration patterns for an entity. Format-agnostic. Three guidance levels: full (default — exact prescription including layouts, copy, and column orders), patterns (balanced hints with softened vocabulary), facts (API integration bindings only, for callers with strong design instincts).

Health

  • adcritter_health — server status and version.

Recommended workflow

  1. Call adcritter_get_platform_overview once at the start of a session.
  2. Call adcritter_build_app to see the feature catalog. Pick the keys that match what you want to build.
  3. For each feature key, call adcritter_guidance(key) to get prescriptive build instructions with embedded API snippets.
  4. For every entity and action you plan to use, call adcritter_get_api_reference(entity, action) to lock in the exact route, request shape, and response shape before writing code. Do not guess from REST conventions — the contract is specific.
  5. For deeper conceptual context, call adcritter_get_usage_guide(entity); for screen experiences, call adcritter_get_design_guide(entity).
  6. Generate the application as a server-side REST client of https://api.adcritter.com/v1/... using the actual contracts returned.

Auth

OAuth2 handled by the MCP client. No env vars, no config.