Skip to main content
Glama
Sign In

NoBrainer Tech Flow

by io.github.nobrainer-tech
OverviewDiscussionsAdmin

Start a Flow task

start_flow_task
Read-onlyIdempotent

Use at the start of a non-trivial task. Checks your proposed outcome and definition of done (DoD) against Flow's contract rules, chooses the quick or full path, and returns DoD item IDs, a signed contract token and the first step. Computes only; stores nothing. Save the token in your goal file.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "outcome": "<outcome>",
      "dod": "<dod>"
    },
    "name": "start_flow_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
dodYes
risksNoRisks that add Flow modules and owner gates
outcomeYesObservable result and who sees it
non_goalsNo
local_flowNoVersion of a locally loaded Flow skill, if any

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-open-world, non-destructive; the description adds that it 'computes only; stores nothing,' which clarifies that persistence of the returned token is the caller's job. It also discloses side effects on routing ('chooses the quick or full path') and the exact artifacts returned, though it says nothing about what happens when contract rules are violated.

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?

Four tight sentences, front-loaded with the trigger condition, followed by behavior and the one operational follow-up. No filler, though the ordering could be slightly improved by stating the returned artifacts before the 'computes only' caveat.

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?

There is no output schema, so the description carries the return-shape burden and does so (DoD IDs, contract token, first step). For a 5-parameter contract-start tool the only remaining gap is error/failure behavior when the proposed outcome fails contract rules.

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 60%, and the description maps its checks to the two required parameters (outcome, DoD) but adds no meaning for risks, non_goals, or local_flow beyond what the schema already states. The enum values and defaults live only in the schema, so the description neither helps nor harms here.

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?

States a specific verb and resource ('Checks your proposed outcome and definition of done against Flow's contract rules') plus the tool's outputs (DoD item IDs, signed contract token, first step). The phrase 'at the start of a non-trivial task' temporally separates it from the check_flow_* siblings, which are clearly later-stage checks.

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?

Gives a clear activation condition ('Use at the start of a non-trivial task') and tells the agent what to do afterward ('Save the token in your goal file'). It does not name when-not-to-use or explicitly compare against check_flow_done/check_flow_evidence, so the sequencing must be inferred from 'start'.

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

All NoBrainer Tech Flow 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