Standout

get_section_code

Finished, art-directed HTML/CSS page sections for a design direction: nav, hero, offer, image band, story, and footer — composed by a designer, seeded to this business (accent + expression already applied). Use AFTER get_design_direction: assemble the sections and replace only the content (copy + images), never the composition. This is what makes the result look like a $10k site instead of a template.

Input Schema

TableJSON Schema

Name	Required	Description
`business`	Yes	The business, e.g. 'barbershop in Suva' - seeds the expression so same-direction sites stay distinct
`sections`	No	Optional filter: section ids or kinds (nav, hero, offer, imageband, story, footer). Omit for the full set
`direction`	No	Direction pack id from get_design_direction (e.g. ink-and-paper, harvest-table, aurora-glass)
`signature_move`	No	The signature move id from get_design_direction's Signature Concept (e.g. editorial_dossier, field_report_layout). Pass it so the sections are ORDERED and FRAMED to that concept - the output then leads with the Creative Spine, Memorable Move, and hard Differentiation Rules.

TDQS

A4.4/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 that sections are pre-seeded with accent/expression, composed by a designer, and should not be recomposed. It lacks specifics like return format or side effects, but for a read-oriented code retrieval tool, the description is reasonably transparent.

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 three sentences: the first front-loads the core function, the second provides usage instructions, and the third adds a value proposition. Every sentence earns its place with no fluff or redundancy.

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?

The tool has no output schema, so the description should explain return values. It does say 'HTML/CSS page sections' and implies assembly. It also covers dependencies (direction, signature_move). It could detail the output structure more precisely, but it gives a sufficient mental model for an agent.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the 'business' parameter seeds the expression, and elaborates on 'signature_move' by stating it 'ORDERED and FRAMED to that concept' and leads with Creative Spine, Memorable Move, and Differentiation Rules. It also implicitly ties the 'sections' parameter to the listed section types.

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 returns 'Finished, art-directed HTML/CSS page sections for a design direction' and lists specific section types (nav, hero, offer, image band, story, footer). It distinguishes itself from siblings by emphasizing the designer-composed, production-ready nature and its role after get_design_direction.

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 gives explicit usage guidance: 'Use AFTER get_design_direction' and instructs to 'assemble the sections and replace only the content (copy + images), never the composition.' This provides a clear workflow and when to use the tool, though it does not name alternative tools for exclusion scenarios.

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

All Standout tools Inspect

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

A3.7/5.0

Disambiguation2/5

Multiple tools have unclear boundaries: build_from_reference and build_from_reference_v2 serve nearly the same purpose, make_it_standout and polish_and_prove overlap heavily, and get_design_direction, synthesize_direction_from_references, and build_from_reference_v2 all produce design directions. The long descriptions help, but an agent could easily select the wrong tool.

Naming Consistency4/5

Most tools follow a consistent snake_case verb_noun pattern (e.g., get_design_direction, search_references, watch_site). Minor deviations like client_report, make_it_standout, and polish_and_prove are acceptable but slightly break the pattern.

Tool Count2/5

30 tools is too many for a design toolkit, exceeding the 25+ threshold for 'too many'. Many 'get' tools could be consolidated (e.g., get_hero_concept, get_motion_recipes, get_asset_pack could be one tool). The count feels bloated rather than well-scoped.

Completeness4/5

The tool set covers the full design/build/critique/report/watch lifecycle well, from direction and sections to client reports and site monitoring. Minor gaps exist (e.g., no explicit 'update' or 'delete' for references), but these are not critical to the core workflow.

Resources

Need Help?