Learning Optimizer

Learning Optimizer — Get Engine Script (large logs)

learning_get_engine

Read-only

For review logs over 2,000 rows, or any review file already in your code sandbox. Returns a complete numpy-only Python script with the same engine as learning_optimizer; it reads the file(s), prints the decision cards and writes every learner's lists, exam plans and item states to learning_result.json. Pass other inputs (exam_date, daily_review_limit, target_retention ...) in params. No learner data reaches this server on this path.

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": "learning_get_engine"
  }
}

Input Schema

Name	Required	Description
`params`	No	Other inputs exactly as learning_optimizer takes them (exam_date, daily_review_limit, target_retention, grade_scale ...).
`items_path`	No	Optional item bank file in your sandbox.
`reviews_path`	No	Review log file in your sandbox (CSV/TSV/JSON).

Output Schema

Name	Required	Description	Default
`notes`	No
`script`	Yes
`language`	No
`requires`	No
`items_path`	No
`writes_file`	No
`instructions`	Yes
`reviews_path`	No
`engine_version`	Yes
`scipy_required`	No
`data_requirements`	No
`network_access_required`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already establish read-only and non-destructive behavior, but the description adds important context beyond them: the tool returns an executable script, reads files locally, prints decision cards, and writes all learner outputs to learning_result.json. The privacy note ('No learner data reaches this server on this path') is exactly the kind of behavioral detail annotations cannot convey. It does not discuss runtime constraints or failure modes, so not a 5.

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?

The description is three sentences and front-loads the main use condition and output artifact. The long middle sentence is dense but every clause carries useful information about file handling, generated script contents, and the output JSON. No obvious 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?

For a code-generation tool with an output schema and annotated safety profile, the description covers the critical dimensions: when to choose it, what script is produced, what file it writes, and the privacy boundary. Minor omissions such as explicit runtime assumptions or handling of missing paths are not significant given the schema and output schema.

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 description coverage is 100%, so the schema already documents params, items_path, and reviews_path in detail. The description adds only that params should carry 'other inputs (exam_date, daily_review_limit, target_retention ...),' which largely echoes the nested schema description. Baseline 3 is appropriate.

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 artifact — returns a complete numpy-only Python engine script — plus the exact triggering condition: review logs over 2,000 rows or files already in the sandbox. It also names the sibling tool it mirrors ('same engine as learning_optimizer'), so an agent can distinguish this tool from the in-server optimizer without opening either schema.

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?

Gives a clear threshold condition ('over 2,000 rows') and an additional sandbox-file condition that select this tool over the sibling. It does not explicitly state the complementary case (use learning_optimizer directly for small logs), but the reference to the sibling and the size condition imply the alternative well enough.

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

All Learning Optimizer tools Inspect

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.