Skip to main content
Glama

Estimate Time

estimate_time
Read-onlyIdempotent

Estimate how long one model call or a whole job takes—on a usual day and a slow day—from your own timed runs, using logged run history when time matters more than cost.

Instructions

Estimate how long one call and a whole job take, as a usual time and a slow day, from the user's own timed runs of that model called that way (kept by log_run). Use when the question is time, not money, and some runs have been logged; it says so when none have. Not for cost (estimate_cost) or for a job you have a promptfoo sample of (forecast_job gives time and cost together).

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": {
      "model": "<model>",
      "input_tokens": "<input_tokens>",
      "output_tokens": "<output_tokens>"
    },
    "name": "estimate_time"
  }
}

Input Schema

NameRequiredDescriptionDefault
wayNoHow the model is calledapi
callsNoHow many calls the job makes
modelYesA model name, as the catalogue or Ollama names it
thinkingNoThinking turned on
concurrencyNoCalls running at once
input_tokensYesPrompt tokens per call
output_tokensYesAnswer tokens per call, including hidden thinking

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.7

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare this is a read-only, idempotent, closed-world operation, so the description does not need to restate safety. It adds useful behavioral context by disclosing that estimates come from the user's own logged timed runs and that the tool reports when none exist. The main remaining gap is output-shape detail, though an output schema exists.

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

Conciseness5/5

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

Three compact sentences with the core purpose and data source up front, followed by usage conditions and exclusions. Every sentence carries useful routing or behavioral information.

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?

For a seven-parameter estimator with an output schema and strong annotations, the description supplies the key missing context: where timing data comes from, the precondition that runs must be logged, and which sibling tools handle adjacent cases. Nothing an agent needs in order to choose and call it correctly is missing.

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 all seven parameters including enums, defaults, and token semantics. The description adds context about the overall estimate but does not contribute parameter-level meaning beyond what is already structured.

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 outcome: estimating duration for one call and a whole job, reported as usual time and a slow day. It names the data source (the user's own timed runs kept by log_run) and explicitly distinguishes itself from estimate_cost and forecast_job.

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?

Explicitly says to use it when the question is time rather than money and when some runs have been logged. It names both alternatives and the conditions that select them: estimate_cost for cost questions and forecast_job when a promptfoo sample exists.

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