Skip to main content
Glama

List machine prices

list_machine_prices
Read-only

The company's price list for the machines its computations run on — what list_computations and computation_hours work costs out from. Per machine, every price it has had, newest first ('current' is the row in force today): 'kind' monthly (a machine of our own, its month shared out by load: a core-hour at monthlyPrice ÷ (cores × hours in the month); 'computeCores' is the part of it given to computations, the rest of the machine doing other work) or tariff (a service billed by the second: coreSecond, memoryGiBSecond, gpuRates by type); the currency (converted to dollars at the ECB rate of each job's day); 'validFrom'; 'source', 'checkedOn' and 'basis' — list, invoice or estimate; 'typeAssumed' where the provider's plan was matched by cores and memory rather than confirmed; 'note' (an estimate's formula). 'builtIn' is Modal's public tariff, used for machine 'modal' while the company has no row of its own. 'unpriced' lists machines jobs reported that no row prices — their jobs have no cost, never a zero. 'mayChange' says whether you may change the list (set_machine_price).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_machine_prices"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly and non-destructive annotations, the description discloses ordering (newest first), what 'current' means, the builtIn fallback, and the important behavior that unpriced machines have no cost rather than zero. It also indicates whether the caller may change the list.

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 purpose is front-loaded and the field explanations are relevant, especially because there is no output schema. However, the dense semicolon-and-parenthetical structure makes it harder to scan than a well-bulleted definition would be.

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?

With no input parameters and no output schema, the description carries the return-shape burden and does so thoroughly: it explains kind, current rows, currency conversion, validity, source/basis, assumptions, notes, builtIn, unpriced, and change eligibility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is no parameter semantics to compensate for; the baseline is 4. The description instead spends its detail on return-field meaning, which is useful but outside this dimension.

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 a specific resource (the company's machine price list) and its role as the basis for computation costs. It clearly distinguishes this read-oriented price list from cost/work tools such as list_computations and computation_hours.

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 explains when this data matters by tying it to list_computations and computation_hours, and it routes changes to set_machine_price via the mayChange field. It does not explicitly say when not to use it, but the intended context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources