llmledger

Overview Schema Source Related Servers Discussions Admin

Local Or Cloud

local_or_cloud

Read-onlyIdempotent

Compare running an open model on bought hardware vs paying a cloud model per call: monthly cost, break-even month, and load capacity.

Instructions

Compare running an open model on a computer you buy with paying a cloud model per call: the cost a month each way, the month the computer pays for itself, and whether it keeps up with the load. Use when the question is whether to buy hardware for a local model. Needs timed runs of the local model (log_run) and the computer's price; electricity comes from EIA or the user's own rate. Not for cloud-only comparisons (compare_models or estimate_cost).

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": {
      "local_model": "<local_model>",
      "cloud_models": "<cloud_models>",
      "input_tokens": "<input_tokens>",
      "output_tokens": "<output_tokens>",
      "calls_per_month": "<calls_per_month>",
      "hardware_price": "<hardware_price>"
    },
    "name": "local_or_cloud"
  }
}

Input Schema

Name	Required	Description	Default
`state`	No	A US state, for EIA's average there, for example Texas
`watts`	No	Power the computer draws while it answers, in watts
`months`	No	How many months to compare over
`thinking`	No	Thinking turned on for the local model
`local_way`	No	How the local model is called	ollama
`local_model`	Yes	The open model you would run at home, as Ollama names it, for example llama3.1:8b
`cloud_models`	Yes	1 to 5 cloud models to compare with
`input_tokens`	Yes	Prompt tokens per call
`cached_tokens`	No	Prompt tokens read from the cloud model's cache
`output_tokens`	Yes	Answer tokens per call, including hidden thinking
`hardware_price`	Yes	What the computer costs you, in dollars
`calls_per_month`	Yes	Calls a month
`electricity_price`	No	Your electricity price, dollars per kWh (default: EIA's average for homes)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.7Oct 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds real context beyond them: the tool depends on prior log_run measurements and pulls electricity cost from EIA or a user-supplied rate. It does not discuss sensitivity of the break-even result or how load feasibility is judged, which keeps it short of a 5.

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?

Three sentences, front-loaded with the decision the tool answers, then prerequisites, then exclusions. Phrasing like "the cost a month each way" is slightly compressed but no sentence is wasted; structure is sound.

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 13-parameter, 6-required analysis tool with an output schema and full annotations, the description covers purpose, prerequisites, and alternatives adequately. Remaining gaps (result interpretation, what happens with missing run data) are minor given the output schema documents return values.

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%, so all 13 parameters are already documented, including the electricity_price default and the state/watts options. The description only reinforces the electricity source and the hardware-price input, adding little beyond the schema; 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 specific comparison verb and both resources: local hardware cost versus per-call cloud cost, plus the derived outputs (break-even month, whether it keeps up with load). It also names the sibling tools it is not, so an agent can separate it from compare_models and estimate_cost without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit use condition ("Use when the question is whether to buy hardware for a local model"), explicit exclusion ("Not for cloud-only comparisons (compare_models or estimate_cost)"), and stated prerequisites (timed runs via log_run, hardware price). Nothing is left to inference.

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

Deploy Server