Skip to main content
Glama

Inventory value report

inventory_report
Read-only

Calculate total home inventory value for insurance, with property and room totals, top-value items, and counts of items lacking recorded values. Use it to find what your belongings are worth.

Instructions

What everything is worth, for insurance: totals by property and by room, the most valuable items, and how many have no value recorded. An item counts at its value, else its purchase price, times its quantity; amounts in cents; gone and wanted things are left out. Use it for "what's all our stuff worth?"; to compare against insurance limits use coverage_check.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint=false; the description adds the genuinely non-obvious behaviour: valuation falls back from value to purchase price, is multiplied by quantity, is expressed in cents, and excludes gone and wanted items. Those exclusion and unit rules are exactly what an agent needs to interpret the numbers correctly.

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?

Two sentences, front-loaded with the purpose and followed by the valuation rules and a routing pointer, with no filler. It is dense — the second sentence packs several rules into one clause chain — but almost every clause carries information an agent would otherwise have to guess.

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 parameters and no output schema, the description carries the full burden and meets it: it enumerates the report's sections (by-property totals, by-room totals, top items, unvalued count) and the arithmetic behind them. An agent could answer questions about the returned numbers without further documentation.

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 nothing for the description to disambiguate and the baseline of 4 applies. The description correctly says nothing about inputs rather than inventing them.

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 concrete deliverable set: totals by property and by room, the most valuable items, and a count of items with no recorded value. That is specific enough to distinguish it from data-listing siblings like list_items or search_inventory, and it also names coverage_check as the different neighbour.

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?

Gives an explicit trigger phrase ("what's all our stuff worth?") plus an explicit routing rule: use coverage_check to compare against insurance limits. Both the when-to-use and the when-to-use-something-else cases are covered.

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