Kaiku

Computation hours

computation_hours

Read-only

What a project's computations spent over a period — the machine-hours of its stats screen: CPU-hours measured and core-hours allocated in total, by machine, by week (weeks begin on Monday) and the issues that spent most, and how many jobs finished done, failed, cancelled or lost in it. Only the time inside the period counts: a job that ran across its edge is cut there in proportion, and a job still running counts up to now. All figures are seconds; 'machineSeconds' is measured CPU time where a runner sent one and cores × wall clock where it did not, and 'estimated' counts the jobs that were only estimated. 'cost' is the same in US dollars — in total and by basis (reported bill, Modal tariff, share of our machines by load), by machine, by week and the ten dearest issues, with the jobs that have no cost counted in 'uncosted' — and 'idle': for each machine priced by the month, what the part of its month in the period cost the computations, what this project's jobs took of it, what the company's other work took, and what nobody took (idle); 'fx' gives the exchange rates used. The period is the last 30 days unless 'from'/'to' (YYYY-MM-DD, UTC) or 'days' say otherwise.

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": {
      "projectKey": "<projectKey>"
    },
    "name": "computation_hours"
  }
}

Input Schema

Name	Required	Description
`to`	No	The last day, YYYY-MM-DD; today when left out.
`days`	No	How many days back from 'to', when 'from' is not given (default 30, max 730).
`from`	No	The first day, YYYY-MM-DD.
`projectKey`	Yes	The project, e.g. 'MATH'.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered; the description then adds substantial semantics the annotations cannot carry. It discloses boundary behavior ("a job that ran across its edge is cut there in proportion, and a job still running counts up to now"), unit conventions (all figures in seconds), the machineSeconds basis distinction (measured vs cores × wall clock), what 'estimated' and 'uncosted' capture, the three cost bases, and the idle decomposition. These are exactly the computation rules an agent needs to interpret results correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, and nearly every sentence carries substantive information. But the cost/idle passage is a single sprawling 90-word sentence with nested parentheticals ("reported bill, Modal tariff, share of our machines by load") that is hard to parse as a run-on block. It would read far better split into labeled lines for machine-hours, cost, idle, and period.

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

Completeness5/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 full burden of explaining the returned structure — and it does, covering the totals, per-machine/per-week/per-issue breakdowns, job outcome counts, cost dimensions, idle decomposition, and fx. Combined with the period-selection rules, an agent has enough to call the tool and interpret what comes back without guessing.

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 the schema already documents projectKey, from, to, and days, and a baseline of 3 applies. The description restates the same facts (YYYY-MM-DD, UTC, default 30 days) plus the timezone qualifier, but adds no per-parameter meaning beyond what the schema carries. Redundant rather than harmful.

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?

The description opens with a specific verb+resource framing: "What a project's computations spent over a period — the machine-hours of its stats screen," and enumerates the returned aggregates (CPU-hours, core-hours, by machine, by week, by issue, job outcomes, cost, idle, fx). That is far beyond restating the name. It does not, however, name or distinguish itself from the nearby siblings list_computations, get_agent_usage, or report_computation, so an agent must infer the split from the word "stats screen."

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?

Usage is only implied: the framing as a stats/aggregate report plus the period defaults tell an agent this is for reporting, not for listing individual computation records. There is no explicit when-to-use / when-not-to-use statement and no routing to alternatives such as list_computations for per-job detail or get_agent_usage for agent usage. The period-selection guidance ("last 30 days unless 'from'/'to' or 'days' say otherwise") is the only real usage instruction.

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

All Kaiku tools Inspect

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

Need Help?