Skip to main content
Glama

Dayze — Life Context

Add Inventory Item

add_inventory_item

Add an owned item to the user's private Inventory. For a computer, phone, camera or synth pass spec_template (computer.v1, phone.v1, camera.v1, synth.v1) and specs with that template's fields, taken from what the user says or the device reports; never infer specs from a model name. Changing facts (OS version, free space, battery, service readiness) go in state, one observation with observed_at. Never ask for or store device or account identifiers. Returns inventory_id and the item with capability_summary. Example: { name: "MacBook Pro 14 (2023)", spec_template: "computer.v1", specs: { manufacturer: "Apple", model_name: "MacBook Pro", model_identifier: "Mac15,11", chip: "Apple M3 Max", performance_cores: 10, efficiency_cores: 4, total_cores: 14, memory_bytes: 38654705664, memory: "36 GB", architecture: "arm64" }, state: { os: { name: "macOS", version: "15.4.1", build: "24E263" }, observed_at: "2026-09-29T14:00:00Z", source: "user_reported" } } ($0.10; API key required)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesWhat the user calls the item, e.g. "MacBook Pro 14 (2023)".
tagsNoReplaces the tag list.
brandNo
modelNo
notesNoFree text from the user.
specsNoStable facts, by the template's field names (computer.v1: nickname, manufacturer, model_name, model_identifier, year, primary_uses, capability_tags, product_family, form_factor, chip, cpu, architecture, performance_cores, efficiency_cores, total_cores, threads, gpu, gpu_cores, gpu_memory_bytes, neural_engine_cores, memory_bytes, memory, storage_devices, display, ports). Merged per key on update; null removes a key; other keys are kept as written. Only what the user or the device says, never inferred from a model name. Never device or account identifiers.
stateNoChanging facts, as one observation: observed_at (ISO, default now), source (e.g. user_reported, system_profiler), confidence (0-1), and values such as os { name, version, build }, available_storage_bytes, battery, security { sip, gatekeeper, filevault }, services { bluebubbles: { installed_version, running, configured, blockers, checked_at } }. Merged per key; a key observed more recently is kept. Never changes specs or notes. Never device or account identifiers.
statusNoDefault owned. To archive, use archive_inventory_item.
subtypeNoSpecific kind: laptop, sweatshirt, guitar. Alias: item_type.
categoryNoelectronics | instruments | clothing | shoes | bags | accessories | jewelry | watches | collectibles | sports | health | home | tools | vehicles | furniture | other. Computers, phones and cameras are electronics; synths are instruments. Defaults to the spec_template's category, else other.
currencyNoISO 4217, e.g. USD, SGD. Default USD.
locationNoWhere it is kept.
conditionNo
item_typeNoAlias for subtype (the stored column).
person_idsNoContacts to link: purchased_from, or inherited_from when acquisition_type is inheritance.
request_idNoClient idempotency key (retries return original result).
acquired_dateNoYYYY-MM-DD it came into the user's life (gift, inheritance). add_inventory_item also stores it as purchase_date when none is given.
acquired_fromNoShop or person it came from.
current_valueNoAlias for estimated_value (the stored column).
purchase_dateNoYYYY-MM-DD
spec_templateNoWhich typed fields specs uses. Templates are listed in docs/MCP_LIFE_GRAPH.md. null (update) clears it.
purchase_priceNo
estimated_valueNoWhat it is worth now. Alias: current_value.
idempotency_keyNoAlias for request_id.
acquisition_typeNopurchase | gift | inheritance | …
reference_numberNoManufacturer reference or model number (e.g. a watch reference).
subtype_confidenceNo0-1, when the subtype is a guess.
specs_schema_versionNoLayout of specs and state. Only 1 (the default).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemNoInventory item record. With specs: spec_template, specs, state (a timestamped snapshot), state_freshness and capability_summary.
accountNoThe Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
messageNo
provenanceNoWhich connector wrote the record and which connected Dayze account received it.
inventory_idNo
idempotent_replayNotrue when this request_id already ran: the first result, nothing new written.
people_not_linkedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / status / description
      Previous value: -"wishlist | ordered | owned | listed_for_sale | sold | returned | lost | disposed | donated. Default owned. To archive, use archive_inventory_item."New value: +"Default owned. To archive, use archive_inventory_item."
    • addedInput schema / properties / status / enum
      Added value: +[
      +  "wishlist",
      +  "ordered",
      +  "owned",
      +  "listed_for_sale",
      +  "sold",
      +  "returned",
      +  "lost",
      +  "disposed",
      +  "donated"
      +]
  2. Changed2 schema fields changed
    • addedOutput schema / properties / account
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.",
      +  "properties": {
      +    "display_name": {
      +      "description": "Account display name.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "handle": {
      +      "description": "Account handle, e.g. @goh.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "note": {
      +      "description": "How to disclose the account to the user.",
      +      "type": "string"
      +    },
      +    "qa_fixture": {
      +      "description": "True for a known QA test account: its records are fixture data, not a real life.",
      +      "type": "boolean"
      +    }
      +  },
      +  "required": [
      +    "handle",
      +    "display_name",
      +    "qa_fixture",
      +    "note"
      +  ],
      +  "type": "object"
      +}
    • addedOutput schema / properties / provenance
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Which connector wrote the record and which connected Dayze account received it.",
      +  "properties": {
      +    "account": {
      +      "additionalProperties": false,
      +      "description": "The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.",
      +      "properties": {
      +        "display_name": {
      +          "description": "Account display name.",
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "handle": {
      +          "description": "Account handle, e.g. @goh.",
      +          "type": [
      +            "string",
      +            "null"
      +          ]
      +        },
      +        "note": {
      +          "description": "How to disclose the account to the user.",
      +          "type": "string"
      +        },
      +        "qa_fixture": {
      +          "description": "True for a known QA test account: its records are fixture data, not a real life.",
      +          "type": "boolean"
      +        }
      +      },
      +      "required": [
      +        "handle",
      +        "display_name",
      +        "qa_fixture",
      +        "note"
      +      ],
      +      "type": "object"
      +    },
      +    "channel": {
      +      "description": "Always mcp_connector.",
      +      "type": "string"
      +    },
      +    "connector": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "kind": {
      +          "description": "oauth or api_key.",
      +          "type": "string"
      +        },
      +        "name": {
      +          "description": "The connected app or API-key label shown to the account owner.",
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "kind",
      +        "name"
      +      ],
      +      "type": "object"
      +    },
      +    "source": {
      +      "description": "chatgpt for ChatGPT OAuth writes; mcp for another OAuth app or API key.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "source",
      +    "channel",
      +    "connector",
      +    "account"
      +  ],
      +  "type": "object"
      +}
  3. Changed30 schema fields changed
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / properties / acquired_date
      Added value: +{
      +  "description": "YYYY-MM-DD it came into the user's life (gift, inheritance). add_inventory_item also stores it as purchase_date when none is given.",
      +  "type": "string"
      +}
    • addedInput schema / properties / acquired_from
      Added value: +{
      +  "description": "Shop or person it came from.",
      +  "type": "string"
      +}
    • addedInput schema / properties / acquisition_type
      Added value: +{
      +  "description": "purchase | gift | inheritance | …",
      +  "type": "string"
      +}
    • addedInput schema / properties / brand
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / category
      Added value: +{
      +  "description": "electronics | instruments | clothing | shoes | bags | accessories | jewelry | watches | collectibles | sports | health | home | tools | vehicles | furniture | other. Computers, phones and cameras are electronics; synths are instruments. Defaults to the spec_template's category, else other.",
      +  "type": "string"
      +}
    • addedInput schema / properties / condition
      Added value: +{
      +  "enum": [
      +    "new",
      +    "excellent",
      +    "good",
      +    "worn",
      +    "needs_repair",
      +    "retired"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / currency
      Added value: +{
      +  "description": "ISO 4217, e.g. USD, SGD. Default USD.",
      +  "type": "string"
      +}
    • addedInput schema / properties / current_value
      Added value: +{
      +  "description": "Alias for estimated_value (the stored column).",
      +  "type": "number"
      +}
    • addedInput schema / properties / estimated_value
      Added value: +{
      +  "description": "What it is worth now. Alias: current_value.",
      +  "type": "number"
      +}
    • addedInput schema / properties / item_type
      Added value: +{
      +  "description": "Alias for subtype (the stored column).",
      +  "type": "string"
      +}
    • addedInput schema / properties / location
      Added value: +{
      +  "description": "Where it is kept.",
      +  "type": "string"
      +}
    • addedInput schema / properties / model
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / name / description
      Added value: +"What the user calls the item, e.g. \"MacBook Pro 14 (2023)\"."
    • addedInput schema / properties / notes
      Added value: +{
      +  "description": "Free text from the user.",
      +  "type": "string"
      +}
    • addedInput schema / properties / person_ids
      Added value: +{
      +  "description": "Contacts to link: purchased_from, or inherited_from when acquisition_type is inheritance.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / purchase_date
      Added value: +{
      +  "description": "YYYY-MM-DD",
      +  "type": "string"
      +}
    • addedInput schema / properties / purchase_price
      Added value: +{
      +  "type": "number"
      +}
    • addedInput schema / properties / reference_number
      Added value: +{
      +  "description": "Manufacturer reference or model number (e.g. a watch reference).",
      +  "type": "string"
      +}
    • addedInput schema / properties / spec_template
      Added value: +{
      +  "description": "Which typed fields specs uses. Templates are listed in docs/MCP_LIFE_GRAPH.md. null (update) clears it.",
      +  "enum": [
      +    "computer.v1",
      +    "phone.v1",
      +    "camera.v1",
      +    "synth.v1"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / specs
      Added value: +{
      +  "description": "Stable facts, by the template's field names (computer.v1: nickname, manufacturer, model_name, model_identifier, year, primary_uses, capability_tags, product_family, form_factor, chip, cpu, architecture, performance_cores, efficiency_cores, total_cores, threads, gpu, gpu_cores, gpu_memory_bytes, neural_engine_cores, memory_bytes, memory, storage_devices, display, ports). Merged per key on update; null removes a key; other keys are kept as written. Only what the user or the device says, never inferred from a model name. Never device or account identifiers.",
      +  "type": "object"
      +}
    • addedInput schema / properties / specs_schema_version
      Added value: +{
      +  "description": "Layout of specs and state. Only 1 (the default).",
      +  "type": "integer"
      +}
    • addedInput schema / properties / state
      Added value: +{
      +  "description": "Changing facts, as one observation: observed_at (ISO, default now), source (e.g. user_reported, system_profiler), confidence (0-1), and values such as os { name, version, build }, available_storage_bytes, battery, security { sip, gatekeeper, filevault }, services { bluebubbles: { installed_version, running, configured, blockers, checked_at } }. Merged per key; a key observed more recently is kept. Never changes specs or notes. Never device or account identifiers.",
      +  "type": "object"
      +}
    • addedInput schema / properties / status
      Added value: +{
      +  "description": "wishlist | ordered | owned | listed_for_sale | sold | returned | lost | disposed | donated. Default owned. To archive, use archive_inventory_item.",
      +  "type": "string"
      +}
    • addedInput schema / properties / subtype
      Added value: +{
      +  "description": "Specific kind: laptop, sweatshirt, guitar. Alias: item_type.",
      +  "type": "string"
      +}
    • addedInput schema / properties / subtype_confidence
      Added value: +{
      +  "description": "0-1, when the subtype is a guess.",
      +  "type": "number"
      +}
    • addedInput schema / properties / tags
      Added value: +{
      +  "description": "Replaces the tag list.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedOutput schema / properties / idempotent_replay
      Added value: +{
      +  "description": "true when this request_id already ran: the first result, nothing new written.",
      +  "type": "boolean"
      +}
    • changedOutput schema / properties / item / description
      Previous value: -"Inventory item record."New value: +"Inventory item record. With specs: spec_template, specs, state (a timestamped snapshot), state_freshness and capability_summary."
    • addedOutput schema / properties / people_not_linked
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. Changed2 schema fields changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "Alias for request_id.",
      +  "type": "string"
      +}
    • addedInput schema / properties / request_id
      Added value: +{
      +  "description": "Client idempotency key (retries return original result).",
      +  "type": "string"
      +}
  5. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnly=false, destructive=false, openWorld=false. The description adds real behavioral context the annotations lack: cost ($0.10), API key requirement, a privacy constraint ('never ask for or store device or account identifiers'), and the return shape (inventory_id, item with capability_summary). It does not cover failure modes or rate limits, so not a 5.

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?

Purpose and the key constraining rules are front-loaded in the opening sentences, and every clause is load-bearing for a 28-parameter tool. The embedded JSON example is long and slightly unwieldy, but it demonstrates the specs/state split in a way prose cannot.

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 high-complexity 28-param nested tool, the description plus a rich schema and output schema cover what an agent needs: when a template is required, what goes in specs vs state, the privacy prohibition, and the return values. Nothing essential is missing.

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?

Schema coverage is 86%, so the baseline is 3; the description nonetheless makes the hardest distinction explicit — stable facts belong in specs, changing facts go in state as one observation with observed_at — and the worked example shows exactly which fields that implies. This adds meaning beyond the field-level descriptions.

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 resource ('Add an owned item to the user's private Inventory') and immediately differentiates the typed spec path from free-form adds. An agent can distinguish this from update_inventory_item, get_inventory_item, and archive_inventory_item without opening any schema.

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?

Gives concrete routing rules: pass spec_template plus matching specs for computer/phone/camera/synth, put changing facts in state as one observation with observed_at, and never infer specs from a model name. It stops short of explicitly contrasting add vs update_inventory_item, which the schema partly handles ('null (update) clears it').

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.