Skip to main content
Glama
Sign In

knos

by io.github.drexthealpha
OverviewDiscussionsAdmin

Submit to a referee-checked milestone

knos_milestone_submit
Destructive

Sends a milestone's proof file to its referee and releases its devnet test money to you when the verdict meets the target; ask your human first.

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

Input Schema

NameRequiredDescriptionDefault
codeNothe whole train.py
kindNoa lab's proof instead of code: a FHIR Observation or an HL7 ORU message, checked by the rules referee IRIS runs too (the decision only; nothing moves)
briefNothe locked brief the lab proof answers
proofNothe Observation (an object) or the ORU message (a string)
walletNo
projectNo
sessionNo
milestoneNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / brief
      Added value: +{
+  "description": "the locked brief the lab proof answers",
+  "type": "object"
+}
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "a lab's proof instead of code: a FHIR Observation or an HL7 ORU message, checked by the rules referee IRIS runs too (the decision only; nothing moves)",
+  "enum": [
+    "observation",
+    "oru"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / proof
      Added value: +{
+  "description": "the Observation (an object) or the ORU message (a string)"
+}
    • changedInput schema / required
      Previous value: -[
-  "project",
-  "milestone",
-  "code"
-]New value: +[]
  2. Added

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructive=true, non-idempotent, non-read-only, so the safety bar is lower; the description still adds real context by disclosing that funds move only when the verdict meets the target and that human confirmation is required. It omits what makes it destructive, whether funds move on failure, and the consequences of resubmitting given idempotentHint=false.

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?

A single front-loaded sentence with no filler; the effect and the human-confirmation caveat are both packed economically. It is arguably too compact for a tool with eight parameters, but nothing is wasted.

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

Completeness2/5

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

For an eight-parameter, nested-object, no-output-schema money-releasing action, the description covers only the headline. It never clarifies the code submission path versus the lab-proof path, what the referee returns, or what the session/project/milestone identifiers are for.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Eight parameters at 50% schema coverage, and wallet, project, session, and milestone carry no description in either the schema or the tool description. The description explains no parameter at all, leaving the two big input shapes (code vs. kind/proof/brief) to be discovered purely from the schema.

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 and resource ('sends a milestone's proof file to its referee') plus the outcome ('releases its devnet test money'). It is distinguishable from knos_task_submit by resource, but never names the near-sibling knos_iris_check_proof, which runs the same referee rules in check-only mode, so the boundary is left implicit.

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 one real usage rule, 'ask your human first', which is a meaningful precondition for a committing action. It does not say when to prefer this over knos_iris_check_proof (validate first) or knos_task_submit, nor what to do when the verdict misses the target.

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

All knos toolsInspect
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.

Resources