Skip to main content
Glama

update_critique_context

Persist a compiled critique brief, signals, and policy to the cloud for the AI critic. Use after gathering repo signals to define the critique context.

Instructions

Lightweight write-only path for the layered critique-context system. Use this from /setup and /refresh-brand after the dev agent has gathered repo signals (README, theme tokens, sample copy, competitor URLs, recent resolved pins) and compiled them into a critique brief. Unlike configure_project, this does NOT create a deploy hook, sync members, or validate URLs — it just persists the compiled brief (+ signals + policy) and pushes to cloud. Identify the project by projectId or name. The compiled critiqueContext is what the AI critic actually reads at pin time; critiqueSignals + critiquePolicy are inputs retained for traceability and the next recompile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoThe project display name. Used to look up the project when projectId is not known.
projectIdNoThe project ID to update. Mutually exclusive with `name`.
critiquePolicyNoUser-editable policy override (max 4096 chars). Persists across recompiles so users keep hand-tuned rules. Pass null to clear.
critiqueContextNoThe compiled critique brief (max 8192 chars). Markdown encouraged. This is what the AI critic loads at pin time. Pass null to clear and force a recompile on the next run.
critiqueSignalsNoRaw signals JSONB. Recommended shape: { framework: e.g. "next-app-router"|"astro"|"static-html", projectType: "marketing"|"app"|"mixed", pages: [{ url, source, slice, headings, ctas, components, bodyExcerpt }], themeTokens, brandDocs, readmeExcerpt, competitors, mission, audience, tone, tenantContexts (reserved/null in v1), sources }. The agent decides exact shape; the AI critic reads the COMPILED context, not the signals directly. Pass null to clear.
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that this is a write-only operation, does not create deploy hooks or sync members, simply persists and pushes to cloud. It explains the roles of critiqueContext, critiqueSignals, and critiquePolicy. However, it does not cover failure modes or idempotency.

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?

The description is a single paragraph, efficiently front-loaded with the core purpose and usage context. Every sentence adds value, but there is minor redundancy in explaining the role of each field both in description and schema. Slightly verbose but still clear.

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?

Given the complexity (5 parameters, nested object, no output schema), the description covers the tool's purpose, usage context, and parameter semantics adequately. It lacks details on return values or error scenarios, but the absence of an output schema reduces the burden. Slightly incomplete on success behavior.

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?

Despite 100% schema coverage, the description adds significant meaning: critiquePolicy is user-editable and persists across recompiles; critiqueContext is what the AI critic reads; critiqueSignals is raw input not directly read by critic. It also gives a recommended shape for critiqueSignals, adding context beyond schema.

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 it is a 'lightweight write-only path for the layered critique-context system' that persists the compiled brief. It explicitly contrasts with the sibling tool `configure_project`, listing what it does not do, making its purpose distinct and specific.

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?

The description explicitly says to use this from /setup and /refresh-brand after gathering repo signals, and contrasts with `configure_project` by listing excluded actions (no deploy hook, sync members, validate URLs). This provides clear when-to-use and when-not-to-use guidance.

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