Skip to main content
Glama

tc_calendar

Move a 1C calendar field to the next or previous month or year, or jump to an exact date. Use goto_date for verifiable date changes.

Instructions

Actions on a calendar field. Common operations for objects of this type live elsewhere: tc_field(action="is_visible"), tc_field(action="is_enabled"), tc_field(action="get_context_menu"), tc_app(action="get_parent"). In the signatures below a trailing * marks a REQUIRED parameter — the group schema itself accepts every parameter as optional. ok: true means the client accepted the command, not that anything changed — confirm an effect by reading the state back; target_check: present is not proof of one either. Where the address can be checked the response carries target_check: present, unknown (not checkable here) or off (checking disabled). target_hidden: true appears ONLY when the target exists and was NOT visible; it does NOT prove the absence of an effect — for tc_field(action="activate") invisibility is the normal precondition — it describes the ELEMENT itself and not an invisible container around it, and its absence says nothing. A wrong address is refused with an error only where the address can be checked: a read without a target marker cannot tell one from an empty answer, and tc_table(action="get_cell_text") on a table that does not exist returns text=null exactly as for an empty cell. Actions:

  • calendar_next_month(ref*) Move a calendar field to the next month. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • calendar_next_year(ref*) Move a calendar field to the next year. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • calendar_previous_month(ref*) Move a calendar field to the previous month. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • calendar_previous_year(ref*) Move a calendar field to the previous year. The command is accepted, but nothing readable about the field changes, so this cannot be verified. To move the date use tc_calendar(action="goto_date").

  • goto_date(ref*, year*, month*, day*) Go to a date (year, month, day) in a calendar field. Returns changed/value_before/value_after. connection_id selects the client. Passing ref selects the client automatically; otherwise, with several clients, connection_id is required. Use tc_session(action="list_connections"). Pass reference values returned by the tools unchanged in ref. If a reference expires, find the element again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dayNo
refNo
yearNo
monthNo
actionYes
connection_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: ok:true only means the command was accepted, target_check present/unknown/off semantics, target_hidden meaning (exists but was not visible, no proof of absence, describes the element not a container), error behavior for unverifiable addresses, and ref expiry handling. It even flags that the four navigation actions cannot be verified at all.

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 verification preamble is front-loaded and earns its length, and each action carries a useful caveat plus the goto_date pointer. The same 'nothing readable changes, cannot be verified' sentence is repeated verbatim four times, which is mild waste but arguably justified since each action stands alone.

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 5-action dispatcher with 6 params, no annotations and no output schema, the definition covers purpose, per-action behavior, verification limits, return shape for goto_date (changed/value_before/value_after), and client selection. Nothing needed to invoke it correctly 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 0% across 6 params, so the description must compensate, and it does for the two non-obvious ones: ref (pass returned values unchanged, re-find on expiry) and connection_id (client selection rules). The trailing-* convention for required params is defined. year/month/day are only glossed as 'a date' but are self-evident.

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 opening line names the resource (a calendar field) and the fact that this is a multi-action dispatcher, then explicitly routes the operations that belong to other tools (tc_field is_visible/is_enabled/get_context_menu, tc_app get_parent) elsewhere. An agent can distinguish this tool from every sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states which operations live in other tools and names them, and it explicitly redirects from the unverifiable month/year navigation actions to goto_date when the goal is to move the date. connection_id selection rules (auto when ref is passed, required when several clients and no ref) are spelled out with a pointer to tc_session(action="list_connections").

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