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 arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states that the tool returns an overview and catalog, which is clear and implies a non-destructive read operation. It also mentions how to use the returned catalog with adcritter_guidance, adding useful context beyond the bare action.
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 exactly two sentences, front-loaded with the primary instruction 'Start here when building an application'. Every sentence adds value: the first explains what the tool returns, the second gives actionable next steps with an explicit tool call and purpose.
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 zero-parameter, no-output-schema tool, the description is complete: it states the tool's role in the build workflow, what it returns, and how to proceed to detailed guides. The mention of adcritter_guidance covers the natural next step and makes the description self-contained.
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, so the baseline is 4. The description adds no parameter-specific details because there are none, but it references calling adcritter_guidance with a key, which provides context for the overall workflow without confusing the current tool's input requirements.
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 the tool's purpose: it is the starting point for building an application, returning an overview of the platform and a catalog of feature guides. It differentiates itself from sibling tools by explicitly pointing to adcritter_guidance for detailed instructions.
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 provides explicit usage guidance: 'Start here when building an application' and instructs the agent to 'Call adcritter_guidance(key) for any feature area'. This clearly indicates when to use this tool and directs to an alternative for further steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
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.
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.
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.
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.