Skip to main content
Glama

Critique with GPT

gpt_critique
Read-only

Submit a draft to GPT for an independent critique that returns ranked issues by severity with suggested fixes. Use it for second opinions or before finalizing high-stakes work.

Instructions

Send a draft to GPT (OpenAI) for an independent critique. Returns ranked issues, each with a severity (critical, major, minor, nit) and a suggested fix. Call this when the user asks for a second opinion, review or critique, or before you finalise high-stakes work (code, a plan, an argument, an important message) where an outside reviewer could catch mistakes you missed. Do not call it for short or casual replies. Pass the complete draft text; GPT sees nothing else from the conversation, so include needed context in the draft or rubric. Afterwards, tell the user which issues you accept and fix, and which you reject and why.

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": {
      "draft": "<draft>"
    },
    "name": "gpt_critique"
  }
}

Input Schema

NameRequiredDescriptionDefault
draftYesThe full text to critique.
rubricNoOptional criteria or context to judge against, e.g. 'audience: CFO; must be under 200 words'.

Output Schema

NameRequiredDescriptionDefault
modelYes
issuesYes
parsedYesFalse if GPT's reply was not valid structured JSON; see the text content.
summaryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-idempotent, so the safety profile is covered. The description adds the critical behavioral fact that GPT sees nothing else from the conversation, meaning the draft must be self-contained, plus the severity taxonomy of the returned issues — context not derivable from the annotations.

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?

Purpose is front-loaded in the first sentence, followed by return shape, triggers, exclusions, parameter guidance, and follow-up. Four sentences is slightly long but each carries distinct, non-redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and rich annotations, the description only needs to cover intent, triggers, and the context-isolation caveat — all of which it does. An agent can select and invoke this tool correctly with no remaining ambiguity.

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 the baseline is 3; the description earns more by explaining that the draft must be the complete text and that the rubric is where audience or length constraints belong, because the model has no other context. It adds intent beyond the schema's terse field descriptions.

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?

States a specific verb and resource: send a draft to GPT (OpenAI) for an independent critique, and names the artifact produced (ranked issues with severity and suggested fix). The 'independent critique' framing separates it from the sibling debate/synthesize tools without needing to name them.

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?

Gives explicit positive triggers (second opinion, review, before finalising high-stakes work) and an explicit exclusion ('Do not call it for short or casual replies'). It even prescribes the post-call workflow of telling the user which issues are accepted and which are rejected.

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