trading-swarm-mcp

Overview Schema Source Related Servers Discussions Admin

Validate Genome

warden.validate_genome

Read-onlyIdempotent

Validate a trading strategy genome against its bounded schema and return the canonical genome_hash for reproducible strategy identity, challenger IDs, and audit requests.

Instructions

Validate a genome against the bounded schema and return its canonical genome_hash.

The hash is the reproducible strategy identity used as challenger_id in the hosted tournament and in audit_request blocks.

Input Schema

Name	Required	Description	Default
`genome`	Yes	Genome object (bounded schema, versioned).

Output Schema

Name	Required	Description	Default
`how`	No
`note`	No
`tool`	No
`error`	No
`valid`	No
`access`	No
`errors`	No
`genome_hash`	No
`schema_version`	No
`request_access_at`	No
`schema_version_current`	No
`evaluated_schema_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.6.2Oct 16, 2026

addedOutput schema / properties / evaluated_schema_version

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Evaluated Schema Version"
+}

addedOutput schema / properties / schema_version / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / schema_version / type
```
Removed value: -"integer"
```

First observedv0.4.1Sep 25, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine non-obvious context beyond that: the hash is a reproducible strategy identity reused as challenger_id and in audit_request blocks, which is behavior an agent could not infer from the schema or annotations.

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?

Two sentences with the verb and result front-loaded, followed by the one piece of downstream context that matters. No filler, no repetition of the title or schema.

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 and the annotations cover safety, so the description need not explain return shapes or side effects, and the hash semantics are covered anyway. The one omission is failure behavior — what a validation rejection looks like — which matters for a validator but is a minor gap given the structured coverage.

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 the single 'genome' parameter is documented as a versioned bounded schema, so the schema carries the meaning. The description only restates 'validated against the bounded schema' without adding format, version, or constraint detail, so the baseline 3 applies.

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?

States a specific verb+resource ('Validate a genome') and names the concrete output ('return its canonical genome_hash'), so the agent knows exactly what it gets back. It is implicitly distinguished from the sibling warden.validate_order by resource, but no sibling is named or contrasted explicitly.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative among the seven siblings. Usage is only implied by the note that the hash feeds the hosted tournament and audit_request blocks, which hints at the workflow context without stating it.

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

Deploy Server