Skip to main content
Glama
Sign In
Grill

Grill

by mtangoz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Grill a decision

grill
Read-only

Send a decision, plan, or forecast to an outside AI judge from a different company and get an independent verdict, so you can check your reasoning before acting.

Instructions

Send a decision, plan or forecast to an outside AI judge: a model from a different company than the assistant that wrote it (Claude, unless set otherwise). The judge is picked by openrouter/auto. Do not pin a model, and do not fall back to this chat's own model for speed or cost. Send the decision as the user stated it, with whatever context is already in the chat. Do not rewrite it into a template, and do not add your own case against. Ask at most one short question, and only if the decision is truly unclear, such as 'What's the goal?'. Then call this tool. Do not wait for an OK, and do not show a write-up full of blanks. Never add a required question before the verdict on a quick or bulk grill. Ask only what the subject strictly needs. The first time you use Grill with this person, say once, as one line, and not again: This goes to an outside judge from a different company, and the router does not keep it. https://grillyour.ai/#privacy A quality check (Jev, from TypeSafe) may also see the masked write-up, on a zero-retention endpoint. Do not put that into the once-only line. The privacy link covers it. Do not mention the check or its score again. Pass quality_check: false only if the user asks to skip it. After that, do not repeat the disclosure. Do not mention the judge's model, a score, a balance, or a quote check. Relay layer 1 as written. It is at most 50 words and already ends with: Say 'more', 'options', or your call. On a decision they marked as big, and only while the deepen test is on, that line may also name deepen. Relay whichever line came back. Do not add deepen yourself. Do not add a fact list, a confidence question, a record, or a disclaimer. When the user says more, why, or what else, call grill_result with detail more. When they say options, help me decide, or they are stuck, call grill_result with detail options. When they say full report, call grill_result with detail full. Do not write a layer yourself. Call grill_result with detail deepen only when the person asks to deepen or go bigger. Do not call it on a quick or bulk grill, and do not ask them to. Pass big: true only when they already marked the decision as big. Never ask whether it is big. Any stated choice counts, such as do it, yes, keep it, or delay. Confidence is optional. If they did not say a percent, leave it empty and do not ask. After a grill, don't start doing the decision (no code changes, no PRs, no product questions) unless the person separately asks. Grill's job ends at the verdict and the record. If Grill's settings name a judge model, that model is used, and it must be from a different company than the assistant that wrote the subject. A same-company pin is refused. Leave it blank to use Grill's default. If the result is a job id, call grill_result with it before you reply. Do not ask the user for a job id, and do not tell them how long it takes.

Input Schema

NameRequiredDescriptionDefault
bigNoOptional. true only when the person already marked this decision as big. Never ask whether it is big. Leave it off on a quick or bulk grill. It changes nothing before the verdict.
authorNoOptional. The model family that wrote the subject, if not Claude, for example openai, google or xai. That family is excluded from judging. If you are not Claude, always set it to your own family.
subjectYesThe decision as the user stated it, plus context already in the chat. Not a template, and not a case against you wrote.
questionNoOptional. Leave it empty unless the user asked a question of their own. Do not invent one.
quality_checkNoOptional. false skips the Jev quality check for this grill only, when the user asks. It never turns on a check the user switched off in settings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly and openWorld annotations, the description discloses that data goes to an outside judge from a different company, explains the zero-retention/privacy disclosure, mentions the optional quality check, same-company pin refusal, job-id handling, and post-verdict boundaries. These are substantive behavioral details that annotations alone do not provide.

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

Conciseness2/5

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

The purpose is front-loaded, but the description is far longer than necessary for a single tool invocation, with many repeated prohibitions and disclosure instructions. Several rules could be compressed without losing agent-relevant meaning.

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?

For a complex external-judge tool with privacy, disclosure, follow-up routing, and job-id behavior, the description covers what the agent needs to call it correctly and handle the result. There is no output schema, but the description explains the key return-handling behavior such as relaying layer 1 and calling grill_result when a job id is returned.

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 schema already documents all five parameters. The description adds operational meaning for big, quality_check, subject, and question, though it does not directly discuss author by parameter name, so it stops just short of full parameter elaboration.

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 states a specific action: send a decision, plan, or forecast to an outside AI judge from a different company, with the judge selected by openrouter/auto. It also distinguishes the initial grill call from follow-up grill_result calls by routing phrases like 'more', 'options', 'full report', and 'deepen'.

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?

It gives explicit when-to-use and when-not-to-use rules, including not pinning a model, not waiting for an OK, not adding a template, and not calling deepen on quick or bulk grills. It also maps exact user phrases to grill_result detail values, which is strong alternative routing.

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