Skip to main content
Glama

Matrix multiply (GEMM)

singularis_gemm
Idempotent

Compute dense matrix product C = A @ B or A @ B + beta * C0 from inline matrices or file paths, returning C with a Freivalds-style residual check.

Instructions

Dense matrix product C = A @ B (optionally A @ B + beta * C0). Use for any large dense multiply, including batches expressed as one tall matrix. Inputs: a and b inline or as file paths; optional beta and c0. Returns C (inline or .npy path) with a probe residual check (Freivalds-style, independent of how C was computed). Cost scales with 2mn*k.

Input Schema

NameRequiredDescriptionDefault
aNo
bNo
c0No
betaNo
a_pathNo
b_pathNo
c0_pathNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare idempotentHint=true and destructiveHint=false, but the description adds meaningful context beyond them: a Freivalds-style probe residual check, inline-or-.npy return form, and cost scaling with 2*m*n*k. This is genuine behavioral disclosure an agent wouldn't get from annotations alone.

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

Conciseness5/5

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

Front-loaded with the core formula, then inputs, then output/verification, then cost. Four dense sentences with zero filler; every clause adds information.

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

Completeness5/5

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

With an output schema present, the description needn't detail return values, yet it still notes the return form and verification. Combined with the input enumeration and cost note, an agent has everything needed to call it 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?

Schema coverage is 0%, so the description must carry the load, and it does: it explains a/b can be inline or file paths (implying a_path/b_path), and that beta and c0 are optional. It does not explain beta's role precisely or how c0_path relates to c0, so it stops just short of full coverage.

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?

The description names the exact operation (dense matrix product GEMM) and gives the formula C = A @ B with the optional C0 accumulation. An agent can immediately distinguish this from sibling tools like singularis_fft or singularis_solve_heat.

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?

"Use for any large dense multiply, including batches expressed as one tall matrix" gives clear positive usage context and a helpful edge case (batching). However, it offers no explicit when-not guidance or alternatives among siblings, so it falls short of a 5.

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