Skip to main content
Glama
Sign In

NL;NL Labs

by com.nlnllabs
OverviewDiscussionsAdmin

All models on one day

get_day_results
Read-onlyIdempotent

Use to compare the models and systems on one job on one day. Leave date out for the newest day. Returns every model's and system's published result that day, NL;NL Labs' own models and systems marked. Extract's documents days also carry invented, missed and unreadable counts. Fields: cost_per_1000_right_usd and ipd are exact; cost_shown and ipd_shown are how the page shows them. assembled_by_us is 1 when the answer was assembled by us, else 0. A count marked "not published for this model" is not published for that model.

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": {
      "job": "<job>"
    },
    "name": "get_day_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
jobYesJob id.
dateNoYYYY-MM-DD. Default: newest day.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / job / description
      Previous value: -"Job id (see list_jobs)."New value: +"Job id."
  2. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, closed-world safety profile, and the description adds real context on top: that NL;NL Labs' own models are marked, that extract adds invented/missed/unreadable counts, and what a 'not published for this model' count means. It stops short of describing ordering, result size, or the return envelope.

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

Conciseness3/5

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

The purpose is front-loaded in sentence one, which is good. The remainder is a dense run-on field glossary with undefined terms (ipd, cost_shown) and an awkward passage ('Extract's documents days'), which costs readability even though no sentence is outright filler.

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?

With no output schema, the description correctly takes on the burden of describing return fields and does so for most of them. Coverage is strong but a few field names (ipd, ipd_shown) are left without plain-language meaning, which is the main completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters already carry descriptions and an enum, so the schema does the heavy lifting. The description merely restates the default-date behavior already documented in the schema and says nothing about selecting a job id.

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 first sentence names a specific verb and scope: compare all models and systems on one job for one day. That distinguishes it reasonably well from day-agnostic or single-result siblings, but no sibling is named, so the differentiation is inferred rather than stated.

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

Usage Guidelines3/5

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

The description gives one concrete operating rule — leave date out for the newest day — which is genuinely useful. It offers no when-not-to-use guidance or comparison to get_model_history or get_pick, so an agent must guess which tool to reach for.

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

All NL;NL Labs toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources