Skip to main content
Glama

AdCritter for Builders

by com.adcritter

adcritter_guidance

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesThe feature guide key from the adcritter_build_app catalog (e.g., 'auth', 'dashboard', 'campaign-create')

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the transparency burden. It discloses the tool is read-only (returns instructions) and describes content details such as what to build, UX expectations, and API endpoints. It does not cover error behavior or authentication, but these are less critical for an informational guide 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?

The description is compact and front-loaded with the primary action. Every sentence adds value: functionality, content details, and usage prerequisite. No redundant words.

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 single-parameter read-only tool, the description explains purpose, content, and prerequisite. It lacks explicit mention of error behavior or exact output format, but the tool is simple and the description is sufficiently complete.

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 has 100% coverage with a clear description for the 'key' parameter. The description adds no additional semantic value beyond the schema, only repeating the source from the build_app catalog. Baseline 3 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 tool's function: returning detailed building instructions for a specific feature area of an AdCritter application. It distinguishes from sibling tools like adcritter_get_api_reference and adcritter_get_design_guide by focusing on build instructions and including API contracts.

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?

Provides explicit guidance to call adcritter_build_app first to obtain valid keys, establishing a clear workflow. It also implies the tool's role versus the API reference by noting it includes request/response shapes, but does not explicitly list exclusions or 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