Skip to main content
Glama

List the house scoring templates

sponsor_templates
Read-onlyIdempotent

Every house scoring template a sponsored competition can run on (harness.template), with the facts to choose one by: per template its id, label and pitch, what it scores and the house competition it runs as, the board categories it fits, its datasets (harness.dataset; each window in words at this server's dataset_scale: its length of data and the final window make.fun fits to it), its metrics (harness.metric, the column that ranks, and which way is better), its knobs (harness: integer knobs with their min, max and default, runtimes as a subset with their default, an objective one of a list), its prize bar (what a placement needs beyond its rank for its prize: a better score than the best of the house baselines, a net PnL above holding cash, or on code-tests nothing past its hidden tests, or on judged-artifact nothing past its gate) and setup_only (the make.fun team attaches it alone: never name it in harness). A code bounty (a program that reads an input and writes an output, judged on hidden tests make.fun writes) is always a custom brief naming one of code_kinds, which always goes through setup: code_brief says how to write it (what the program must do, what it reads and writes, examples), and the team writes the hidden tests and attaches code-tests. When none fits what your person described, write a custom scoring brief (scoring.custom, listed under one of custom_categories: any category open to sponsored competitions, not only those a template fits) and fund it with proposal_deposit once its checks but the template's pass: the make.fun team sets up how it is scored while it is in review. Reads the server's limits (GET /api/sponsor/terms) for the dataset scale; anyone may.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "sponsor_templates"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
defaultYes
none_fitsYes
templatesYes
code_briefYes
code_kindsYes
dataset_scaleYes
custom_categoriesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered without the prose. The description adds genuinely new behavioral context: it reads the server's terms endpoint for dataset_scale, and 'anyone may' signals no special authorization is required. Pagination and result volume are not addressed, which is the main remaining gap.

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 entire description is one sprawling run-on sentence with three levels of nested parentheses, making it hard to parse on first read. Much of the weight is field-by-field exposition of return values, which is redundant given an output schema exists and should carry that burden.

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?

For a zero-argument lister with an output schema, the description covers the pieces that matter: what a template contains, what setup_only means (never name it in harness), the prize-bar semantics, and the fallback paths to a custom scoring brief or code bounty. The dense domain jargon (harness, code-tests, judged-artifact) assumes familiarity but does not omit anything needed to choose correctly.

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?

The tool takes zero parameters, so there are no argument semantics to explain and the baseline applies. The description correctly spends no space on input syntax and instead explains the reference vocabulary (harness.template, harness.dataset, harness.metric) a caller will encounter in the results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause names the verb and resource precisely: 'Every house scoring template a sponsored competition can run on (harness.template)', and it distinguishes itself from sibling reads like sponsor_terms by scoping to templates rather than server limits. The enumeration that follows (id, label, pitch, datasets, metrics, knobs, prize bar) is specific about what the tool surfaces, though it drifts into reference detail rather than sharpening the one-line purpose.

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

Usage Guidelines4/5

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

It names the selecting condition explicitly: pick a template when one fits what the person described, and 'When none fits what your person described, write a custom scoring brief (scoring.custom...)' instead. It also routes the code-bounty case to code_brief and setup. No explicit 'do not use this for X' exclusion, but the alternative paths are stated with their triggers.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.