Skip to main content
Glama
doitintl

DoiT MCP Server

Official
by doitintl

run_query

Read-only

Analyze cloud costs, generate cost breakdowns, and view spending trends by running custom analytics queries across your cloud providers.

Instructions

Use this when the user wants to analyze cloud costs, generate a cost breakdown, view spending trends, or run a custom analytics query across their cloud providers. Accepts a structured config with data source, metrics, dimensions, time range, and filters. Do NOT use this for listing saved reports (use list_reports), checking anomalies (use get_anomalies), or viewing budgets (use list_budgets). Fields that are not populated will use their default values if needed. To limit the number of rows returned per group, set the limit.value field inside each config.group[] entry (maximum 25). If possible, use timeRange instead of customTimeRange when no specific dates are given. Use "includeCurrent": true to include the current in-progress month. Use "includeCurrent": false only when asking about a fully completed past period. Always use "metrics" (array) not the deprecated "metric" (object).

ALWAYS include a "group" with id "service_description" and type "fixed" unless the user explicitly asks to group by something else. This gives a per-service cost breakdown which is always the most useful default.

Common grouping dimension IDs (all type "fixed"):
  "service_description" — cloud service (default)
  "project_id"          — GCP project / AWS account / Azure subscription (use when user asks to group by project, account, or subscription)
  "cloud_provider"      — cloud provider (AWS / GCP / Azure)

IMPORTANT — filter values are dimension IDs, never display names. Before filtering on any dimension
you are unsure about, call get_dimension({type, id}) to retrieve the exact valid values for this customer.
Known cloud provider IDs (cloud_provider, type "fixed"):
  "amazon-web-services" = AWS, "google-cloud" = GCP, "microsoft-azure" = Azure

Example — top AWS services last month:
{
  "config": {
    "dataSource": "billing",
    "metrics": [{"type": "basic", "value": "cost"}],
    "timeRange": {"mode": "last", "amount": 1, "unit": "month", "includeCurrent": true},
    "filters": [{"id": "cloud_provider", "type": "fixed", "values": ["amazon-web-services"]}],
    "group": [{"id": "service_description", "type": "fixed", "limit": {"metric": {"type": "basic", "value": "cost"}, "sort": "desc", "value": 10}}]
  }
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configYesConfiguration for the query. Use the dimension tool to look up valid dimension IDs.
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context about defaulting behavior, row limits, and the need to call get_dimension for filter values, enhancing transparency 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.

Conciseness4/5

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

Well-structured with paragraphs, bullet points, and an example. Information is front-loaded with purpose and usage. However, it is verbose in places, repeating some advice (e.g., group defaults mentioned twice). Still, every section serves a purpose.

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

Completeness4/5

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

For a complex tool with many nested parameters and no output schema, the description covers use cases, defaults, pitfalls, and provides a comprehensive example. It could briefly mention the response format, but overall it equips the agent with sufficient context for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, yet the description adds significant value by explaining field usage (e.g., includeCurrent meaning, group defaults, filter value requirements). It warns about deprecated metric fields and provides examples that clarify nested structures.

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?

The description clearly states the tool's purpose: to analyze cloud costs, generate cost breakdowns, and run custom analytics queries. It explicitly distinguishes from siblings by listing when not to use it (list_reports, get_anomalies, list_budgets), making its role unambiguous.

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?

Provides explicit when-to-use scenarios (cost analysis, trends) and when-not-to-use scenarios (listing reports, checking anomalies, budgets). Offers detailed guidance on default values, field precedence (timeRange over customTimeRange), and required group defaults, with concrete examples.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/doitintl/doit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server