mcp-server
Server Details
Query BigQuery, Snowflake, Redshift & Azure Synapse with natural language
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 21 of 21 tools scored. Lowest: 3.9/5.
Each tool targets a specific action and resource; CRUD tools for use cases and aggregation views are clearly separated, and schema discovery tools are distinct (catalog vs. detailed schema). No overlapping purposes.
All tools follow a consistent verb_noun pattern with snake_case (e.g., create_aggregation_view, list_projects, execute_query), with no mixing of conventions.
21 tools is slightly above the typical optimal range (3-15) but still reasonable for the breadth of functionality (project management, data discovery, use cases, MMM, etc.). No extremes.
CRUD coverage for use cases and aggregation views is present, schema discovery is two-step, and MMM workflow is covered. Minor gaps like no direct update for aggregation views or scheduled queries, but overall comprehensive.
Available Tools
21 toolscollect_feedbackAInspect
Collects user feedback on the provided response.
When to use this tool:
After providing an analysis, a SQL query, or an important response
When you want to know if the response was helpful
Naturally suggest: "Was this response helpful? 👍 👎"
Ratings:
'positive': The response was helpful and accurate
'negative': The response was not satisfactory
'neutral': Neither satisfied nor dissatisfied
Categories (optional):
'accuracy': Was the response accurate?
'relevance': Did the response address the question?
'completeness': Was the response complete?
'speed': Was the response time acceptable?
'other': Other feedback
Feedback usage: Feedback is used to improve future responses (RAG, analytics).
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | Rating: 'positive', 'negative', or 'neutral' | |
| comment | No | Free-form user comment (optional) | |
| category | No | Feedback category: 'accuracy', 'relevance', 'completeness', 'speed', 'other' (optional) | |
| tool_name | No | The name of the tool whose response is being rated (optional) | |
| original_question | No | The user's original question for which feedback is given (to improve RAG) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that feedback is used to improve future responses via RAG and analytics. Annotations already indicate it's not read-only and not destructive, so the description adds value by disclosing the impact of the feedback.
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 well-structured with sections, front-loads the purpose, and is concise without unnecessary repetition.
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?
The description covers what the tool does, when to use, all parameters, and how feedback is used. Though there is no output schema, the description is adequate for a feedback collection tool.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the rating values, categories, and the purpose of tool_name and original_question parameters.
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 clearly states it collects user feedback on the provided response, specifying the verb 'collects' and the resource 'feedback'. It distinguishes itself from sibling tools, none of which are feedback-related.
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 explicitly states when to use the tool (after providing analysis, SQL query, or important response) and provides a natural suggestion. It does not explicitly mention when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_aggregation_viewAInspect
Creates a materialized view or stored procedure in the project's BigQuery data warehouse for data pre-aggregation.
When to use this tool:
When the user needs to pre-aggregate data from multiple connectors (e.g., cross-channel marketing report)
When a query is too slow to run on-demand and benefits from materialization
When the user asks to "create a view", "save this as a table", "materialize this query"
Naming rules (enforced):
Target dataset MUST be 'quanti_agg' (created automatically if it doesn't exist)
Object name MUST start with 'llm_' prefix (e.g., llm_weekly_spend)
Format: CREATE MATERIALIZED VIEW quanti_agg.llm_name AS SELECT ...
SQL format:
CREATE MATERIALIZED VIEW: for pre-computed aggregation tables
CREATE OR REPLACE MATERIALIZED VIEW: to update an existing view
CREATE PROCEDURE: for complex multi-step transformations
Example: CREATE MATERIALIZED VIEW quanti_agg.llm_weekly_channel_spend AS SELECT DATE_TRUNC(date, WEEK) as week, channel, SUM(spend) as total_spend FROM prod_google_ads_v2.campaign_stats GROUP BY 1, 2
Limits: Maximum 20 active aggregation views per project.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | The CREATE MATERIALIZED VIEW or CREATE PROCEDURE SQL statement. Must follow naming rules (llm_ prefix, _agg dataset suffix). | |
| project_id | Yes | The project folderId (e.g., p57d4af1b) | |
| description | No | Business description of the aggregation (what it computes, when to use it). Optional but recommended. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds context about naming rules, SQL format, and limits, which goes beyond annotations. No contradiction.
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?
Well-structured with clear sections: purpose, when to use, naming rules, SQL format, example, limits. Concise yet informative. Slightly verbose but maintains clarity.
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?
Covers essentials: purpose, usage, naming, syntax, limits, example. Missing error handling or permissions, but sufficient for an AI agent with no output schema. The complexity is moderate, and the description is largely complete.
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?
Schema coverage is 100% with each parameter described. The description reinforces and adds extra guidance (e.g., naming rules for sql parameter, example SQL). Baseline is 3 due to high coverage, but the added examples and rules justify a 4.
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 clearly states it creates materialized views or stored procedures for data pre-aggregation. It distinguishes from sibling tools like delete_aggregation_view and list_aggregation_views by focusing on creation.
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?
Explicitly lists when to use (pre-aggregation, slow queries, user requests) and mentions limits (max 20 views). Lacks explicit when-not-to-use or alternatives like execute_query for ad-hoc queries, but still provides strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_use_caseAInspect
Creates and saves a new use case (reusable analysis).
When to use this tool:
When the user asks to "save this analysis", "create a use case", "remember this query"
After building a SQL query the user wants to reuse
To capitalize on a recurring business analysis
Available scopes:
'member' (default): Personal use case, visible only to you
'project': Shared with the entire project team (requires project_id)
Best practices:
Slug: technical identifier in snake_case (e.g., weekly_campaign_performance)
Name: human-readable name (e.g., "Weekly Campaign Performance")
Description: explain the business context and when to use this analysis
SQL template: include the SQL query if it's generic and reusable
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name, human-readable (e.g., 'Weekly Campaign Performance') | |
| slug | Yes | Unique identifier in snake_case (e.g., 'weekly_campaign_perf'). No spaces or special characters. | |
| scope | No | Visibility: 'member' (personal, default) or 'project' (shared with the team) | |
| prompt | No | Structured prompt for use cases that don't rely on SQL (e.g., analysis instructions, business steps, reporting guidelines). | |
| category | No | Category to organize use cases (e.g., 'performance', 'attribution', 'budget', 'audience') | |
| project_id | No | The project folderId. Required only if scope='project'. | |
| description | No | Business description: what problem does this use case solve? When to use it? What metrics are analyzed? | |
| sql_template | No | BigQuery SQL template for the analysis. Use placeholders if needed (e.g., {{start_date}}, {{campaign_id}}). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description adds context on scopes and best practices, consistent with annotations. No contradictions.
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?
Well-structured with sections for purpose, when to use, available scopes, and best practices. Concise and front-loaded with the main action. No unnecessary sentences.
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 creation tool with 8 parameters and no output schema, the description provides adequate context including purpose, usage triggers, scopes, and parameter guidance. Return values are not explained, but that's acceptable.
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?
Schema coverage is 100% with descriptions. The description adds best practices for each parameter (e.g., slug in snake_case, name human-readable), enhancing understanding beyond the schema.
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 clearly states the tool creates and saves a new use case, using specific verb and resource. It distinguishes from sibling tools like update_use_case and delete_use_case.
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?
Provides explicit when-to-use scenarios (e.g., 'save this analysis', 'create a use case') and context for recurring analysis. Does not explicitly state when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_aggregation_viewADestructiveInspect
Deletes an aggregation view (materialized view or procedure) from the project.
When to use this tool:
When the user explicitly asks to delete/drop a view
To clean up unused or obsolete aggregations
When the project has reached the maximum number of views (20)
Warning: This marks the view as dropped in Quanti's tracking. The actual BigQuery object may need manual cleanup.
Tip: Use list_aggregation_views first to get the view ID.
| Name | Required | Description | Default |
|---|---|---|---|
| view_id | Yes | The UUID of the aggregation view to delete. Get it from list_aggregation_views. | |
| project_id | Yes | The project folderId |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false. Description adds context beyond annotations by warning that the tool only marks the view as dropped in Quanti's tracking, and the actual BigQuery object may need manual cleanup. No contradiction with annotations.
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?
Description is well-structured with a clear overview sentence, bullet points for usage guidelines, and a warning section. Every sentence adds value, no redundancy, appropriately sized.
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 delete tool with two simple parameters, strong annotations, and clear usage guidelines, the description is complete. It covers what it does, when to use it, behavioral consequences, and prerequisite steps. No missing information.
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?
Schema coverage is 100% (both parameters well-described). Description adds guidance to get view_id from list_aggregation_views, but that is more usage instruction than parameter meaning. Baseline 3 is appropriate as the schema already provides sufficient information.
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?
Description clearly states 'Deletes an aggregation view (materialized view or procedure) from the project.' This is a specific verb+resource combination that distinguishes it from sibling tools like create_aggregation_view and list_aggregation_views.
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?
Explicit 'When to use this tool:' section with three clear bullet points, including when the user explicitly asks to delete, to clean up unused views, or when max views reached. Also includes a tip to use list_aggregation_views first for prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_use_caseADestructiveInspect
Permanently deletes a use case you created.
When to use this tool:
When the user explicitly asks to delete a use case
To clean up obsolete or duplicate use cases
Warning: This action is irreversible. The use case will be permanently deleted.
Permissions: You can only delete use cases you created.
Tip: Ask for user confirmation before deleting.
| Name | Required | Description | Default |
|---|---|---|---|
| use_case_id | Yes | The UUID ID of the use case to delete. Get it from list_my_use_cases or list_project_use_cases. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds 'This action is irreversible. The use case will be permanently deleted,' and 'You can only delete use cases you created,' providing critical behavioral context beyond the annotation.
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 concise, with the main action front-loaded, followed by structured bullet points for usage, warning, permissions, and tip. Every sentence adds value.
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 one-parameter destructive tool with annotations, the description covers purpose, usage scenarios, behavioral impact, permissions, and confirmation guidance completely.
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?
Schema description coverage is 100% and the schema already explains the parameter well ('The UUID ID... Get it from list_my_use_cases or list_project_use_cases'). The description adds no further parameter detail, so baseline 3 is appropriate.
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 clearly states 'Permanently deletes a use case you created,' specifying the verb (delete) and resource (use case). It distinguishes from sibling tools like create_use_case and update_use_case.
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 explicitly provides when to use ('when user explicitly asks to delete', 'to clean up obsolete or duplicate use cases'), permissions ('only delete use cases you created'), and a tip to ask for confirmation, giving clear guidance over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_queryARead-onlyIdempotentInspect
Executes a read-only SQL SELECT query on the project's BigQuery data warehouse. No data modification allowed.
Table format: Use dataset.table (e.g., prod_google_ads_v2.campaign_stats). Do NOT prefix with a project_id.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | The SQL SELECT query to execute (BigQuery standard SQL). Tables in dataset.table format only. | |
| project_id | Yes | The project folderId (Quanti identifier, not the BigQuery project) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint; description adds specific behavior (BigQuery, SELECT only, table format) without contradiction. Provides additional context beyond annotations.
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?
Two concise sentences front-loading the main purpose. Every sentence serves a purpose with no wasted words.
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?
Given rich annotations and 2 parameters with full schema coverage, the description covers essential usage. Could mention return format or limits, but overall sufficient for the tool's simplicity.
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?
Schema coverage is 100%, and parameter descriptions are already clear. Description reiterates table format rule but does not add significant new semantics beyond the schema.
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?
Description clearly states 'Executes a read-only SQL SELECT query on the project's BigQuery data warehouse', specifying verb, resource, and scope. Differentiates from sibling tools by emphasizing read-only and BigQuery context.
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?
Provides explicit usage instructions like table format, but does not contrast with sibling tools or state when not to use. The description is clear enough for the agent to understand appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_helpARead-onlyIdempotentInspect
Searches the official Quanti documentation (docs.quanti.io) to answer questions about using the platform.
When to use this tool:
When the user asks "how to do X in Quanti?", "what is a connector?", "how to configure BigQuery?"
When the user needs help configuring or using a connector (Google Ads, Meta, Piano, etc.)
To explain Quanti concepts: projects, connectors, prebuilds, data warehouse, tag tracker, transformations
When the user asks about the Quanti MCP (setup, overview, semantic layer)
This tool does NOT replace:
get_schema_context: to get the actual BigQuery schema for a client project
list_prebuilds: to list pre-configured reports for a connector
get_use_cases: to find reusable analyses
execute_query: to execute SQL
Available topic filters: connectors, data-warehouses, data-management, tag-tracker, mcp-server, transformations
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The user's question about Quanti (e.g., 'how to configure Google Ads?', 'what is the lookback window?') | |
| topic | No | Filter by documentation section: 'connectors', 'data-warehouses', 'data-management', 'tag-tracker', 'mcp-server', 'transformations'. Optional. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds behavior: searches docs.quanti.io, offers topic filters, and clarifies scope. Minor additional value beyond annotations.
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?
Well-structured with bullet points under 'When to use' and 'This tool does NOT replace'. No fluff; every sentence adds value.
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?
Comprehensive for its complexity: covers purpose, usage, parameters, and exclusions. However, missing description of return format or output behavior, which would improve completeness.
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?
Schema covers 100% parameters. Description adds examples for query parameter and lists available values for topic parameter, enhancing clarity but not essential beyond schema.
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?
Clearly states it searches official Quanti documentation to answer platform usage questions. Differentiates from siblings by listing tools it does not replace, ensuring distinct purpose.
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?
Explicitly specifies when to use (e.g., 'how to do X in Quanti?', explaining concepts) and when not to, listing alternative tools like get_schema_context, list_prebuilds, etc. Also provides topic filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_launch_contextARead-onlyIdempotentInspect
Retrieves the full context of a Quanti launch session. The user has pre-configured an analysis from the Quanti interface and was redirected here with a launch_id. Call this function to get the analysis details to execute (name, prompt or SQL template, project).
| Name | Required | Description | Default |
|---|---|---|---|
| launch_id | Yes | The launch session identifier (UUID provided in the initial prompt) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns analysis details (name, prompt or SQL template, project), but no additional behavioral traits beyond what annotations cover. No contradiction.
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 sentences, front-loaded with the main purpose, and every sentence adds value. No unnecessary words.
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 one-parameter retrieval tool with no output schema, the description adequately explains what is returned (name, prompt or SQL template, project). The low complexity and single parameter make this complete.
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?
Schema coverage is 100% with a description for launch_id. The description reinforces that the UUID is provided in the initial prompt, adding minor context. Baseline score of 3 is appropriate as it does not significantly extend beyond the schema.
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 clearly states the tool retrieves the full context of a Quanti launch session. It specifies the resource (launch session) and the verb (retrieves), and distinguishes it from sibling tools like get_project_context by focusing on the launch scenario.
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 a clear usage scenario: when a user is redirected with a launch_id after pre-configuring an analysis. It implies when to use this tool but does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_contextARead-onlyIdempotentInspect
Gets the full context of a project: active connectors with their datasets, visual branding, and business context (about both the client organization and the user querying the MCP).
Use the folderId obtained from list_projects. Always call this tool before answering analytical questions or generating a report.
Response structure:
connectors: active data sources with sku, dataset, last_sync, tables_count. May also carrydescription/purpose(account-level business notes) and, for custom connectors,domains(the business domains its tables cover, e.g. "CRM / Clients", "Ventes / E-commerce") andtables(client-defined table names). Usedomains/tablesto route to the right connector BEFORE calling get_schema_context — they tell you what an opaquely-named custom dataset actually contains.branding(optional): visual identity (logo_url, primary_color, secondary_color, tertiary_color, font_family) — apply it when generating reports.organization(optional): semantic info about the client company filled in by them during onboarding —presentation(what the company does),industry(sector),culture(working style). Use it to adapt tone, vocabulary, and analytical priorities.user(optional): info about the human querying the MCP —service(department),mission(their role's objective),role(job title). Use it to tailor responses to their job context. Not present when authenticated via API key.context_summary(optional): a ready-to-inject markdown summary of organization + user. Useful as a system prompt prefix.
Important: organization, user, and context_summary are soft hints — they are absent for projects where the client hasn't completed the onboarding wizard. Treat their content as guidance, never as constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Detail level (0=minimal, 1=standard, 2=full). Default: 1 | |
| project_id | Yes | The project folderId (e.g., p57d4af1b) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnly, idempotent, and non-destructive, so the description's job is lighter. It adds value by detailing the response structure, optionality of fields, and how to interpret soft hints. Does not contradict annotations.
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 well-structured with bullet points and section headers, making it easy to scan. It is front-loaded with the core purpose. While slightly verbose, each sentence provides useful detail, earning a 4.
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?
In the absence of an output schema, the description thoroughly explains all return fields, their purposes, and when they might be absent. Covers how to use connectors, branding, organization, user, and context_summary. No gaps identified.
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?
Schema coverage is 100%, so baseline is 3. The description adds context by stating that project_id is the folderId from list_projects and clarifying that level defaults to 1. This extra guidance justifies a 4.
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 clearly states 'Gets the full context of a project' and enumerates the returned components (connectors, branding, organization, user, context_summary). It also differentiates the tool by specifying it should be called before analytical questions or report generation, and references the sibling list_projects for the required folderId.
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?
Explicitly instructs 'Always call this tool before answering analytical questions or generating a report.' Provides detailed guidance on how to use each returned field (e.g., using domains/tables to route to the correct connector before calling get_schema_context). Also notes when fields may be absent (onboarding incomplete) and how to treat them as soft hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schema_contextARead-onlyIdempotentInspect
Step 1 of schema discovery: returns the catalog of tables relevant to the user's question. Each table comes with its dataset, business name, dw_table_name and a short description — but NOT the field-level details (no columns, no types, no semantic codes).
Use the catalog to identify the most promising candidate(s), then call get_table_schema to fetch the full structure of a specific table before writing SQL.
IMPORTANT for SQL queries: Use ONLY the dataset.table format (e.g., prod_google_ads_v2.campaign_stats). NEVER prefix with a project_id.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset | No | Optional filter on a specific data source. Accepts either the BigQuery dataset name returned by get_project_context (e.g., 'matomo_data') or the connector SKU (e.g., 'matomo') — both are tolerated. Recommended when the user mentions a specific data source. | |
| question | Yes | The user's question (e.g., 'What are the campaign spend this month?') | |
| max_tables | No | Maximum number of tables to return. Default: 5 | |
| project_id | Yes | The project folderId (e.g., p57d4af1b) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns only a catalog without field-level details, which goes beyond the annotations (readOnlyHint, idempotentHint). It sets clear expectations about the output granularity. No contradictions exist.
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 concise with only three sentences covering purpose, usage flow, and an essential SQL naming rule. It is front-loaded with the key action and outcome, then provides sequential guidance. No wasted words.
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?
Given the absence of an output schema, the description provides a complete picture: it explains the tool's role in the workflow, lists returned fields, and includes a critical usage caveat. The parameter descriptions in the schema already handle inputs, and the description covers the output format adequately.
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?
While the input schema has 100% coverage with parameter descriptions, the description does not add significant new meaning beyond the schema. It does not elaborate on parameter constraints or relationships beyond what the schema already states. The description focuses on the overall output and workflow, not on individual parameters.
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 clearly states it returns a catalog of tables relevant to the user's question, explicitly lists what fields are included (dataset, business name, dw_table_name, short description) and what is NOT included (no columns, no types, no semantic codes). It also distinguishes itself as 'Step 1 of schema discovery' and differentiates from get_table_schema.
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?
It provides explicit guidance on when to use this tool: as the first step to identify promising tables. It directs the agent to then call get_table_schema for full structure. Additionally, it gives a critical SQL naming instruction (use dataset.table format, never project_id prefix). This leaves no ambiguity about usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_table_schemaARead-onlyIdempotentInspect
Step 2 of schema discovery: returns the full structure of a single table — fields with types, semantic codes, business names, and the semantic definitions referenced by those codes. Call this AFTER get_schema_context once you've picked a candidate table.
Returns: dw_table_name (use this in SQL), description, fields[], semantic_definitions{} keyed by code.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | Connector SKU as returned by get_schema_context (e.g., 'matomo', 'googleads') | |
| table_id | Yes | Table identifier as returned by get_schema_context (the `id` field, e.g., 'behaviour_page') | |
| account_id | No | Optional. Disambiguates when the project has multiple accounts for the same SKU. | |
| project_id | Yes | The project folderId (e.g., p57d4af1b) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral details: return includes dw_table_name, fields[], semantic_definitions keyed by code. This provides useful context beyond annotations.
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?
Three sentences: first states purpose and output, second gives usage order, third lists return components. Every sentence is necessary and informative. No wasted words.
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?
Despite no output schema, description clearly explains return structure (dw_table_name, description, fields[], semantic_definitions). Combined with detailed parameter schema and annotations, this is complete for an information retrieval tool with 4 parameters.
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?
Schema coverage is 100% with detailed descriptions for each parameter. Description adds value by clarifying table_id is the 'id' field from get_schema_context, and that account_id is optional for disambiguation. This goes beyond schema.
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?
Description clearly states the tool returns full structure of a single table with fields, types, semantic codes, and definitions. It explicitly identifies as Step 2 of schema discovery, distinguishing from get_schema_context which is Step 1.
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?
Description gives explicit instruction: 'Call this AFTER get_schema_context once you've picked a candidate table.' This provides clear sequencing guidance. No alternative tools or when-not-to-use are mentioned, but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_use_casesARead-onlyIdempotentInspect
Searches for relevant use cases to answer the user's question. Use cases contain SQL templates and business definitions. Use this function to discover available analyses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of use cases to return. Default: 5 | |
| category | No | Filter by category (e.g., 'marketing-analytics', 'platform-specific') | |
| question | Yes | The user's question or need (e.g., 'How to analyze my campaign performance?') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds context that use cases contain SQL templates and business definitions, informing the agent about the content, which goes beyond the annotations.
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?
Three short, front-loaded sentences with no redundancy. Every sentence serves a purpose: stating the action, defining use cases, and providing usage direction.
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?
Lacks information about the return format or structure, which is important given no output schema. However, the tool is simple (search) and the description provides enough overall context for basic use.
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?
Schema coverage is 100% with clear descriptions for all parameters. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
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?
Clearly states it searches for use cases containing SQL templates and business definitions. Differentiates from sibling tools like create_use_case and list_my_use_cases by focusing on discovery based on a user question.
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?
Implies usage via 'Use this function to discover available analyses,' but lacks explicit guidance on when not to use it or how it compares to similar tools like list_my_use_cases or list_project_use_cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_aggregation_viewsARead-onlyIdempotentInspect
Lists aggregation views (materialized views and procedures) created for a project.
When to use this tool:
When the user asks "what views exist?", "my aggregations", "my materialized views"
Before creating a new view to check it doesn't already exist
To get the view ID for deletion
Response format: Returns a JSON array with each view's ID, full_name (dataset.name), type, SQL, description, and creation date.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project folderId (e.g., p57d4af1b) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds behavioral context by detailing the response format (JSON array with specific fields), which is beyond the annotations. No contradictions.
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?
Description is well-structured with clear sections for when to use and response format. Every sentence adds value; no redundant or extraneous information.
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 tool with one parameter and no output schema, the description fully covers purpose, usage, and return format. No gaps remain.
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?
Schema coverage is 100% with a descriptive parameter. The description does not add additional meaning to the parameter beyond the schema's description of project_id. Baseline score of 3 is appropriate.
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 clearly states it lists aggregation views (materialized views and procedures) for a project. It includes specific resource types and scope, distinguishing it from sibling tools like create/delete views.
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?
Explicitly provides three use cases: when user asks about existing views, before creating a new view to check existence, and to get view ID for deletion. This guides the agent on when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_use_casesARead-onlyIdempotentInspect
Lists your personal use cases (scope: member).
What is a use case? A use case is a reusable analysis you created or saved. It contains a business description and optionally a SQL template.
When to use this tool:
When the user asks for "my analyses", "my use cases", "what I saved"
Before creating a new use case to check it doesn't already exist
To find the ID of a use case to modify or delete
Visibility: These use cases are private and only visible to you.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by defining what a use case is and stating visibility is private. Annotations already cover readOnly, idempotent, and non-destructive hints.
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?
Well-structured with clear sections (function, definition, usage). Efficiently front-loaded, though the 'What is a use case?' section could be slightly trimmed.
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 list tool with no parameters and no output schema, the description fully explains purpose, scope, and usage context. Nothing missing.
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?
No parameters exist; schema coverage is 100% (empty). Baseline for 0 params is 4, and no additional param info is needed.
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?
Clearly states 'Lists your personal use cases (scope: member)' with a specific verb and resource. Distinguishes from siblings like 'list_project_use_cases' by emphasizing personal scope.
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?
Provides explicit 'When to use' bullet points including checking before creation and finding IDs. Context is clear, though no explicit 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_prebuildsARead-onlyIdempotentInspect
Lists pre-configured reports (prebuilds) available for a connector.
What is a prebuild? A prebuild is a standardized report maintained by Quanti for a given connector (e.g., Campaign Stats for Google Ads). It defines the BigQuery table structure (columns, types, metrics) and the associated API query.
When to use this tool:
When the user asks "what reports are available for [connector]?"
When the user doesn't know which data or metrics exist for a connector
BEFORE get_schema_context, to explore available reports for a connector
To understand the data structure before writing SQL
Difference with get_schema_context:
list_prebuilds → discover which reports/tables EXIST for a connector (catalog)
get_schema_context → get the actual BigQuery schema for the client project (effective data)
Response format: Returns a JSON with for each prebuild: its ID, name, description, BigQuery table name, and the list of fields (name, type, description, is_metric). Fields marked is_metric=true are aggregatable metrics (impressions, clicks, cost...), others are dimensions (date, campaign_name...).
SKU examples: googleads, meta, tiktok, tiktok-organic, amazon-ads, amazon-dsp, piano, shopify-v2, microsoftads, prestashop-api, mailchimp, kwanko
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | The connector name (e.g., 'googleads', 'meta', 'tiktok', 'piano', 'amazon-ads') | |
| project_id | No | The project folderId (optional). If provided, verifies project access. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds significant behavioral context: explains what a prebuild is, response format (IDs, names, fields, metrics vs dimensions), and provides SKU examples. No contradiction with annotations.
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 well-organized with sections (What is a prebuild?, When to use, Difference with...), bullet points, and response format details. Every sentence adds value; no wasted words.
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?
Despite no output schema, the description thoroughly explains the response format including field types (name, type, description, is_metric) and their semantics. Covers usage guidance and examples, making it complete for this tool.
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?
Schema coverage is 100%, but the description adds meaning beyond field names: 'sku' is described as connector name with examples ('googleads', 'meta'), and 'project_id' is explained as optional for access verification. This provides practical context not present in schema.
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 clearly states it lists pre-configured reports (prebuilds) for a connector, with a specific verb 'Lists' and resource 'prebuilds'. It distinguishes from the sibling tool get_schema_context by explaining the difference in purpose (catalog vs. effective schema).
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?
Explicitly provides when to use (user asks what reports are available, before get_schema_context) and contrasts with get_schema_context, including a bulleted list of appropriate scenarios. No exclusion criteria needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsARead-onlyIdempotentInspect
Lists all projects accessible by the user. Call this function first to discover available projects.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds 'accessible by the user', which is useful but does not contradict annotations. No new behavioral context beyond what annotations convey.
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?
Two sentences, no wasted words. Front-loaded with purpose, then usage guidance. Highly 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 parameterless list tool, the description covers purpose and usage. No output schema exists, but the description hints at functionality. Could mention return format, but not essential.
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?
Zero parameters, so schema coverage is 100%. Description does not need to add param info; baseline of 4 applies for no params.
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?
Description clearly states verb 'Lists' and resource 'projects' with scope 'accessible by the user'. It implies this is a discovery tool, but does not explicitly differentiate from siblings like list_aggregation_views or list_project_use_cases.
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?
Explicitly says 'Call this function first to discover available projects', providing clear when-to-use guidance. It does not cover when not to use, but the context of siblings suggests this is the starting point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_project_use_casesARead-onlyIdempotentInspect
Lists use cases shared with the project team (scope: project).
When to use this tool:
When the user asks for "team analyses", "project use cases"
To see what colleagues have shared
Before sharing a new use case to avoid duplicates
Visibility: These use cases are visible to all project members.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project folderId (e.g., p57d4af1b). Use list_projects to get IDs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false; description adds meaningful context about project scope and visibility to all members. No contradictions. Some minor omissions (pagination) but not critical for a list tool.
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?
Concise (4 lines) with well-structured sections: purpose sentence, bulleted usage guidelines, visibility note. Every sentence adds value; no redundancy.
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 list tool with comprehensive schema and annotations, the description covers purpose, usage context, and visibility. No output schema needed; complete for effective use.
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?
Schema coverage is 100% with parameter description including format and cross-reference to list_projects. Description adds no further parameter details beyond schema, achieving baseline score for high coverage.
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?
Description clearly states it lists use cases shared with the project team, scoped to project. The verb 'Lists' is specific, and it distinguishes from siblings like list_my_use_cases (personal) and get_use_cases (specific retrieval).
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?
Provides explicit 'When to use this tool' section with example queries and advice to avoid duplicates. Clearly states visibility to project members, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_scheduled_queriesARead-onlyIdempotentInspect
Lists scheduled queries configured in the project's BigQuery.
What is a scheduled query? A scheduled query is a SQL query automatically executed on a defined schedule in BigQuery. It is used to aggregate data, populate reporting tables, or perform recurring transformations.
When to use this tool:
When the user EXPLICITLY asks about scheduled queries, BigQuery pipelines, or transfer configs
When the user asks "what are my scheduled queries?", "my BigQuery pipelines"
To check execution frequency or status of a specific scheduled query
Do NOT use this tool for general data queries, analytics, or when the user asks about page views, metrics, or data from connectors. Use get_schema_context + execute_query instead.
Available filters:
dataset: filter by destination dataset (e.g., 'prod_reports')
status: filter by status 'active' (enabled) or 'disabled'
Response format: Returns a JSON with for each scheduled query: its name, SQL query, execution schedule, destination dataset, status (active/disabled), and last/next execution dates.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status: 'active' (enabled) or 'disabled'. Optional. | |
| dataset | No | Filter by destination dataset (e.g., 'prod_reports'). Optional. | |
| project_id | Yes | The project folderId (e.g., p57d4af1b). Use list_projects to get IDs. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, establishing it as a safe read operation. The description adds context about response format and available filters, but does not go beyond what is expected given the annotations. No contradictions.
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?
Well-structured with sections and bullet points, but somewhat verbose. Could be slightly more concise while retaining all necessary information. No wasted sentences.
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?
With no output schema, the description explains the response format (JSON with name, SQL, schedule, etc.). It covers filters and usage context, making it sufficiently complete for this tool.
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?
Schema coverage is 100% for all 3 parameters. The description adds value by explaining the filters (dataset, status) with examples and referencing list_projects for project_id. This improves parameter understanding beyond the schema.
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 clearly states it lists scheduled queries, with specific verb and resource. It distinguishes from sibling tools like execute_query and get_schema_context, ensuring the agent understands its unique purpose.
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?
Explicitly provides when-to-use and when-not-to-use scenarios, including reference to alternatives for general data queries (get_schema_context + execute_query). This is exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_mmmAInspect
Re-runs a Marketing Mix Modeling study previously configured with setup_mmm.
Important: Do NOT call this right after setup_mmm. The first run is automatically triggered by setup_mmm. Use run_mmm only to re-launch an existing study later (e.g., after data refresh or parameter changes).
Prerequisite: Must have called setup_mmm first to obtain an account_id.
Duration: The Meridian fit (MCMC) takes approximately 10-30 minutes depending on data volume. The user will receive an email when results are ready.
Results: Results are written to the project's data warehouse (mmm_channel_summary and mmm_weekly_contributions tables). They can then be queried via execute_query.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The account_id returned by setup_mmm | |
| project_id | Yes | The project folderId |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides details beyond annotations: duration estimate, email notification, and result storage location. Annotations are present but add minimal info; description fills gaps.
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?
Well-structured with sections, front-loaded with core action, no unnecessary words.
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?
Covers all needed context: when to use, prerequisites, duration, output location, and notification method.
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?
Schema coverage is 100%, and description adds context connecting account_id to setup_mmm's return value and project_id to folderId.
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 clearly states it re-runs a previously configured MMM study, distinguishing it from setup_mmm which triggers the first run.
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?
Explicitly warns not to call right after setup_mmm, specifies prerequisite (setup_mmm), and indicates use cases like re-launch after data refresh or parameter changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setup_mmmAInspect
Configures a Marketing Mix Modeling (MMM) study for a project.
What is MMM? Marketing Mix Modeling measures the real contribution of each marketing channel (Google Ads, Meta, etc.) on a KPI (leads, revenue, conversions), accounting for external factors (seasonality, holidays, promotions).
Recommended workflow:
Use get_schema_context to discover the project's tables/columns
Generate input SQL queries (KPI, channels, exogenous variables)
Validate each query before calling setup_mmm: Use execute_query to run a COUNT() wrapper on each input query (e.g., SELECT COUNT() FROM ()). If any query returns 0 rows, do NOT include it in setup_mmm — warn the user that the data source is empty and ask whether to proceed without it or fix the query.
Call setup_mmm with the validated SQL queries — the study is automatically launched after setup
Do NOT call run_mmm after setup_mmm: the first run is triggered automatically
Important: run_mmm is only needed to RE-RUN an existing study later, not after initial setup.
Input queries format: Each query must return a "time" column (DATE) and the requested metrics.
role="kpi": a "kpi" column (the target KPI)
role="channel": "spend" and "impressions" columns + channel_name
role="exogenous": columns named after the exogenous variables + columns[]
Granularity: "weekly" is recommended (MMM standard). SQL should aggregate by week.
Important: Adapt the SQL dialect to the project's data warehouse type (BigQuery, Snowflake, Redshift).
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | Analysis period end date (YYYY-MM-DD format) | |
| kpi_type | No | KPI type: 'leads', 'revenue', 'conversions'. Determines the Meridian mode (revenue vs non_revenue). | |
| question | No | The analyst's question (for traceability). E.g., 'What is the ROI of Google Ads vs Meta?' | |
| project_id | Yes | The project folderId (e.g., p57d4af1b) | |
| start_date | Yes | Analysis period start date (YYYY-MM-DD format) | |
| study_name | No | Custom name for this MMM study (used as connector account name). E.g., 'Q1 2025 Channel ROI'. If not provided, defaults to the question or 'MMM Study'. | |
| destination | No | Data warehouse type: 'bigquery', 'snowflake', 'redshift'. Default: bigquery. | |
| granularity | No | Time granularity: 'weekly' (recommended) or 'daily'. Default: weekly. | |
| input_queries | Yes | List of input SQL queries. Each element: {role: 'kpi'|'channel'|'exogenous', channel_name?: string, columns?: string[], sql: string, name?: string} | |
| output_tables | No | Output tables (optional, default: channel_summary + weekly_contributions). Format: {id: string, name: string, source: 'channels'|'weekly'} |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the study is automatically launched after setup, so no need for run_mmm. Annotations already show readOnlyHint=false and destructiveHint=false, and description adds value by describing automatic launch and re-run behavior.
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?
Well-structured with sections and bullet points; front-loads purpose. Slightly verbose but appropriate given complexity. Each sentence adds value.
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?
Covers workflow, input format, important caveats, and integrates with sibling tools. No output schema, but description compensates with return behavior info. Adequately complete for an AI agent.
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?
Schema coverage is 100%, but description adds significant context: explains query roles (kpi, channel, exogenous) with required columns, kpi_type's effect on Meridian mode, and destination/granularity defaults.
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?
Clearly states it configures an MMM study for a project, explains MMM, and distinguishes from sibling 'run_mmm' by noting that run_mmm is only for re-runs, not after setup.
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?
Provides explicit workflow: validate queries with execute_query before calling setup_mmm, warns not to call run_mmm after setup, and advises adapting SQL dialect to warehouse type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_use_caseAInspect
Updates an existing use case that you created.
When to use this tool:
To improve the description or SQL of an existing use case
To fix an error in a use case
To change a use case's category
Permissions: You can only modify use cases you created.
Tip: Use list_my_use_cases or list_project_use_cases first to get the use case ID.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New use case name (optional) | |
| prompt | No | New structured prompt (optional) | |
| category | No | New category (optional) | |
| description | No | New business description (optional) | |
| use_case_id | Yes | The UUID ID of the use case to modify. Get it from list_my_use_cases or list_project_use_cases. | |
| sql_template | No | New SQL template (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds critical permission context ('only modify use cases you created') not present in annotations, but does not disclose potential side effects or error behavior, which is acceptable for a non-destructive update.
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?
Concise and well-structured: main action first, followed by bulleted use cases, permissions, and a tip. Every sentence adds value with no redundancy.
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?
Adequately covers usage, permissions, and prerequisite hint for a CRUD update tool. Lacks return value description, but no output schema exists. Given the moderate complexity (6 parameters, 1 required), the description is sufficiently complete.
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?
Schema description coverage is 100%, so the schema fully documents each parameter. The description does not add parameter-level detail beyond referencing 'description or SQL' and 'category,' which aligns with schema fields. With high coverage, baseline 3 is appropriate.
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 clearly states 'Updates an existing use case that you created,' specifying the verb and resource. It lists specific scenarios (improve description/SQL, fix error, change category) and distinguishes from siblings like create_use_case.
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?
Explicitly provides a 'When to use this tool' section with three clear use cases. Includes permission constraint ('only modify use cases you created') and a tip to first get the ID via list_*_use_cases, guiding appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!