Skip to main content
Glama

Set axis values

set_axis_values

Define or extend an extra timeline axis after the consent gate by upserting values with sections, citations, and source references.

Instructions

Define or extend an extra axis (slot 1 or 2) after the consent gate.

values: [{id, name, role?, color?, symbol_svg?, sections?: [{h,t,prov?}], aliases?: [str], cite?: {ch?, p?, note?}, sources?: [source id]}], upserted by id, so this can be called repeatedly as material arrives. aliases are other names the material uses for a value (running text naming one links to its page; "X v. Y" short forms are generated). cite is where it sits in a book; cite_link ({label?, url with {p} and optionally {sec}, sections: {chapter number: section id}}) turns each cite into a link. Unlike the entity axis there is no count cap — this is where a course's cases belong, each carrying the student's own brief in sections.

hide_nav keeps the chips on the cards and the detail pages reachable while dropping the axis from the nav bar, drawer and legend, and labels those chips with the value's name rather than a glyph. Set it for anything with more values than a nav row can hold; skip glyph design for it. Such an axis gets an index page under "Index" in the nav instead, and no Filter section unless filter is true. sources (manifest ids) show on the index page; index_sections [{h,t}] open it; index_blurb names the section headings (in order) whose text excerpts each row; nav_label shortens the nav button; index_label names the nav group (default "Index", shared by both axes).

§0: sections are verbatim from the user's materials. This tool exists because an axis declared inside create_timeline is authored BEFORE record_materials_consent runs — so axis values carrying real content had no gate. This one is consent-locked like add_nodes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slotYes
labelYes
filterNo
valuesYes
sourcesNo
hide_navNo
singularYes
cite_linkNo
nav_labelNo
index_blurbNo
index_labelNo
timeline_idYes
index_sectionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.8.22
    • addedInput schema / properties / cite_link
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Cite Link"
      +}
    • addedInput schema / properties / filter
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Filter"
      +}
    • addedInput schema / properties / index_blurb
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Index Blurb"
      +}
    • addedInput schema / properties / index_label
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Index Label"
      +}
    • addedInput schema / properties / index_sections
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Index Sections"
      +}
    • addedInput schema / properties / nav_label
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Nav Label"
      +}
    • addedInput schema / properties / sources
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Sources"
      +}
  2. First observedv1.4.0

TDQS

A4.6/5.0
Behavior5/5

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

The description heavily compensates for the sparse annotations by disclosing upsert-by-id idempotency, repeatable calls, consent-locking, the lack of a count cap, hide_nav side effects, and verbatim sections. None of this contradicts readOnlyHint=false or destructiveHint=false.

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 long but information-dense and front-loaded with the core purpose. Every block serves a purpose given the absence of schema parameter descriptions, though bullet points or clearer separation of the many optional parameters would improve scannability.

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?

For a 13-parameter mutation tool with no output schema and no param descriptions, the description is largely complete: it covers values semantics, index/nav behavior, consent gating, and idempotent upserting. It does not mention the return value or error/failure modes, but those are secondary to correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the full burden and largely succeeds. It explains the structure of `values`, the behavior of `aliases`, `cite`/`cite_link`, `hide_nav`, `sources`, `index_sections`, `index_blurb`, `nav_label`, and `index_label`. Simple parameters like `timeline_id` and `label` are left to obvious interpretation, which is acceptable.

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 opens with a specific verb-resource pair: 'Define or extend an extra axis (slot 1 or 2) after the consent gate.' It also distinguishes this tool from the entity axis by noting there is no count cap, and references create_timeline's pre-consent authoring, making its purpose and scope immediately clear.

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 gives clear context: use it after the consent gate, for axis values that carry real content, and repeatedly via upsert as material arrives. It contrasts with the entity axis and mentions add_nodes for consent-locking, but it does not explicitly name set_entities or another sibling as the alternative for entity-axis values.

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