Skip to main content
Glama

update_thesis

Revise an investment thesis's status, confidence, claims, triggers, and alert settings in one atomic step while preserving every change in its history.

Instructions

Revise a thesis: status, confidence, the claims it rests on, and its triggers, in one atomic step. Everything is kept in its history.

    Also tunes its alerts: a threshold of its own, and mutes (e.g. no alerts
    for a supplier's routine 10-Qs).

Input Schema

NameRequiredDescriptionDefault
reasonYesWhy; kept in the thesis history
statusNo
horizonNoNew horizon, e.g. 12m or FY2027 (counted from now)
add_mutesNoStop alerts from matching events
thesis_idYes
add_claimsNoClaims to link (e.g. newer, better-sourced assumptions)
confidenceNo
add_triggersNoNew conditions that would invalidate it
alert_thresholdNoMinimum alert score for this thesis
remove_mute_idsNo
remove_claim_idsNoClaims the thesis no longer rests on
remove_trigger_idsNo
reset_alert_thresholdNoGo back to the global alert threshold

Output Schema

NameRequiredDescriptionDefault
idYes
titleYes
claimsYes
stanceYes
statusYes
horizonYes
entry_atNo
triggersYes
benchmarkNo
statementYes
confidenceYes
created_atYes
instrumentNo
session_idYes
updated_atYes
entry_priceNo
horizon_dateNo
alert_thresholdNo
subject_entity_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses two genuinely useful traits: the change is applied "in one atomic step" and "Everything is kept in its history," which reassures the agent about reversibility. It does not address permissions or partial-failure behavior, keeping it short of a 5.

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?

Two short paragraphs, front-loaded with the core revision semantics before the secondary alert-tuning behavior. Every clause carries information; only mild redundancy between "triggers" and "tunes its alerts."

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 atomic mutation with an output schema and safety annotations already present, this covers the main behavioral story (atomicity, history retention, alert tuning). The gap is the destructive/removal parameters and the rationale field, which are left entirely to the schema.

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

Parameters3/5

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

Schema coverage is 62%, and the description adds conceptual meaning for the alert-tuning side (per-thesis threshold, mutes with a concrete supplier-10-Q example). However, the add_/remove_ asymmetry (remove_claim_ids, remove_mute_ids, remove_trigger_ids, reset_alert_threshold) and the required reason/horizon fields are left to the schema, so it does not fully compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Revise a thesis") and enumerates the mutable dimensions: status, confidence, claims, triggers, plus alert threshold and mutes. The scope is unambiguous, though it never names a sibling (e.g. record_thesis for creation, track_thesis) to sharpen the boundary.

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?

The reader can infer this is the mutation path versus record_thesis' creation path, but the description never says so explicitly. There is an illustrative mutes example, yet no when-to-use/when-not and no routing to alternatives.

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