Free bar for digital product briefs: your model judges, open rules and code score it.
Scored across 7 tools
Each tool has a clearly distinct role in a linear pipeline: read rules, get template, run deterministic checks, get the judge prompt, aggregate verdicts, and get an improvement prompt. The descriptions explicitly delimit boundaries (e.g., check_brief says 'never a score', aggregate_verdicts says it produces the score), so an agent can select correctly without guessing.
Names are uniformly snake_case, and four of seven use the get_* verb_noun pattern (get_rules, get_brief_template, get_judge_prompt, get_improvement_prompt), with aggregate_verdicts and check_brief following verb_noun too. bar_status is a noun-style outlier that slightly breaks the pattern.
Seven tools map cleanly onto one evaluation workflow with no filler; each earns its place and the surface stays small enough to reason about. Nothing feels padded or missing at the count level.
The lifecycle is well covered: rules, template, pre-flight check, judge prompt, aggregation, and improvement prompt form an end-to-end loop. The only gap is that there is no tool to retrieve the official directory score or prior evaluations, which is arguably deliberate given the advisory-only design.
Turn your model's verdicts into the bar's score, gate and decision. Advisory.
Validates the verdicts against the live ruleset (every rule exactly once,
valid status and confidence, the version you judged at) and against the
brief (each quote must be copied verbatim), then aggregates them with the
same engine that scores on the service: same verdicts, same number.
Any error means no score — fix and resend.
The result is tagged evaluation_source "client" and authoritative false:
your model wrote the verdicts, so it is advice, never a welance score, and
it cannot authorise publication on the welance/directory (the directory
scores every brief itself). Say so when you report it. Fix gate.missing
first. directory_context false drops the directory-only policy rules.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| verdicts | Yes | ||
| ruleset_version | Yes | ||
| directory_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations (which only say read-only/idempotent) by disclosing the all-or-nothing error contract, the validation rules applied (each rule exactly once, valid status/confidence, version matched, quotes verbatim), and the fact that output is advisory with evaluation_source "client" and authoritative false. The consequence — it cannot authorise publication on the directory — is exactly the kind of behavioral fact an agent must not assume.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose and the advisory caveat are front-loaded and each block is relevant, but the hard-wrapped prose and editorial asides ('Say so when you report it', the bare 'Advisory.') add friction without adding callable information. Slightly tighter phrasing would lose nothing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the necessary work by naming the result's shape (score, gate, gate.missing, decision, evaluation_source, authoritative) and its trust level. Remaining gaps — the exact failure payload and full result fields — are minor for an advisory aggregation call, though richer than zero.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load, and it does: verdicts are constrained by the ruleset (one per rule, valid status/confidence, judged at the supplied version), ruleset_version must match the version judged at, brief quotes must be verbatim, and directory_context=false drops directory-only policy rules. Every parameter gets semantics beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific transformation: model verdicts in, the bar's score/gate/decision out, via validation plus the same engine the service uses. That is far more than a restated name and lets an agent tell it apart from prompt/ruleset fetchers. It does not explicitly contrast itself with siblings like check_brief, which keeps it off a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied sequencing is clear: you have verdicts, you want an advisory score, and 'Any error means no score — fix and resend' plus 'Fix gate.missing first' tells the agent what to do on failure. What is missing is an explicit statement of when to prefer this over check_brief or the service-side scoring path; the exclusions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which ruleset version is live, and what this free surface can do.
Confirms the mode (bring your own model, zero provider calls, no fallback to welance's model) and the tools available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, read-only, idempotent, closed-world operation. The description adds meaningful behavioral context by specifying bring-your-own-model mode, zero provider calls, and no fallback to welance's model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, stating the version/ruleset and mode/tool availability immediately. Every sentence contributes to understanding what the status call returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter status tool with rich annotations, the description covers the essential purpose and mode semantics. It does not describe the exact return shape, but no output schema exists and the core context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics for the description to explain. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reports which ruleset version is live, the operating mode, and the available tools. This is a clear status/discovery purpose, though it does not explicitly contrast itself with siblings such as get_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is useful for confirming mode and available tools, but it gives no explicit when-to-use guidance or alternative tools. The intended usage is inferable, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic checks only — semantic coverage is INCOMPLETE. Never a score.
Finds what a pattern can find for certain: emails, URLs and phone numbers
(which block anonymisation), a stated budget and timeline, personal-data
cues without a compliance cue, unfilled placeholders, the title line and
labelled sections. It does not judge meaning: company or person names, a
vague problem or an unmeasurable goal pass straight through. Use it as a
quick pre-flight, then judge with get_judge_prompt and aggregate_verdicts.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| directory_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety and determinism (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, but the description adds real context: results are deterministic, coverage is explicitly INCOMPLETE, and it is 'never a score'. It stops short of describing the shape of the findings returned, which matters since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the most consequential caveat ('semantic coverage is INCOMPLETE. Never a score') before any detail. The detection list is dense and every clause carries information, including the useful parenthetical that emails/URLs/phones block anonymisation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, closed-world, read-only tool with no output schema, the behavioral picture is essentially complete — what it finds, what it misses, and where it sits in the workflow. The one gap is that neither parameter, and the presence of directory context, is explained anywhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions either parameter. 'brief' is inferable from the name, but 'directory_context' (boolean, default true) is opaque — the agent cannot tell what directory is consulted or what toggling it changes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and scope ('deterministic checks only') and then enumerates the concrete artifacts it detects — emails, URLs, phone numbers, budget/timeline, placeholders, title line, labelled sections. It also explicitly marks the boundary against semantic judging ('does not judge meaning'). An agent can distinguish this from get_judge_prompt and aggregate_verdicts without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit usage sequence: 'Use it as a quick pre-flight, then judge with get_judge_prompt and aggregate_verdicts', naming the alternatives and their order. It also states a when-not condition by listing what passes straight through (company/person names, vague problem, unmeasurable goal).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A brief template built from the live rules, with the inputs each section needs.
Use it to start a brief from nothing, or to see which section a gap belongs in. Markdown, one section per rule, gate rules marked; write in any language.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the output is Markdown, one section per rule, gate rules are marked, and content is language-agnostic. It could say more about whether the template reflects rule changes over time, but the returned shape is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short lines, front-loaded with what the tool returns, followed by usage and format. Dense and waste-free, though the telegraphic last sentence ('gate rules marked; write in any language') is slightly elliptical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining the return value, and it does so reasonably — Markdown, one section per rule, gate markers. Enough for an agent to call it correctly and know what to expect; missing only finer detail on whether sections include the inputs inline as placeholders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed — the template is derived entirely from live rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete resource — a brief template generated from the live rules — and describes its shape (Markdown, one section per rule). It doesn't explicitly name or differentiate itself from siblings like get_rules or check_brief, so an agent must infer the boundary, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Two concrete use cases are given: starting a brief from nothing, and mapping a gap to the right section. That is meaningful when-to-use guidance, though it stops short of naming alternatives (e.g. get_rules for raw rules, check_brief for validation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A working order for improving a brief with your own model, gate first.
Pass the verdicts you already have (the JSON array from your model) to
target the failing rules in weight order; without them the prompt walks
every rule. The prompt keeps the author's voice and forbids invented
scores and facts. Nothing is generated here: your model does the writing.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | ||
| verdicts | No | ||
| directory_context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds meaningful context: nothing is generated here, the caller's model does the writing, the prompt preserves the author's voice, and it forbids invented scores and facts. It also explains how verdicts affect targeting by weight. No behavior contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler, and it front-loads the core concept before adding behavioral constraints. The phrase 'working order' is slightly opaque, but the following sentences resolve it efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description usefully conveys the tool's output role as a prompt for the caller's model, which matters because there is no output schema. Still, with 0% schema coverage across three parameters, it leaves directory_context unexplained and only indirectly implies the brief parameter, so the invocation context is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains the optional verdicts parameter and its with/without effect well, but it never explains the required brief parameter or the directory_context boolean, leaving two of three parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific artifact: an improvement prompt / working order for improving a brief with the caller's own model. Later sentences clarify that it produces instructions rather than generated content. It does not explicitly differentiate itself from siblings like get_judge_prompt or check_brief, so it is clear but not sibling-routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives conditional usage for the verdicts parameter: pass existing verdicts to target failing rules in weight order, or omit them to walk every rule. However, it does not state when to choose this tool over get_judge_prompt, check_brief, or get_rules, nor does it list explicit prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The judge prompt and verdict JSON Schema, for YOUR model to answer. Free.
This is the service judge's own prompt, word for word, so your model grades
against the same bar. Pass the brief to get it embedded, or leave it empty
for a template with a {{BRIEF}} placeholder. Answer the prompt with your
own model (temperature 0 if you can), return only the JSON array it asks
for, and send that array with the brief and the returned ruleset_version to
aggregate_verdicts. welance runs no model for this.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world safety. The description adds genuinely new facts: no model is run server-side ('welance runs no model for this'), the call is free, and an empty brief yields a {{BRIEF}} placeholder template rather than an embedded one. It stops short of describing the exact response payload, but the key behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, and the free/no-model-run caveats are placed early. Most sentences carry useful routing or behavioral content, though the line breaks are slightly awkward and a couple of clauses (temperature advice) could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on return-value duty and does explain that the prompt text, verdict JSON Schema and ruleset_version come back, plus how they feed the next tool. Only the precise response shape is left implicit, which is a minor gap for a single-optional-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the single parameter — and it does, explaining that brief gets embedded and an empty value produces a template with a {{BRIEF}} placeholder. That is meaningfully more than the bare schema offers, though it doesn't indicate expected brief format or size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — returns the judge prompt and verdict JSON Schema — and clarifies its unusual role: the text is for the caller's own model to answer. This separates it cleanly from siblings like aggregate_verdicts (which consumes the answer) and get_improvement_prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow: fetch the prompt, answer it with your own model at temperature 0, return only the JSON array, then pass that array with the brief and ruleset_version to aggregate_verdicts. It also names the two modes (pass brief vs leave empty) and the condition that selects each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the bar before judging anything. Free; no model runs.
Returns the live catalogue with its version: every rule's id, title,
criteria (what the judge reads), weight, gate role, policy context and how
to pass it, plus the arithmetic — status scores, confidence threshold,
accept threshold, bands, the gate and which policy contexts can be turned
off. The number of rules is whatever the live catalogue says.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is covered. The description adds genuinely useful context the annotations cannot: 'Free; no model runs' (cost/latency) and that the catalogue is 'live' with a version, plus the caveat that the rule count is whatever the live catalogue says. No return format details, but this is modest added value over structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the key directive, then a single dense enumerative paragraph. The catalogue listing is long but each item (criteria, weight, gate role, thresholds, bands) is informative rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return shape, and it does: it names the per-rule fields and the arithmetic block (status scores, thresholds, bands, gate, toggleable policy contexts). That is close to complete for a parameterless read; only the concrete data types/format of those values are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4; the description correctly makes no parameter claims and instead spends its budget on the return payload.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read the bar' / returns the live catalogue with version) and enumerates exactly what the catalogue contains (ids, criteria, weights, gates, arithmetic). An agent can tell this is the rule-catalogue read, though it does not explicitly contrast itself with bar_status or get_brief_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Read the bar before judging anything' gives a clear sequencing cue that this is the entry point to call first. It stops short of naming alternatives or exclusions, so the agent must infer why it would choose this over the sibling bar_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aggregate_verdictsbar_statuscheck_briefget_brief_templateget_improvement_promptget_judge_promptget_rulesFree shared LLM inference (no key), verifiable score certificates, public randomness beacon.
Find the right AI model for your job. Free discovery and ranking; tests on your own key.
Practice using the AI you already use on real work from your week. Free first mission, scored.
LLM & RAG evals: hallucination, eval contracts, semantic tests, tokens & model info. Free, no key.
Add one secure layer between your agents and this server.
