Bella

Ask Bella

ask_bella

Read-onlyIdempotent

Translates plain-English business questions into read-only SQL, runs them with row and time limits, and returns the rows plus the query used for cases preset tools don't cover.

Instructions

Ask Bella anything about Brightline Outdoor's data that the preset tools don't cover.

Bella turns plain-English questions into SQL using the company's business definitions, runs it safely (read-only, row and time limits) and returns the rows plus the SQL she used. You may also send a SELECT yourself. Returns at most 200 rows: aggregate in SQL when possible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "question": "<question>"
    },
    "name": "ask_bella"
  }
}

Input Schema

Name	Required	Description	Default
`question`	Yes	A business question in plain English, OR one read-only SQL SELECT statement (SQLite dialect, schema in bella://schema).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 3, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered; the description still adds real value by disclosing that queries run through company business definitions, are subject to row and time limits, and are capped at 200 rows. It does not say what happens on an invalid or rejected SQL statement (error shape, whether truncation is flagged), which is the remaining behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the core purpose before the mechanics. Every clause earns its place: the fallback role, the NL-to-SQL mechanism, the safety limits, the return payload, and the row cap with its mitigation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter NL-to-SQL tool with an output schema, the description supplies the decision context (when to prefer it over preset tools), the input flexibility, the safety limits, and the result size constraint. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already covers the plain-English-or-SQL duality, dialect, and schema reference. The description reinforces the dual input mode ("You may also send a SELECT yourself") and adds the practical 200-row ceiling with advice to aggregate in SQL, which is guidance the schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: answering arbitrary data questions by translating plain English into SQL over Brightline Outdoor's data, then returning rows plus the SQL. The clause "that the preset tools don't cover" positions it against the sibling summary/report tools, so an agent can distinguish it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing: use this when the preset tools don't cover the question, and it explicitly permits sending your own read-only SELECT. It does not name the individual siblings (sales_summary, top_customers, etc.) as the preferred path for covered questions, so the exclusion is stated as a category rather than a concrete alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server