Skip to main content
Glama
Sign In
awwwards-mcp

awwwards-mcp

by INSANE0777
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

build_pose_stub

Read-onlyIdempotent

Render a captured pose grid as a standalone scroll-scrubbed three.js stub page with inline frames, synthesized camera path, and reduced-motion fallback.

Instructions

Render a captured pose grid (pose-grid-v1 from capture_pose_3d) as a standalone scroll-scrubbed three.js stub page: frames preloaded inline, a synthesized camera path interpolated between snapshot scroll ratios (guidance only — the pose grid stores frames and scroll ratios, not recovered camera transforms), prefers-reduced-motion static fallback, optional census-derived st/pin/ease suggestions. Pure build — no page fetches, no awwwards.com access.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "poseGrid": "<poseGrid>"
    },
    "name": "build_pose_stub"
  }
}

Input Schema

NameRequiredDescriptionDefault
poseGridYesPoseGrid object as returned by capture_pose_3d (id pose-grid-v1)
scrollCensusNoOptional ScrollCensus from analyze_scroll_map — adds suggestion notes + comment hints

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changedv1.13.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / required
      Added value: +[
+  "poseGrid"
+]
  3. Addedv1.9.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is added context — and it delivers: the camera path is explicitly flagged as synthesized guidance rather than recovered transforms, a prefers-reduced-motion fallback exists, and 'no page fetches, no awwwards.com access' confirms the closed-world hint. Missing is any statement of what the build actually produces (returned markup vs. a written file), which matters for a build tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

One dense sentence, front-loaded with the verb and artifact, with the caveat parenthetical placed right where the expectation would otherwise be wrong. It is information-packed but reads as a run-on list of features, and the 'st/pin/ease' shorthand costs more than it saves.

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 two-parameter build tool with no output schema, the description covers inputs, provenance, rendering behavior, fallback, and network constraints — nearly everything needed to invoke it correctly. The one real gap is the return contract: an agent does not learn whether it gets HTML text, a file path, or a preview URL.

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?

Schema coverage is 100% and both parameters are described there, so the baseline applies. The description adds only modest meaning beyond the schema — it clarifies that scrollCensus yields 'st/pin/ease suggestions' — but leaves those abbreviations unexplained and adds nothing about the poseGrid shape.

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 opens with a specific verb and artifact: 'Render a captured pose grid ... as a standalone scroll-scrubbed three.js stub page', and names the upstream producer (capture_pose_3d, pose-grid-v1). An agent can distinguish this from build_scene_stub/build_gsap_stub purely on the input contract and output artifact.

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?

It implies a clear pipeline position (consume a pose-grid-v1 from capture_pose_3d, optionally feed in a ScrollCensus from analyze_scroll_map), which tells the agent when this tool applies. It stops short of explicitly ruling out the sibling build_* stubs or stating prerequisites, so it is strong context rather than a full when/when-not statement.

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

Deploy Server

Other Tools