CovaSyn Chemistry Tools

covadoe_create_design

Create an experimental design (factorial, fractional, CCD, BBD, D/I-optimal, Taguchi, LHS, simplex mixture, etc.).

Optional: `constraints` — list of {terms:{factor:coef}, op:"<="|">="|"==", rhs} in REAL units —
filters the D/I-optimal candidate set. `mixture=True` with a simplex `design_type`
("simplex_lattice"/"simplex_centroid") builds a bounded-mixture design (L-pseudocomponent,
components sum to 1, each ≥ its `low`); `degree` sets the simplex-lattice degree; `n_levels` sets
the D/I-optimal candidate-grid density.

Model-aware optimal designs: `model_terms` ("linear"|"interaction"|"quadratic") sets the model
matrix the D/I-optimal criterion optimizes for. `n_blocks` (>1) adds a "Block" column, confounding
the highest-order interaction(s) for factorial designs. `n_runs` / `resolution` / `generators`
control the `fractional_factorial` fraction, in that precedence order: `n_runs` (a power of 2,
counting base runs before center points) pins the fraction exactly — e.g. n_runs=16 on 5 factors
gives 2^(5-1), resolution V; `resolution` (3/4/5...) picks the smallest fraction reaching it;
`generators` gives the defining generators verbatim as pyDOE2 tokens, one per factor
(e.g. ["a","b","c","ab","ac"] for 2^(5-2)).
`design_type="taguchi"` builds an orthogonal-array design (`taguchi_levels` 2 or 3). `hard_to_change`
(list of factor names) produces a split-plot layout with a "WholePlot" column. `process_factors`
(with `mixture=True`) builds a mixture-process crossed design (`process_design_type`,
`process_center_points`). `n_runs` also sets the run count for D/I-optimal designs (default
len(factors)*3+1) and the sample count for latin_hypercube / sobol_sequence.

CCD variant: `face` — "circumscribed" (default), "faced" (star points on the faces, α = 1, for
factors that cannot physically exceed their range) or "inscribed" (the CCC scaled so the star
points land on the stated range). `axial_alpha` sets the axial distance; the default is
ROTATABLE, (2**k)**0.25, and "orthogonal" gives the α where Σx² = n_runs. The choice is worth
several points of power — check it with `covadoe_design_power` before running the design.

Common `design_type` aliases resolve ("full_factorial", "ccd", "dsd", "bbd"); the response
reports the canonical name actually built.

Input Schema

Name	Required	Default
`face`	No
`degree`	No
`n_runs`	No
`api_key`	No
`factors`	Yes
`mixture`	No
`n_blocks`	No
`n_levels`	No
`generators`	No
`resolution`	No
`axial_alpha`	No
`constraints`	No
`design_type`	Yes
`model_terms`	No	linear
`n_replicates`	No
`hard_to_change`	No
`taguchi_levels`	No
`n_center_points`	No
`process_factors`	No
`process_design_type`	No	full_factorial_2k
`process_center_points`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does it well: it explains that `constraints` filters the candidate set, that `mixture=True` forces components to sum to 1 and each ≥ its `low`, that `n_blocks` confounds highest-order interactions, that aliases resolve and the response reports the canonical name. It omits any mention of auth (`api_key`), rate limits, or the effort cost of D/I-optimal generation.

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?

Long, but the length is proportionate to a 21-parameter combinatorial tool, and the purpose is front-loaded in the first line. The parameter prose is dense and only lightly segmented, which slightly hinders scanning but every sentence carries substantive information rather than padding.

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?

An output schema exists, so return values need not be explained, and the description still adds the useful note that the response reports the canonical design name. For a 0%-coverage, 21-parameter tool it covers the design-space parameters thoroughly; the gaps are the shape of the required `factors` objects and the few unmentioned knobs (`n_replicates`, `n_center_points`).

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 compensate, and it documents roughly fifteen of the twenty-one parameters with real semantics (precedence rules, defaults, token format for `generators`, α rules for `axial_alpha`). The required `factors` structure, `api_key`, `n_replicates`, and `n_center_points` remain undocumented in both schema and description, which keeps it short of a 5.

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?

Opens with a specific verb+resource ('Create an experimental design') and enumerates the design families it can build, so the agent immediately knows the scope. It does not distinguish itself from close siblings, however — notably `covadoe_suggest_design`, `covadoe_augment_design`, and especially `covadoe_taguchi`, whose functionality is duplicated here via `design_type="taguchi"` with no routing note.

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?

Gives real usage context for parameters (e.g., when to use `face="faced"` for factors that cannot exceed their range, precedence order for `n_runs`/`resolution`/`generators`) and points to `covadoe_design_power` as a follow-up check. What is missing is when to choose this tool over `covadoe_suggest_design` or the dedicated `covadoe_taguchi` tool, leaving sibling routing to inference.

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

All CovaSyn Chemistry Tools 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.