Skip to main content
Glama
Cafelatte1

FronyBoard

open_period

Open a specified quarter (YYYYQn) other than the current one so work can be filed under that period; use this when the automatic current-quarter setup is not the target.

Instructions

Use it only to file work under a quarter other than the current one (open next quarter).

Open a quarter's period (YYYYQn, e.g. 2026Q3) other than the current one — create_task
opens the current quarter by itself, so this is only for filing work under another
quarter. No milestone is needed; if the quarter has a planned one, it flips to active.

Input Schema

NameRequiredDescriptionDefault
keyYes
periodYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that no milestone is needed and that a planned milestone flips to active, but it does not cover permissions, idempotency, or what happens if the period is already open.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The constraint is front-loaded and understandable, but the first and second sentences repeat the same 'other than the current quarter' and 'create_task opens current quarter' points. It could be tightened without losing meaning.

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

Completeness3/5

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

The description explains the operation and its quarter-scoping well enough for the period parameter. However, because no output schema or annotations exist and the required key parameter is undocumented, an agent still lacks key invocation context.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must document both parameters. It explains the period format and meaning with an example, but the required key parameter is not described at all, leaving a critical gap.

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 states a specific verb and resource (open a quarter's period) and clearly scopes it to quarters other than the current one. It distinguishes the tool from create_task by explaining that create_task opens the current quarter automatically.

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 gives explicit when-to-use guidance: only for filing work under another quarter, with a concrete format example. It also names the alternative behavior of create_task, making the selection between the two clear.

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