Loading ToolBench
FastMCP server for fp-wraptr. Exposes FP model tools via the Model Context Protocol (MCP). LLM-platform agnostic and runnable through stdio transport by default.
The server exposes 3 tools with basic descriptions and minimal parameter documentation. Tool naming follows verb_noun convention (get_, validate_, list_) which is good. However, descriptions are generic (10-50 chars), parameter descriptions are sparse or missing entirely, and no output schemas are documented. Input schemas are present but minimal, most parameters lack detail beyond type. Error handling is implicit. This is a typical lightweight utility server that lacks the depth required for agent reasoning and self-correction. It does not guide LLMs on when to call each tool vs. similar alternatives, what to do if validation fails, or what structure to expect in responses.
Return fp-wraptr project identity, version, mascot roster, and capabilities.
List scenario YAML files and metadata from a directory.
Validate a scenario YAML configuration string.
Descriptions are too short (10 - 50 chars) to guide LLM tool selection. Pattern baseline is 194 chars avg; these lack context on WHEN to call the tool vs. alternatives, WHAT dependencies exist, and actionable prereqs.
Output schemas are not documented. LLMs cannot determine what fields get_project_info returns (version? mascot_names? capabilities as a list or dict?), forcing them to guess. Same for validate_scenario (boolean? structured error details?) and list_scenarios (file paths? metadata structure?).
validate_scenario has only one required parameter (yaml_content) with minimal description ('Raw YAML content to validate'). The description does not explain: What constitutes valid YAML? What schema/constraints are checked? What is the expected output on success vs. failure? This leaves LLMs unable to interpret validation errors.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
list_scenarios has a default parameter (examples_dir='examples') but no guidance on what happens if the directory does not exist, has no YAML files, or the agent passes an invalid path. Error handling is opaque.
No error handling responses documented. If validate_scenario receives malformed YAML or validate_scenario fails on a file, how should the LLM respond? What is the error structure? Current implementation offers no guidance.