Skip to main content
Glama
Sign In
kanibal-tools-mcp

kanibal-tools-mcp

Official
by kanibal-studio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

select_least_cost_capable_model

Read-onlyIdempotent

Selects the least-cost AI model from a supplied catalogue that meets every required capability and is available and authorized, returning the selection basis and exclusions.

Instructions

Pick, from a supplied catalogue, the model with the lowest declared cost rank among those that have every required capability and are available and authorised.

Returns status "selected" with the comparison basis, "needs_information" naming the
missing or non-comparable evidence, or "no_candidate_in_catalogue", plus exclusions. Use it to choose
between AI models from facts you supply; it is unrelated to lead sources. Nothing
is called, switched or launched; savings are not guaranteed.

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": {
      "catalogue": "<catalogue>"
    },
    "name": "select_least_cost_capable_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
catalogueYesRequired capabilities and candidate models with their declared cost evidence.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / catalogue / description
      Added value: +"Required capabilities and candidate models with their declared cost evidence."
    • addedInput schema / properties / catalogue / properties
      Added value: +{
+  "models": {
+    "items": {
+      "properties": {
+        "authorized": {
+          "type": "boolean"
+        },
+        "available": {
+          "type": "boolean"
+        },
+        "capabilities": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "capabilities_complete": {
+          "description": "Only a complete list can exclude a model.",
+          "type": "boolean"
+        },
+        "cost": {
+          "description": "Ranks compare only when metric, unit, workload and window match.",
+          "properties": {
+            "as_of": {
+              "type": "string"
+            },
+            "metric": {
+              "type": "string"
+            },
+            "relative_rank": {
+              "description": "Lower means cheaper.",
+              "type": "number"
+            },
+            "source": {
+              "type": "string"
+            },
+            "unit": {
+              "type": "string"
+            },
+            "window": {
+              "type": "string"
+            },
+            "workload": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "id": {
+          "description": "Unique model identifier.",
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "required_capabilities": {
+    "description": "Capabilities the task needs, e.g. [\"python\", \"debugging\"].",
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  }
+}
    • addedInput schema / properties / catalogue / required
      Added value: +[
+  "required_capabilities",
+  "models"
+]
  2. First observedv0.1.0

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-destructive and closed-world, and the description reinforces that with 'nothing is called, switched or launched; savings are not guaranteed', which tells the agent this is advisory only, not an execution step. The three return statuses add outcome-level context the annotations cannot express.

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 selection rule is front-loaded in the first sentence, and the return-status sentence follows immediately. The trailing 'unrelated to lead sources' clause is slightly defensive but earns its place as sibling disambiguation.

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 single-parameter, read-only selection tool with a full output schema, the description covers selection criteria, failure modes and the non-action guarantee. An agent could invoke it correctly from this alone; only edge cases such as how exclusions are reported in detail are left to the output schema.

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 description coverage is 100%, and the nested schema already documents capabilities_complete, relative_rank comparability and required_capabilities. The description restates the catalogue concept but adds no syntax or format guidance beyond it, so the baseline 3 applies.

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 precise verb and object: pick the lowest declared cost rank among models that satisfy every required capability and are available and authorised. This is unmistakably distinct from the sibling lead-generation tools, and the description even says so explicitly.

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?

It says to use it to choose between AI models from facts the caller supplies and that it is unrelated to lead sources, which routes the agent away from the sibling tools. It stops short of naming positive alternatives or stating when a different selection tool would be better.

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

Deploy Server

Other Tools