Skip to main content
Glama

AdCritter for Builders

by com.adcritter

adcritter_get_api_reference

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, canva, domain, facebook, geo, googleads, media-asset, me, plan, report, segment, settings, targeting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoOptional specific action to drill into (e.g., 'create', 'list', 'get', 'update', 'delete'). Omit to see all available actions.
entityYesThe entity to look up (e.g., 'campaign', 'ad', 'report')

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently explains the two modes (summary vs full detail) and what is returned (route, HTTP method, request/response schemas, error codes, constraints), which adequately conveys a read-only lookup operation without 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.

Conciseness5/5

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

The description is concise and well-structured, with a clear front-loaded purpose sentence followed by explanations of behavior and supported entities. Every sentence earns its place, with no redundancy or filler.

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

Completeness5/5

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

For a tool with only two parameters and no output schema, the description fully covers usage modes, parameter semantics, and the content of the returned data. It includes examples and a list of valid entities, making it complete for an API reference lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents both parameters, the description adds significant meaning by explaining the effect of omitting versus passing the action parameter, and by listing concrete entity examples. This goes beyond the schema's descriptions and clarifies the interplay between entity and action.

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's purpose: 'Returns the REST API contract for an AdCritter entity.' It uses a specific verb (Returns) and resource (REST API contract), and distinguishes itself from sibling tools like adcritter_get_usage_guide and adcritter_get_platform_overview by focusing on API contract details.

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

Usage Guidelines4/5

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

The description provides clear guidance on when to use it: omit the action parameter to discover available actions, or pass an action for full details. It explicitly says 'use this to discover what you can do', but it does not explicitly mention alternative sibling tools or exclusions, so it slightly misses the mark on 'vs alternatives'.

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

All AdCritter for Builders toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation2/5

Multiple tools serve as entry points (adcritter_build_app and adcritter_get_platform_overview both say 'Start here') and several guidance tools (guidance, get_usage_guide, get_design_guide, get_api_reference) have overlapping descriptions around API endpoints and workflows. Agents would need to parse subtle differences to choose correctly, making misselection likely.

Naming Consistency4/5

Five of seven tools follow a verb_noun pattern (adcritter_get_*), but adcritter_guidance and adcritter_health are bare nouns, breaking the pattern. The prefix is consistent and all snake_case, so the deviations are minor.

Tool Count5/5

Seven tools is within the ideal 3-15 range and fits the server's purpose as a guidance/reference library. Each tool addresses a distinct aspect of the builder journey, though some overlap in content.

Completeness4/5

The server covers platform overview, API contracts, design guidance, usage workflows, feature-specific build instructions, and health checks. It lacks a direct tool for listing all available entities or guides (buried in other tools), but the core backing need is well covered. The overlap doesn't create dead ends, just confusion.

Resources