TopstepX MCP has 15 well-named tools with consistent verb_noun patterns (get_, search_, place_, modify_, cancel_, close_). All tools have descriptions (avg ~100 chars, within baseline 34-392). Input schemas are present and use Zod validation with type declarations. However, parameter descriptions are sparse, many lack detail on constraints, ranges, or format expectations. Output schemas are not documented; responses are JSON-stringified but structure is opaque to the LLM. Error handling is minimal: risk checks block orders but lack recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Composition is strong: tools chain well (e.g., get_accounts → place_order), and bracket order support is sophisticated. Security: API credentials are not visible in params (good), but no audit logging or permission gates evident.

• Document output schemas for all tools. E.g., topstepx_get_accounts returns {accounts: [{id, name, balance, currency}]}. Include field types and whether fields are always present. This enables LLM to chain tools and extract required IDs.
• Add min/max bounds and enum constraints to parameter descriptions. E.g., 'size: Number of contracts (1-1000, must be positive integer)' and 'unit: Time unit (1=Sec, 2=Min, 3=Hr, 4=Day, 5=Wk, 6=Mo)'.
• Implement tool annotations via MCP SDK. Mark topstepx_close_all and topstepx_place_order with destructiveHint=true; mark read-only tools with readOnlyHint=true. This signals intent to the LLM without parsing descriptions.
• Enhance error messages with recovery guidance. E.g., 'Daily loss limit exceeded (-$750 of -$500 max). Close positions or wait until next trading day.' instead of bare {blocked: true}.
• Clarify mutually exclusive parameters. For topstepx_close_position, state: 'Provide either contractId (e.g., CON.F.US.MGC.M26) OR symbol (e.g., MGC). If both provided, contractId takes precedence.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry