File sharing service. Upload any file, get a shareable link.
Trove exposes 16 HTTP endpoints with mixed quality. Tool names lack action verbs (e.g., '/{slug}' instead of 'get_artifact', 'DELETE /delete/{slug}' instead of 'delete_artifact'). Descriptions are present but generic (e.g., 'View an uploaded artifact with rendering and comments' lacks WHEN to use it or what it returns). Input schemas are visible for most tools but lack type definitions and constraints, parameters like 'slug' and 'path' have descriptions but no explicit 'type' declarations in JSON Schema format. Output schemas are entirely undocumented. Error handling is absent from descriptions. Security-critical parameters like 'X-Trove-User-Email' are exposed as tool parameters rather than server-side injected. No pagination guidance for list endpoints. Tools 1-4 appear to be metadata/health endpoints, not core functionality.
Deletes a comment body while preserving a root tombstone when replies remain. The attribution email must match the original author.
Delete an uploaded artifact
Returns structured JSON metadata for AI agent integration
Lists whole-artifact threads and threads anchored to the requested site page. Open threads are returned by default.
Returns service health status
Returns embedded guide content for LLM context
List artifacts uploaded by the current user
Tool names do not start with action verbs. RESTful paths like 'GET /{slug}' and 'DELETE /delete/{slug}' are not self-documenting tool names. LLMs cannot infer intent from HTTP method + path alone. Rename to 'get_artifact', 'delete_artifact', 'list_comments', etc.
Input schemas lack explicit JSON Schema type definitions. Parameters are described (e.g., 'slug' is 'Artifact slug') but have no 'type' field (string, number, boolean, object). LLMs cannot validate inputs without type info. Add 'type' to every parameter.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | <=2025-11-25 | v2 |
Returns OpenAPI 3.0 specification for the API
View an uploaded artifact with rendering and comments
Access site assets within a multi-page artifact
Download raw artifact content
Replaces a comment body. The attribution email must match the original author.
Updates the resolution state of a root comment thread.
Creates a root comment attributed from X-Trove-User-Email. Supports whole-file, element, and text anchors.
Adds a reply to an open thread.
Upload a file and get a shareable link. Supports custom slugs and overwriting existing files.
Security-critical parameter 'X-Trove-User-Email' is exposed as a tool parameter in POST /upload, GET /api/artifacts/{slug}/comments, and other endpoints. Email addresses should be server-side injected from authentication context, not passed by the agent. This risks email spoofing and audit trail corruption.
Output schemas are completely undocumented. No tool description states what fields are returned, their types, or structure. LLMs cannot plan downstream tool calls or extract required data (e.g., does POST /upload return a 'slug' or 'url'?). Document all response schemas.
Destructive operations (DELETE /delete/{slug}, DELETE /api/artifacts/{slug}/comments/{comment_id}) lack confirmation or dry-run support. Agents can permanently delete artifacts and comments without a safety gate. Implement a confirmation pattern or require explicit 'confirm=true' parameter.