AdCritter for Builders
Server Details
AdCritter ads platform: docs, API reference, app scaffolding, and white-label integration.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 7 of 7 tools scored. Lowest: 3.7/5.
Most tools have distinct purposes, but adcritter_build_app and adcritter_get_platform_overview both serve as starting points with overlapping content. Descriptions help differentiate, but there is some potential confusion.
Names mix conventions: some use 'get_' prefix (get_api_reference, get_design_guide, etc.) while others are bare nouns (guidance, health) or verbs (build_app). The pattern is inconsistent but still coherent.
With 7 tools, the set is well-scoped for a documentation-oriented platform. Each tool serves a clear informational purpose without redundancy.
The tool set covers all necessary aspects for building an AdCritter app: starting points, API contracts, design guidance, usage workflows, and health. No obvious gaps for the stated purpose.
Available Tools
7 toolsadcritter_build_appAInspect
Start here when building an application. Returns an overview of what the AdCritter platform offers and a catalog of feature guides you can query with the adcritter_guidance tool to learn how to build each part of the app. Call adcritter_guidance(key) for any feature area to get detailed building instructions with API endpoints and response shapes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are present, the description sufficiently implies a read-only, non-destructive operation by stating it returns an overview and catalog, with no side effects indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with key instruction, every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description fully covers the tool's role as the entry point and directs to sibling tools for specifics, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and full schema coverage, the description adds value by explaining the tool's purpose and output, exceeding the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the starting point for building an application, returns an overview and catalog, and directs to adcritter_guidance for detailed instructions, effectively distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to start here when building an application and then use adcritter_guidance for feature areas, providing clear when-to-use and next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adcritter_get_api_referenceAInspect
Returns the REST API contract for an AdCritter entity. Without an action parameter, returns a summary with available action names - use this to discover what you can do. With an action parameter (e.g., 'create', 'list', 'get'), returns the full details for that action: route, HTTP method, request schema, response schema, error codes, and constraints. Available entities: ad, advertiser, audience, authentication, blueprint, campaign, domain, geo, media-asset, me, plan, report, segment, settings, targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Optional specific action to drill into (e.g., 'create', 'list', 'get', 'update', 'delete'). Omit to see all available actions. | |
| entity | Yes | The entity to look up (e.g., 'campaign', 'ad', 'report') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully addresses behavioral aspects: it explains the summary vs full detail return, and what the full details include (route, method, schemas, error codes, constraints). It does not mention rate limits or authentication, but for a reference tool, the coverage is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but front-loads the core purpose and behavior. It uses a list for entities, which aids readability. Every sentence contributes meaning, though it could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what is returned in both cases (summary with action names or full details with various elements). It also lists all available entities, providing a complete picture for a 2-parameter reference tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds value by explaining the effect of omitting the action parameter and listing the available entities, which goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the REST API contract for an AdCritter entity, distinguishing it from sibling tools like adcritter_build_app or adcritter_get_design_guide. It also explains the dual behavior based on the action parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: without action to discover available actions, with action to get full details. It lists available entities but does not mention when not to use it or alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adcritter_get_design_guideAInspect
Returns AdCritter design guidance for an entity at a caller-chosen guidance level - screen experiences, API integration patterns, and design philosophy. The default ('full') returns step-by-step prescription (exact layouts, colors, copy text, column orders). Request 'patterns' for balanced hints including common design patterns with softened vocabulary. Request 'facts' if you have strong visual-design instincts and just want API integration bindings (or call adcritter_get_api_reference and adcritter_get_usage_guide directly and skip this tool). Guidance is format-agnostic - it describes outcomes and integration, never prescribes frameworks or architecture. Available entities: ad, advertiser, audience, authentication, blueprint, campaign, geo, media-asset, plan, report, settings.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | The entity to look up (e.g., 'campaign', 'report', 'authentication') | |
| guidance | No | Optional guidance level. Values: 'full' (facts + patterns + prescription, the default), 'patterns' (facts + softened patterns, for capable callers who want structure without exact prescription), 'facts' (conceptual facts only, for callers with strong product instincts). Omit to use the default. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses format-agnostic nature and that it never prescribes frameworks. With no annotations, this is adequate but misses mention of read-only behavior or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient paragraph that front-loads purpose, explains levels with examples, and ends with constraints. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, guidance options, entity list, format constraints, and sibling alternatives. Lacks explicit mention of output structure or type, but acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, yet the description adds significant value by detailing guidance level semantics (full, patterns, facts) and listing all 12 available entities, far surpassing the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('returns'), specific resource ('design guidance for an entity'), and explicit differentiation from siblings by naming alternative tools (adcritter_get_api_reference, adcritter_get_usage_guide).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use each guidance level ('full', 'patterns', 'facts') and suggests skipping the tool for 'facts' users. However, does not systematically list when not to use it versus all siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adcritter_get_platform_overviewAInspect
Start here. Returns the AdCritter platform overview - what AdCritter is, the entity hierarchy (organization > advertiser > campaign > ad), the happy path for getting ads running, and how to navigate the other MCP tools. Applications built from this guidance are REST API clients that call /v1/ endpoints, not MCP tool callers. Before writing code, call adcritter_get_api_reference(entity, action) for each entity and action you plan to use - tool descriptions and parameter names describe conceptual behavior only, and do not match actual API routes, field names, query parameters, or response shapes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses crucial behaviors: tool descriptions and parameter names are conceptual and do not match actual API, and applications are REST API clients, not MCP callers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and front-loaded with 'Start here', but it is slightly lengthy. Each sentence adds value, so it is effective but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's nature as an overview with no parameters, the description fully covers what it returns, how to use it, and important caveats, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so no parameter information is needed. The baseline of 4 is appropriate as the description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a platform overview, including what AdCritter is, the entity hierarchy, the happy path, and navigation to other tools. It distinguishes itself from sibling tools by being the starting point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Start here' and advises to call adcritter_get_api_reference before coding, providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adcritter_get_usage_guideAInspect
Returns the conceptual model and workflow guidance for an AdCritter entity - what it is, how it relates to other entities, and the intended workflow for using it. Includes exhaustive workflow sequencing and prescriptive rules so generated apps call the API correctly. Available entities: ad, advertiser, audience, authentication, blueprint, campaign, domain, geo, media-asset, me, plan, report, segment, settings, targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | The entity to look up (e.g., 'campaign', 'geo', 'plan') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like side effects, auth needs, or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a list, though it could be more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately covers the tool's purpose and output content for a conceptual guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description lists available entities but does not add significant meaning beyond the schema's example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns conceptual model and workflow guidance for an AdCritter entity, distinguishing it from sibling tools like adcritter_get_api_reference and adcritter_get_design_guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to understand entity workflows and prescriptive rules, but lacks explicit guidance on when not to use or alternatives beyond listing sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adcritter_guidanceAInspect
Returns detailed building instructions for a specific feature area of an AdCritter application. Each guide describes what to build, how users should experience it, and includes all API endpoints with request/response shapes so you never have to guess the API contract. Call adcritter_build_app first to see available feature guides and their keys.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The feature guide key from the adcritter_build_app catalog (e.g., 'auth', 'dashboard', 'campaign-create') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes what the tool returns (building instructions, API endpoints) but does not explicitly state it is read-only or disclose other behavioral traits like permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description fully explains what is returned (what to build, user experience, API contracts) and the prerequisite, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the parameter meaning (key from catalog), and the overall description reinforces the prerequisite link to adcritter_build_app, adding context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns detailed building instructions for a specific feature area, using a specific verb and resource. Distinguishes from sibling adcritter_build_app by noting it is the source for keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call adcritter_build_app first to get available keys, providing a clear prerequisite and usage order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
adcritter_healthAInspect
Returns server health status and version information for the AdCritter MCP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the output (health status, version) accurately. No annotations exist, but the nature of the tool suggests safe, read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous information, front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully captures the tool's simple purpose and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline applies. Description appropriately states the return values without needing param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns server health status and version information, distinguishing it from sibling tools that focus on building apps or retrieving documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The health check purpose is implied but not compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!