Skip to main content
Glama

create_critique_pin

Create actionable, concrete critique pins for specific UI elements on live pages, naming the element, problem, and fix in under 40 words. For high or medium severity issues only.

Instructions

Create a pin authored by Pincushion AI. ONLY call this from the pincushion-critic subagent or the /critique-latest-deploy flow — never from a regular user prompt, since the bot voice is reserved for AI-driven UI/copy/a11y feedback. Each call should produce one tasteful, high-signal pin (max 3 per page in a critique run). The body must be concrete and actionable: name the specific element + the specific problem + the suggested fix in <40 words. Forbidden: layout philosophy, business-model commentary, generic "consider improving hierarchy" advice. Always read the project's critique context (ai.critique.effectiveContext from get_project_context — falls back to brandContext when no compiled brief exists) before drafting the body so the critique is on-brand. If ai.critique.staleness is "stale" or "missing", suggest the user run /refresh-brand before continuing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesThe critique itself. Concrete + actionable, <40 words, names the element and proposes a fix. This becomes the first thread message on the pin.
tagsNoOptional tags. "pincushion-ai" is added automatically. Add domain tags like "a11y", "copy", "deploy:<hash>" for traceability.
pageUrlYesFull URL of the page being critiqued (e.g. "http://localhost:3000/dashboard").
selectorNoCSS selector for the element the critique targets. The Chrome extension uses this to position the pin since the bot has no live page coords. Be specific (e.g. 'main button[type="submit"]' not just 'button').
severityNo"high" = ships-blocking (broken contrast, broken keyboard nav, misleading CTA copy). "medium" = worth-fixing (minor copy issues, cramped spacing, polish opportunities). 'low' is intentionally not allowed — bot pins must be worth acting on.
pageTitleNoOptional page title for the .feedback file header. Defaults to pageUrl if omitted.
projectIdNoProject ID to associate the pin with. Defaults to the MCP server's configured project.
componentNameNoOptional component name (e.g. LWC component, React component) for grouping. Used by get_component_feedback.
Behavior4/5

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

No annotations exist, so the description carries full responsibility. It discloses that the pin must be concrete/actionable, forbids certain topics, and requires reading project context. However, it does not explicitly mention the return value or side effects beyond creating a pin, which marks a minor gap.

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 succinct (~120 words) yet packed with essential rules. It front-loads the invocation restriction, then provides actionable parameter details and process prerequisites. No superfluous sentences; every part earns its place.

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 description covers usage, parameter constraints, prerequisite context checks, and forbidden content. Without an output schema, it could briefly mention expected return (e.g., the created pin ID), but the overall completeness is high given the tool complexity.

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?

All 8 parameters have schema descriptions (100% coverage), but the description adds significant value: it gives concrete examples ('body <40 words'), clarifies automatic tag addition, specifies selector specificity, and explains severity thresholds. This enriches the schema and helps the agent craft correct calls.

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 creates a pin authored by Pincushion AI and distinguishes it from user-driven actions. It specifies the verb ('Create'), the resource ('pin'), and the context ('AI-driven UI/copy/a11y feedback'), making it unambiguous among sibling tools like approve_pin or claim_pin.

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

Usage Guidelines5/5

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

Explicit guidance is provided: 'ONLY call this from the pincushion-critic subagent or the /critique-latest-deploy flow — never from a regular user prompt.' It further states constraints like 'max 3 per page' and prerequisites like checking 'ai.critique.staleness', leaving no ambiguity about when to invoke.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jcooley8/pincushion-plugin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server