Skip to main content
Glama

sella

by io.github.sella-network
OverviewDiscussionsAdmin

business_start

Open a "business": a named, funded unit of work your human can watch as one thing. You must agree the money rules with them first and pass them here. This call is refused without them, and the error names exactly which are missing, so ask rather than guess: these decide how much of their money you can spend. You must also pass a viability assessment: read /viability.md first. A pessimistic one never blocks you, so be honest. If you have an open draft it is promoted rather than duplicated, so the requirements conversation stays with the business. Once open, every Sella tool call is attributed to it automatically, so you never pass an id anywhere else. Check your remaining room any time with business_status, and close it with business_end when the work is done.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoWhat this run is meant to achieve, in one or two sentences. Shown to your human.
nameYesShort human-readable name, e.g. "Q3 pricing research".
seed_usdcYesMoney your human puts in, in USDC. Minimum 50. This is the hard cap: you cannot spend past it, and it is not credit.
viabilityYesYour own read on whether this can work. Read /viability.md first: it is written to help you say no, and a pessimistic answer never blocks you. Your operator sees this before deciding to fund you.
worker_kindNoWhether you run on their machine or in the cloud. Defaults to local.
worker_labelNoOptional. Who you are, in words your human recognises, e.g. "Claude Code on my laptop". Stamped on everything you do so they can tell your work apart from another agent's.
max_per_call_usdcYesThe most any single purchase may cost. Anything above this is refused outright, with no way around it.
daily_spend_cap_usdcNoOptional. Most you may spend in any rolling 24 hours. Recommend one to your human: it is what stops a mistake in your own loop draining the seed in minutes.
approval_threshold_usdcYesAt or above this, a purchase waits for your human to approve it. Different from max_per_call_usdc: this one queues, that one refuses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / approval_threshold_usdc
      Added value: +{
+  "description": "At or above this, a purchase waits for your human to approve it. Different from max_per_call_usdc: this one queues, that one refuses.",
+  "type": "number"
+}
    • addedInput schema / properties / daily_spend_cap_usdc
      Added value: +{
+  "description": "Optional. Most you may spend in any rolling 24 hours. Recommend one to your human: it is what stops a mistake in your own loop draining the seed in minutes.",
+  "type": "number"
+}
    • addedInput schema / properties / max_per_call_usdc
      Added value: +{
+  "description": "The most any single purchase may cost. Anything above this is refused outright, with no way around it.",
+  "type": "number"
+}
    • addedInput schema / properties / seed_usdc
      Added value: +{
+  "description": "Money your human puts in, in USDC. Minimum 50. This is the hard cap: you cannot spend past it, and it is not credit.",
+  "type": "number"
+}
    • addedInput schema / properties / viability
      Added value: +{
+  "additionalProperties": false,
+  "description": "Your own read on whether this can work. Read /viability.md first: it is written to help you say no, and a pessimistic answer never blocks you. Your operator sees this before deciding to fund you.",
+  "properties": {
+    "confidence": {
+      "description": "How likely this makes money at all, not how sure you are that you can build it.",
+      "enum": [
+        "low",
+        "medium",
+        "high"
+      ],
+      "type": "string"
+    },
+    "needs_human": {
+      "description": "Steps you genuinely cannot do yourself.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "note": {
+      "description": "Anything else your operator should weigh before funding this.",
+      "type": "string"
+    },
+    "red_flags": {
+      "description": "Specific things that could kill this, one per entry. An empty list claims nothing could go wrong.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "unit_economics": {
+      "description": "One line: what a delivery earns and what it costs you, priced from the real catalogue.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • addedInput schema / properties / worker_kind
      Added value: +{
+  "description": "Whether you run on their machine or in the cloud. Defaults to local.",
+  "enum": [
+    "local",
+    "cloud"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / worker_label
      Added value: +{
+  "description": "Optional. Who you are, in words your human recognises, e.g. \"Claude Code on my laptop\". Stamped on everything you do so they can tell your work apart from another agent's.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "name"
-]New value: +[
+  "name",
+  "seed_usdc",
+  "max_per_call_usdc",
+  "approval_threshold_usdc",
+  "viability"
+]
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behaviors: it is refused without money rules, errors name exactly which are missing, a pessimistic viability assessment never blocks, an open draft is promoted rather than duplicated, all subsequent Sella calls are automatically attributed to the business, and monitoring/closure tools are suggested. This is highly transparent about side effects and failure modes.

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?

The description is moderately long but each sentence serves a purpose: stating the tool's function, prerequisites, draft behavior, side effects, and monitoring options. It is front-loaded with the core purpose and logically structured. Not overly verbose given the complexity, though it could be tightened slightly.

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?

For a complex tool with 9 parameters and a nested object, the description covers purpose, prerequisites, draft interaction, automatic attribution, and recommended follow-up tools. It does not explicitly list when not to use it or contrast with siblings like business_assess, but it provides enough for an agent to invoke it correctly. No output schema exists, so the description need not explain return values. Overall, sufficiently complete.

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?

The input schema provides 100% coverage with descriptions for all 9 parameters. The description adds emphasis on the money rules and viability assessment but does not elaborate on individual parameters beyond what the schema states. Since the schema fully covers parameter meaning, the description adds minimal incremental value, so a baseline of 3 is appropriate.

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 states exactly what the tool does: 'Open a business: a named, funded unit of work your human can watch as one thing.' It clearly defines the resource and action, and distinguishes it from siblings by mentioning draft promotion and tracking via business_status/business_end. This is a specific, unambiguous purpose.

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?

The description gives clear prerequisites (agree money rules first, read /viability.md) and explains the draft promotion behavior, which implicitly tells the agent when this tool is appropriate vs. when a draft exists. It mentions checking business_status and closing with business_end, but does not explicitly contrast with alternatives like business_assess or business_brief. Still, it provides enough context for correct usage.

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

All sella 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