Affine Earth Math Court Remote

game_frame_meta

Run a language-game context and return its state plus the cell's own self-evaluation of the rendered frame - integer score 0-1000 over occupancy, spread, contrast and edge quality, with the C4 span correction applied. Stateless: (kind, seed, t, n, at_seq) fully determine the result.

Input Schema

TableJSON Schema

Name	Required	Description
`h`	No	decimal string
`n`	No	decimal string, population
`t`	No	decimal string, step index
`w`	No	decimal string
`kind`	No
`seed`	No	decimal string; JSON numbers still admitted
`at_seq`	No	decimal string, pinned corpus epoch
`target`	No	decimal string, refine until score >= this (0-1000, default 950)
`max_iter`	No	decimal string, iteration cap, default 10

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden and does a solid job. It explicitly discloses statelessness and determinism—'(kind, seed, t, n, at_seq) fully determine the result'—and specifies the score range and evaluation components. It does not detail the 'state' structure or error behavior, but the side-effect profile is clear.

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 compact and front-loads the core action and deterministic contract in two sentences. The only notable jargon is the unexplained 'C4 span correction', but the overall structure has no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives good score semantics and determinism, but the returned 'state' is not described and there is no output schema to compensate. For a domain-specific tool with nine parameters and no annotations, this leaves some ambiguity for an agent.

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 high (89%), so the description does not need to re-document every parameter. It adds meaningful semantic information by naming the five determinative parameters, though the roles of h and w are left unexplained.

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 description names a specific action and resource ('Run a language-game context') and clearly specifies the two output components: the state and a self-evaluation score. The score's range and composition are also stated, though it does not explicitly differentiate itself from a sibling like critique_frame.

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 intended use case is implied: obtain a deterministic language-game frame state and its self-evaluation. However, there is no explicit guidance on when to prefer this tool over alternatives or when not to use it.

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

All Affine Earth Math Court Remote tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.6/5.0

Disambiguation2/5

Many verify_* tools are distinct, but there are overlapping clusters: math_court duplicates execute_2local_hamiltonian, route_spin_glass_manifold, and the quantum verifiers; project_affine_key, expose, verify_presented_pair, and the optional affine exposes in other tools blur together; weather and geometry tools also overlap. The detailed descriptions help a human, but an agent would likely struggle to choose between equivalent-seeming entry points.

Naming Consistency2/5

Naming is mostly snake_case but otherwise inconsistent: some tools use dotted prefixes (atc.*, twin.robotics.*, weather.*), some use bare verbs (expose, lattice_op, math_court), some use noun phrases (corpus_bonds, feeds_catalog), and others mix prefixes with verbs (ide_rebuild_mesh, umc_resume). The verify_* family is consistent, but the overall set has no single predictable verb_noun pattern.

Tool Count2/5

49 tools is far above the typical well-scoped server size and includes multiple near-duplicate paths to the same law (math_court, execute_*, route_*, verify_*). While not quite 50+, the count still feels like a sprawling kitchen-sink rather than a deliberate minimal surface.

Completeness3/5

The toolset covers a surprisingly wide range: QC verifiers, QMA laws, affine projections, corpus reads, weather, UMC state, and robotics IK. However, there are notable gaps for such a broad surface: no general court case lifecycle beyond expose/seal, no corpus content search, and no way to manage or update sealed artifacts; several areas have only entry-point coverage.

Resources

Need Help?