list_projectsList your Floot projects (id, name, last-updated, whether an app icon is set), most recently updated first. name_filter is a case-insensitive substring match on the stored name, which is often not the name the user uses for a project — on a small account a filter that matches nothing returns the whole list instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| name_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds valuable behavioral context: the list is ordered by last-updated, name_filter is case-insensitive and matches the stored name (not the user-facing name), and a no-match filter returns the whole list on small accounts. This goes beyond annotations and helps the agent predict edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the core functionality (what it returns and ordering) and then details the filter behavior. Every sentence adds information, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description is fairly complete: it lists the returned fields, ordering, and filter semantics. It doesn't cover pagination or error behavior, but given the minimal parameter set (limit and name_filter) and read-only annotation, what's missing is not critical. It could note that limit defaults, but the schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for both parameters. It thoroughly explains name_filter semantics (case-insensitive substring, stored vs. user name, fallback behavior), which adds real value. However, it does not describe limit at all, though limit's min/max are in the schema. Since name_filter gets rich treatment but limit is left to schema defaults, the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('Floot projects'), and enumerates the returned fields (id, name, last-updated, app icon) and ordering (most recently updated first). This clearly distinguishes it from sibling list tools like list_files and list_resources, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual details (ordering, filter behavior) but does not explicitly state when to use this tool versus alternatives or mention any prerequisites. It's implied that this is for listing projects, but there is no direct guidance on when not to use it or which sibling to prefer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct, but there is some overlap among file-modifying tools (edit_file, write_file, apply_patch) and between run_code_in_vm and run_code_in_browser. Detailed descriptions and clearly scoped use cases help agents select correctly.
Most tools follow a verb_noun snake_case pattern (create_project, list_files, execute_sql), but a few deviate (apply_patch, card_upload_asset, run_code_in_vm). Overall readable and predictable, with only minor inconsistencies.
With 46 tools, the server exceeds the typical well-scoped range and approaches the extreme threshold. While the broad scope of a full development platform justifies many tools, this count may overwhelm agents and increase misselection risk.
The tool surface covers the full development lifecycle: project creation, file operations, database management, resource provisioning, deployment, testing, and debugging. Minor gaps exist (e.g., no delete_project or checkpoint management), but core workflows are well-supported.