Use this when a user reports a problem that should be tracked as a ticket.

Args:
    short_description: One-line summary of the issue (required, shown in lists).
    description: Longer free-text details, steps to reproduce, impact, etc.
    urgency: "1" (High), "2" (Medium) or "3" (Low). Defaults to "3".

Returns:
    {"number": "INC0010001", "sys_id": "...", "short_description": ..., "state": ..., "urgency": ...}
    The `number` is what humans reference; `sys_id` is the stable record id.

Use this to find existing tickets before creating a new one, to check on a
ticket by number, or to answer "what incidents are open about X?".

Args:
    query_text: What to search for. An incident number ("INC0010001") matches
        exactly; anything else runs ServiceNow's keyword search over the
        incident's text fields, falling back to a substring match on
        short_description/description. Leave empty to list the most recent incidents.
    state: Filter by state. Accepts a numeric code ("1".."8") or a name such as
        "New", "In Progress", "On Hold", "Resolved", "Closed", "Canceled".
        Leave empty for any state.
    limit: Maximum number of incidents to return (1-100). Defaults to 5.

Returns:
    A list of {"number", "sys_id", "short_description", "state", "state_code",
    "urgency", "created_on"}; an empty list means nothing matched.

Use this to record progress on a ticket or move it through its lifecycle.
At least one of `work_notes` or `state` must be provided.

Args:
    number: The incident number, e.g. "INC0010001".
    work_notes: Text to append to the (internal) work notes journal.
    state: New state as a numeric code ("1".."8") or a name such as "In Progress",
        "On Hold", "Resolved", "Closed". Note: resolving/closing on most instances
        also requires resolution fields and will be rejected by ServiceNow if missing.

Returns:
    {"number", "sys_id", "changed": {field: new value, ...}, "state": <current state>}
    describing exactly what was applied.