Skip to main content
Glama

AssetLab

by ca.assetlab
OverviewDiscussionsAdmin

List asset costs

list_asset_costs
Read-onlyIdempotent

List asset cost records - this is what the AssetLab UI shows on the main "Expenses" page (top-level nav). Each record includes amount, cost_date, category (Acquisition, Repair, PM, Operation, Replacement, Decommission, Other), description, invoice_number, po_number, the vendor paid, and links to asset/site/building/work_order. Distinct from list_expenses, which returns project-scoped expenses without invoice/PO fields. Filter by asset, site, vendor, category, or work order. Amounts are bare numbers with no currency: call get_organization_settings for currency_code before stating one.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default: all pages fetched automatically)
site_idNoFilter by site ID
asset_idNoFilter by asset ID
categoryNoFilter by cost category
per_pageNoItems per page (default: 1000, max: 1000). All pages are fetched automatically.
vendor_idNoFilter by vendor ID
work_order_idNoFilter by work order ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / category / enum
      Previous value: -[
-  "Repair",
-  "PM",
-  "Operation",
-  "Replacement",
-  "Decommission"
-]New value: +[
+  "Acquisition",
+  "Repair",
+  "PM",
+  "Operation",
+  "Replacement",
+  "Decommission",
+  "Other"
+]
    • addedInput schema / properties / vendor_id
      Added value: +{
+  "description": "Filter by vendor ID",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$",
+  "type": "string"
+}
  2. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / asset_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / site_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / work_order_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  3. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"https://json-schema.org/draft/2020-12/schema"New value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / asset_id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • removedInput schema / properties / page / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / site_id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • removedInput schema / properties / work_order_id / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  4. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / asset_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / site_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • addedInput schema / properties / work_order_id / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  5. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations, including record fields, UI context, and the important currency caveat requiring get_organization_settings. It does not cover pagination or rate limits, but the added currency behavior is a meaningful disclosure.

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 description is front-loaded with purpose and record contents, followed by distinction from list_expenses, filters, and currency caveat. It is somewhat long but most sentences carry useful information. Minor trimming is possible around the UI page reference, but it remains efficient overall.

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 appropriately enumerates the returned fields and includes the critical currency interpretation step. Combined with full schema coverage for inputs and read-only annotations, this gives an agent enough information to call and interpret the tool correctly.

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. The description restates the filterable dimensions and category values, but adds little parameter-specific syntax or deeper semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 uses a specific verb and resource: 'List asset cost records.' It further distinguishes the resource by mapping it to the AssetLab Expenses page and explicitly contrasting it with list_expenses. An agent can identify the correct tool without opening schemas.

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?

The description provides clear usage context by naming list_expenses as a distinct sibling and explaining the difference in scope and fields. It also lists supported filters. It does not address every possible sibling such as list_infrastructure_asset_costs, so it falls short of fully explicit when/when-not guidance.

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

All AssetLab toolsInspect
Try in Browser
Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources