Skip to main content
Glama

stop_study

End the study timer and complete the current session in the YPT study tracker; defaults to the recorded start time and clears it after success.

Instructions

Stop the study timer and finish the current session.

If ``started_at`` is omitted the timestamp recorded by :func:`start_study`
is used; the recorded value is cleared after a successful stop.

:param started_at: Session start time in epoch milliseconds, as returned
    by ``start_study``. Optional; defaults to the recorded session.
:type started_at: int | None
:param device_model: Device model reported to the YPT API. Defaults to
    ``"ypt-mcp"``.
:type device_model: str
:returns: The full day-log shape described in ``get_day_log``.
:rtype: dict[str, Any]
:raises RuntimeError: If there is no recorded session and ``started_at``
    is not provided, or if YPT credentials are not configured.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
started_atNo
device_modelNoypt-mcp

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/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: it discloses the state mutation (recorded timestamp is cleared after a successful stop), the exact RuntimeError conditions (no recorded session, missing credentials), and the credential prerequisite.

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 behavioral content is front-loaded well, but Sphinx-style :type:/:rtype: markup duplicates the input schema and adds noise an agent gains nothing from.

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?

Error conditions, side effects, and the reference to get_day_log for the return shape cover the essentials; since an output schema exists, not restating the return format is fine. Only the when-to-use framing is thin.

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%, so the description must document both parameters, and it does: started_at is defined as epoch milliseconds returned by start_study with a default-to-recorded-session behavior, and device_model's default is given. The :type: lines merely echo the schema.

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 ('Stop the study timer and finish the current session') and ties itself to the sibling start_study, so an agent can distinguish it from other tools 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 Guidelines3/5

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

Usage is implied through the pairing with start_study and the note that started_at defaults to the recorded session, but there is no explicit when-to-use/when-not guidance or named alternative.

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