Local-first, model-agnostic AI research workbench for macOS, Windows and Linux. A desktop application and headless server with workspace management, OpenCode sidecar integration, and gateway for remote access.
Single tool 'detect_tools' has a reasonable description (127 chars, within 10-1024 range) but lacks a visible input schema in the provided source. The tool name uses a verb ('detect') but is somewhat generic. No parameter descriptions, type definitions, or output schema documentation are visible. The tool appears to be READ_ONLY (good security posture) but lacks the structured definition required for LLM-driven agent composition. Cannot verify schema presence from source code provided.
Report availability of the tools relevant to a research workflow. Detects which scientific/runtime tools are available to the app: first on the user's own PATH, then — for the ones the app ships or provisions itself (the bundled uv sidecar, the managed Jupyter env) — the app's own copy.
No input schema visible in source code. Tool definition lacks parameter types, constraints, and output schema documentation.
Tool name 'detect_tools' is generic and does not clearly convey the action. Verb is present but 'detect' is vague, does it probe, list, check availability, or validate? Rename to 'list_available_tools' or 'check_tool_availability' for clarity.
No parameter descriptions visible. If the tool accepts parameters (e.g., search_path, include_bundled, filter_by_type), they must each have descriptions explaining what they control and valid values.
Output schema not documented. LLMs need to know what fields are returned (e.g., tool_name, version, path, available, category) to plan downstream calls and extract data correctly.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
STDIO-only transport limits remote accessibility. MCP servers should support HTTP or Streamable HTTP for hosted client compatibility.