Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Create saved query

fastero_create_query

Save a new SQL query against a connection so it can be scheduled, shared or turned into a report. The SQL is saved, not run; as with fastero_run_sql it must be read-only, and a statement that could change data is refused. Two queries may share a name. Returns the query with its _id, the queryId fastero_create_report and fastero_create_alert take; starting a chart from SQL, fastero_save_chart saves the query and the chart in one call. Where the query computes a business number, fastero_get_definitions holds this organisation's own expression for it, and definitionsUsed records which definitions the query was built from, with their version.

Input Schema

NameRequiredDescriptionDefault
sqlYesThe SQL text, in the connection’s own dialect.
nameYesThe query’s name, as people will see it.
projectIdYesThe project’s id, from fastero_list_projects.
connectionIdYesA data connection’s id, from fastero_list_connections; fastero_create_file_connection makes one of an uploaded CSV or Excel file.
definitionsUsedNoNames of the shared definitions (metrics, datasets) the SQL was built from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / connectionId / description
      Previous value: -"A data connection’s id, from fastero_list_connections."New value: +"A data connection’s id, from fastero_list_connections; fastero_create_file_connection makes one of an uploaded CSV or Excel file."
  2. Changed4 schema fields changed
    • addedInput schema / properties / connectionId / description
      Added value: +"A data connection’s id, from fastero_list_connections."
    • addedInput schema / properties / name / description
      Added value: +"The query’s name, as people will see it."
    • addedInput schema / properties / projectId / description
      Added value: +"The project’s id, from fastero_list_projects."
    • changedInput schema / properties / sql / description
      Previous value: -"The SQL text"New value: +"The SQL text, in the connection’s own dialect."
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only declare the write shape (readOnlyHint=false, destructiveHint=false); the description adds real behavioral context: the SQL is persisted not executed, it must be read-only or the call is rejected, and duplicate names are permitted. It also describes the return value (_id/queryId), which matters since there is no output schema. Slightly short of 5 as it omits error/permission behavior beyond the read-only check.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence and the saved-not-run distinction follows immediately. The paragraph is dense and the closing definitions sentence is somewhat tangential, but every sentence carries usable routing or behavioral information, so little is wasted.

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?

With no output schema, the description compensates by naming the returned _id/queryId and which siblings consume it. Validation rules, duplicate-name tolerance, and related tools are all covered, so an agent has enough to invoke it correctly.

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%, so a 3 baseline would suffice, but the description adds semantic value by explaining that definitionsUsed records which shared definitions and versions the query was built from and tying it to fastero_get_definitions. That goes beyond the schema's terse field descriptions.

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 ("Save a new SQL query against a connection") plus the downstream purposes (scheduling, sharing, reports). Explicitly distinguishes itself from fastero_run_sql ("The SQL is saved, not run"), so an agent can pick it without opening a schema.

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

Usage Guidelines5/5

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

Gives clear when-to-use routing: use fastero_run_sql to execute, fastero_save_chart when you want the query and chart together, and references that fastero_create_report/create_alert consume the returned queryId. Also states a when-not: SQL that could change data is refused.

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

All Fastero toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources