Loading ToolBench
User-reviewed browser feedback workflow with feedback collector, SDK, and dashboard
Filika exposes 3 tools with mixed quality. Tool naming follows verb_noun convention (filika_submit_feedback, filika_demo_save_draft, filika_local_test), which is good. However, descriptions vary significantly in clarity and actionability. filika_submit_feedback has a detailed 280-char description explaining purpose, constraints, and success criteria, well above the 10-char minimum and within the 194-char production baseline. filika_demo_save_draft (150 chars) and filika_local_test (120 chars) are adequate but generic. All three tools have input schemas with proper JSON Schema structure (type: object, properties defined, additionalProperties: false). However, parameter descriptions are sparse or missing entirely. filika_submit_feedback has 'title' and 'description' params with brief descriptions ('Brief title', 'Detailed description'), but no constraints on length, format, or content validation rules. The other two tools have empty parameter objects, so no param descriptions exist. No output schemas are documented in the visible code, LLMs cannot infer what these tools return. Error handling is not visible; no recovery guidance or error classification is evident. Security annotations (readOnlyHint, destructiveHint) are present on filika_demo_save_draft and filika_local_test but missing on filika_submit_feedback despite it being a WRITE operation. Overall, the server demonstrates basic tool structure but lacks the depth of parameter documentation, output schema clarity, and error guidance expected of production-grade tools.
Runs the local demo save task. The task deterministically triggers a visible save conflict failure (FILIKA_DEMO_SAVE_CONFLICT) that can be reported via feedback.
Runs a harmless local Filika connectivity check without reading page data or making network requests.
Draft feedback about an observed bug, blocked task, confusing behavior, or concrete improvement idea in this application. Submitting this tool transmits the report to the application's feedback collector. Describe only evidence available from the current task; do not invent failures, repeat an existing report, or include credentials or personal data. Do not use for unrelated requests or hypothetical problems. Only a success receipt confirms acceptance.
No output schemas documented. LLMs cannot infer return types, field names, or structure for any of the three tools. This breaks downstream tool chaining and forces agents to guess what data is available.
Parameter descriptions missing or minimal. filika_submit_feedback params ('title', 'description') lack length constraints, format rules, or validation guidance. filika_demo_save_draft and filika_local_test have empty parameter objects with no descriptions at all.
No error handling or recovery guidance visible. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Security annotations incomplete. filika_submit_feedback (WRITE operation) lacks readOnlyHint/destructiveHint annotations, while the other two tools have them. Inconsistent annotation coverage reduces clarity about side effects.
Tool names use underscores and 'filika_' prefix, which is non-standard. Production tools typically use verb_noun (e.g., 'submit_feedback' not 'filika_submit_feedback'). Prefixing all tools with the app name adds noise and reduces clarity.