11 tools with mixed quality. Naming is verb-first and clear (get_, create_, list_, start_, cancel_). Descriptions present but generic, most lack context on WHEN to use the tool or what happens next. Schemas visible for all tools with proper types and descriptions for parameters. Critical gaps: no output schemas documented, no error handling guidance, no pagination info for list tools, no idempotency hints for write operations. Tool composition is reasonable (separate ideation vs experiment), but responses lack chaining IDs and result limits are undocumented.

• Add output schemas to all tools. Document the structure of returned objects, especially IDs (projectId, jobId, ideaIndex) needed for chaining. Example: create_research_project should return {projectId: string, createdAt: string, status: string}.
• Expand list tool descriptions to include pagination guidance: 'Returns up to 50 projects per page. Use limit and offset parameters to paginate. Call this first to discover available projects before creating new ones.'
• Add idempotency hints to write operations. Document whether repeated calls with the same input produce the same result or duplicate side effects. For create_research_project, clarify if duplicate titles are allowed.
• Enhance descriptions with WHEN context. E.g., start_ideation: 'Initiates an async ideation job. Call get_job_status to poll progress. Typically takes 2-5 minutes. Returns jobId for tracking.'
• Document error scenarios and recovery paths. E.g., 'If projectId not found, call list_research_projects to verify the project exists. If job fails, check get_job_status for error details and retry with adjusted parameters.'

Inferred effective spec: 2026-07-28+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained