Jesse MCP Server

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

No annotations provided, so description carries full burden. It mentions return type ('Dict with update status') and implies constraints ('safe modifications'), but fails to disclose critical mutation behaviors: whether this affects running sessions, what 'safe' specifically means, idempotency, or error handling. For an update operation, this lack of safety/disclosure context is problematic.

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

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

Uses clear docstring structure (Args/Returns) with the main purpose front-loaded in the first sentence. Appropriately brief for a 2-parameter tool. However, 'limited to safe modifications' consumes space without adding actionable detail, slightly weakening the value density.

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

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

Inadequate for a mutation tool with zero annotations and zero schema coverage. The description claims to update 'session parameters' (plural) but the schema reveals only 'notes' is modifiable—mismatch suggests incomplete specification. Missing: side effects on active sessions, validation rules, and relationship to the paper trading lifecycle.

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

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

With 0% schema description coverage, the Args section provides basic compensation by documenting both 'session_id' and 'notes'. However, it adds minimal semantic value beyond naming—no format guidance for session_id, no explanation of notes' purpose or behavior when null. Sufficient to prevent total ambiguity but barely adequate.

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

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

States the basic action (update session parameters) but omits critical domain context. Given the tool name 'trading_paper_update' and siblings like 'trading_paper_start', the description should explicitly mention 'paper trading session' rather than the generic 'session parameters'. The phrase 'limited to safe modifications' hints at constraints but remains vague.

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

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

Provides no explicit guidance on when to use this tool versus siblings like 'trading_paper_start' or 'trading_paper_stop'. The 'safe modifications' caveat is too vague to guide proper usage. No mention of prerequisites (e.g., session must exist) or error conditions.

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