Skip to main content
Glama

Create infrastructure lifecycle event

create_infrastructure_lifecycle_event

Create a lifecycle strategy event. Events attach to a SCOPE (feature_class code, material, optional diameter band) - never to individual features; every feature resolves the most specific matching scope, like replacement rates. Replacement is NOT an event (it is priced by the rates and scheduled by the renewal forecast) - model the interventions BEFORE replacement: crack sealing, relining, resurfacing. List existing events first to reuse a scope. Requires infrastructure_lifecycle_events:write scope.

Input Schema

NameRequiredDescriptionDefault
nameYesEvent name (required, e.g. "Crack Sealing")
materialNoMaterial the scope applies to, exactly as features carry it (e.g. "PVC")
unit_costNoCost per unit (current dollars, never indexed)
fixed_costNoFixed cost (current dollars)
sort_orderNoEvaluation order within the strategy
cost_methodNoCosting: per unit (uses the feature's measured quantity and unit) or a fixed amount (default per_unit)
cost_sourceNoProvenance of the cost ("Engineering 2026", a tender reference)
event_classYesEvent type - preventative maintenance or rehabilitation
feature_classNoFeature class code the strategy scope applies to (omit for a material-wide scope; at least one of feature_class/material is required)
impact_methodYesEffect: add years of life, or reset condition to a value
diameter_min_mmNoLower bound of a diameter band (requires material); bands ladder like rates
impact_reset_toNoCondition after the event (required when impact_method is reset_condition)
work_generationNoWhat a due application of this event becomes when created from the interventions list: none (plan only, default), work_order, or project. Nothing is created on a schedule.
impact_add_yearsNoYears added (required when impact_method is add_years)
max_applicationsNoHow many times the event may fire over a feature's life (default 1)
min_years_betweenNoMinimum years between firings of a recurring event (default 1)
trigger_condition_maxYesUpper bound of the trigger window - the event fires when projected condition falls to this
trigger_condition_minNoLower bound of the trigger window (default 0); a feature already below it has missed the event
work_generation_priorityNoPriority for generated work orders. Ignored unless work_generation is work_order.
work_generation_category_idNoWork category for generated work orders - resolve with list_work_categories. Ignored unless work_generation is work_order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 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 / sort_order / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / work_generation_category_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})$"
  2. Changed4 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 / sort_order / maximum
      Removed value: -9007199254740991
    • removedInput schema / properties / work_generation_category_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})$"
  3. Changed4 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 / sort_order / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / work_generation_category_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})$"
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only provide the generic write profile (readOnly=false, destructive=false, idempotent=false), so the description carries real added weight: it discloses the required infrastructure_lifecycle_events:write scope and the scope-resolution rule that every feature resolves the most specific matching scope. It does not state whether the created event is returned or how duplicates are handled.

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?

Front-loaded with the action, then scope semantics, then the replacement exclusion, then the operational hint and auth scope. Every sentence carries information, though the paragraph is dense and the replacement tangent could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers auth requirements, scope modeling, and domain exclusions for a 20-parameter non-idempotent create. With no output schema, the only real gap is not saying what comes back (e.g. the created event id), which is a minor omission rather than a blocker.

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 100% with rich per-field descriptions, so the baseline is 3, but the description adds meaning on how feature_class, material, and the diameter band combine into a scope and how specificity resolves. That goes beyond restating field docs and helps an agent choose scope parameters correctly.

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 ('Create a lifecycle strategy event') and immediately scopes what the resource is: strategy/scope-level, not per-asset. The 'never to individual features' clause implicitly distinguishes it from sibling create_asset_lifecycle_event, so an agent can pick the right 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?

Gives concrete operational guidance: list existing events first to reuse a scope, and model pre-replacement interventions (crack sealing, relining, resurfacing) rather than replacement. It stops short of naming the sibling that handles replacement/asset-level events, so the alternative is implied rather than explicit.

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