Loading ToolBench
MCP server for managing construction projects (obras) and expenses (gastos) using Supabase backend
This server exposes 6 tools for construction project (obra) and expense (gasto) management via HTTP. Tool definitions are present with basic schemas and descriptions, but fall significantly short of production standards. Naming follows verb_noun convention (criar_, listar_, resumo_) which is acceptable but generic. Descriptions exist but lack the depth needed for LLM-driven tool selection, they are short (10-90 chars) and omit critical context like prerequisites, return structure, and when to use each tool vs alternatives. Parameter schemas are present with type declarations and basic descriptions, but lack constraints (no enums for 'tipo', no format declarations for dates, no min/max bounds). Error handling is minimal, responses are generic HTTP status codes without recovery guidance. The 'pergunta' (question) tool is particularly underdocumented, with vague description ('Natural language query interface') and no specification of what kinds of questions it answers or what output it produces. Output schemas are entirely undocumented, LLMs cannot infer result structure from these tool definitions.
Create an expense (gasto) for a construction project
Create a new construction project (obra)
List all expenses (gastos) for a given construction project
List all construction projects (obras) for a given user
Natural language query interface for asking questions about construction projects and expenses. Parses Portuguese text to extract month/year and project information, then returns relevant expense summaries
Get monthly summary of expenses for a construction project, including total, breakdown by type, and top 5 expenses
No output schemas documented. LLMs cannot infer what fields each tool returns, forcing them to make assumptions about result structure and downstream tool compatibility.
Descriptions are too short and lack LLM-optimized guidance. Most are under 50 characters. No explanation of when to use each tool, what it modifies, or prerequisites.
'tipo' parameter in criar_gasto accepts free-form strings with no enum constraint. LLMs will hallucinate invalid category values.
No pagination support in listar_* tools. If a user has hundreds of projects or expenses, the response will be massive and blow context windows.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
'pergunta' tool is vaguely named and poorly described. It does NLP parsing internally but offers no contract for input (what questions does it handle?) or output (what structure is returned?).
Error responses lack recovery guidance. A 401 returns 'Não autorizado' with no hint about checking API key or retrying. A 400 returns field validation but no alternatives.
Parameter descriptions are generic and lack format guidance. 'Valor' is described only as 'Amount/value' with no min/max bounds, currency assumption, or precision (e.g. cents vs decimals).
No idempotency hints. criar_gasto and criar_obra are write operations but do not document whether they support deduplication or conflict detection if called twice with same parameters.
Date handling is implicit. resumo_mes accepts month/year as integers but does not document behavior on invalid inputs (e.g. month=13), leap-year edge cases, or timezone assumptions.
Implicit chaining risk: criar_obra returns data from Supabase (likely containing obra_id) but output schema is not declared, so LLMs cannot reliably extract the ID to pass to listar_gastos.