CloudScope MCP is a read-only Model Context Protocol server that provides AI assistants with cloud cost management capabilities across Azure and GCP. No cloud resources are created, modified, or deleted.
Cost Analysis
Get cost breakdowns by service, resource group, tag, or region for any date range
Compare spending across two time periods to spot changes
Identify the most expensive individual resources
Analyze costs by tag/label for chargeback and cost allocation
Combine costs across multiple Azure subscriptions or GCP projects
Monitoring & Forecasting
Detect spending anomalies by comparing recent days against a prior period
Check budget status: current spend, percentage used, forecast, and overage risk
Forecast future spending using linear trend analysis from the last 30 days
Optimization & Governance
Fetch cost-saving recommendations from Azure Advisor or GCP Recommender, filtered by category (compute, storage, networking)
Identify idle/unused resources (unattached disks, orphaned IPs, idle VMs) with estimated monthly savings
Find untagged resources that hinder cost attribution
Utility Tools
Retrieve the current date and month boundaries for use in queries
List accessible Azure subscriptions or GCP projects
Guided Workflows
Monthly cost review — Full report covering spend, comparisons, anomalies, budgets, and forecasts
Waste audit — Focused report on idle resources and optimization opportunities
Cost spike investigation — Root-cause analysis for unexpected cost increases
Executive summary — Brief, non-technical cost overview for leadership
Chargeback report — Cost allocation by tag/label for internal billing
Provides tools for querying and analyzing cloud costs from GCP (Google Cloud Platform), including cost summaries, anomaly detection, budget status, idle resource identification, and cross-project cost comparisons.
Ask your AI about your cloud bill.
Ask once: "Give me this month's cost review" — and CloudScope runs the full workflow (spend, deltas, anomalies, idle resources, budgets, forecast) and hands back a decision-ready report, not raw numbers to interpret yourself:
Related MCP server: Azure FinOps Elite
TL;DR
Month-to-date Azure spend is $4,312 (May 1–29), tracking +11% vs April. The mover is App Service (+$280) — a new staging slot left running. 2 idle resources cost $94/month;
prod-budgetis at 78% with 2 days left. Top action: delete the orphaned managed disk → save $63/month.Spend This Month
Service
Cost
%
Virtual Machines
$2,140
49.6%
App Service
$890
20.6%
Storage
$612
14.2%
Redis Cache
$410
9.5%
Networking
$260
6.0%
vs Last Month
+$427 (+11%) overall. App Service +$280 drove most of it; everything else flat. → new
staging-slot-2, created May 12, never torn down.Idle & Wasted Resources
Resource
Type
$/month
orphaned-osdisk-01Managed Disk
$63
old-lb-ipPublic IP
$31
Budget Status
prod-budget— 78% used, $4,312 / $5,500, on track (2 days left).Recommended Actions
Delete
orphaned-osdisk-01(unattached 40 days) → $63/monthTear down
staging-slot-2if staging is idle → ~$280/monthRelease
old-lb-ip(no binding) → $31/month
Illustrative example showing the report format. Run /cloudscope:monthly-cost-review against your own subscription for live numbers.
Azure is auto-detected from your
az loginsession. GCP requires BigQuery billing export setup (see below).
Provider | Status |
Azure | ✅ Supported |
GCP | ✅ Supported |
AWS |
Azure CLI installed and logged in (az login)
Cost Management Reader role on the subscription
gcloud CLI installed and logged in (gcloud auth application-default login)
Billing export to BigQuery enabled — this is a one-time manual setup step, not enabled by default (the detailed export is recommended for resource-level cost queries)
BigQuery Data Viewer + BigQuery Job User roles on the dataset project
Note: BigQuery on-demand queries cost $6.25 per TiB scanned (pricing). The first 1 TiB/month is free. Billing export tables are small — typical CloudScope queries cost <$0.01 each.
CloudScope auto-detects your subscription from az login. Just add the server:
{
"mcpServers": {
"cloudscope": {
"command": "npx",
"args": ["-y", "cloudscope-mcp"]
}
}
}To target a specific subscription, add an env block:
{
"mcpServers": {
"cloudscope": {
"command": "npx",
"args": ["-y", "cloudscope-mcp"],
"env": {
"AZURE_SUBSCRIPTION_ID": "your-subscription-id"
}
}
}
}Variable | Description |
| Azure AD tenant ID |
| App registration client ID |
| App registration client secret |
Set these alongside AZURE_SUBSCRIPTION_ID in the env block above.
GCP requires a BigQuery billing export table. Find your table name in GCP Console > Billing > Billing export > BigQuery export.
{
"mcpServers": {
"cloudscope": {
"command": "npx",
"args": ["-y", "cloudscope-mcp"],
"env": {
"GOOGLE_CLOUD_PROJECT": "my-project",
"GCP_BILLING_TABLE": "my-project.my_dataset.gcp_billing_export_resource_v1_XXXXXX"
}
}
}
}Set GOOGLE_CLOUD_PROJECT to your GCP project ID. Override with GCP_PROJECT_ID if your billing dataset lives in a different project.
These variables apply only when using GCP; Azure-only users can skip them.
Variable | Description | Required |
| GCP project ID | Yes |
| Fully-qualified BigQuery table ( | Yes |
| Override project ID if different from | No |
| Billing account ID for budget monitoring | No |
| Path to service account JSON key file | No |
{
"mcpServers": {
"cloudscope": {
"command": "npx",
"args": ["-y", "cloudscope-mcp"],
"env": {
"AZURE_SUBSCRIPTION_ID": "your-subscription-id",
"GOOGLE_CLOUD_PROJECT": "my-project",
"GCP_BILLING_TABLE": "my-project.my_dataset.gcp_billing_export_resource_v1_XXXXXX"
}
}
}
}Azure is auto-detected from az login. Add AZURE_SUBSCRIPTION_ID to target a specific subscription.
"How much did Azure cost last month?"
"Show GCP spending by service for the last 7 days"
"Any cost anomalies this week on GCP?"
"What will Azure cost next month?"
"Show me cost optimization recommendations for GCP"
"Compare Azure and GCP costs across all projects and subscriptions"
CloudScope is read-only. It cannot create, modify, or delete any cloud resources. Azure uses Cost Management Reader permissions. GCP uses BigQuery Data Viewer + Job User with no write access.
Does this modify my cloud resources? No. Read-only access only.
Do I need a service principal? No. az login (Azure) or gcloud auth application-default login (GCP) works for local use.
Does the Azure Cost Management API cost money? No. It's free.
Do GCP BigQuery cost queries cost money? Yes, but typically <$0.01 per query ($6.25/TiB scanned, first 1 TiB/month free). See BigQuery pricing.
Can I use both Azure and GCP at the same time? Yes. Configure both sets of env vars and CloudScope queries whichever provider you specify in each tool call.
git clone https://github.com/alexpota/cloudscope-mcp.git
cd cloudscope-mcp
npm install
npm run build
npm test
npx @modelcontextprotocol/inspector node dist/index.jsMost tools accept a provider parameter (azure or gcp); the provider-specific tools (list_subscriptions, list_projects, and the cross-account tools get_cross_subscription_costs / get_cross_project_costs) are fixed to their own cloud. The default provider is auto-detected based on which providers are configured.
Cost Analysis
Tool | Description | Key Parameters |
| Spending breakdown by service, group, or region |
|
| Costs grouped by a tag/label key |
|
| Side-by-side cost comparison of two date ranges |
|
| Most expensive individual resources |
|
| Combined costs across Azure subscriptions |
|
| Combined costs across GCP projects |
|
Monitoring
Tool | Description | Key Parameters |
| Find spending spikes vs previous period |
|
| Budget status, current spend, projected overage | (none) |
| Predict spending based on current trends |
|
Optimization
Tool | Description | Key Parameters |
| Cost optimization suggestions (Azure Advisor / GCP Recommender) |
|
| Provisioned but unused resources with cost estimates | (none) |
| Resources with no tags/labels (cost attribution gaps) | (none) |
Utility
Tool | Description | Key Parameters |
| Today's date and current/previous month bounds | (none) |
| Azure subscriptions with active indicator | (none) |
| GCP projects with active indicator | (none) |
Guided workflows that produce structured reports. All prompts accept an optional provider argument (azure or gcp). In Claude Code, type /cloudscope: to see all prompts. In Claude Desktop, click the + button → Connectors → cloudscope.
Prompt | Description | Arguments |
| Complete monthly review: spending, last-month comparison, anomalies, top resources, budgets, forecast, savings opportunities |
|
| Find wasted spend: top resources, optimization recommendations, at-risk budgets, total potential savings |
|
| Root-cause analysis for a cost increase: which services, which resources, trend vs one-time, recommended actions |
|
| Brief non-technical cost summary for leadership: spend, trend, budget status, top drivers, forecast, key recommendation |
|
| Cost allocation by tag/label key for chargeback: spending per value, untagged resources, tagged vs untagged split, month-over-month |
|
Check budget status: current spend vs limit, percentage used, forecast, and overage risk. For GCP, requires GCP_BILLING_ACCOUNT_ID to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety is covered. The description adds the GCP prerequisite and mentions the type of data returned (forecast, overage risk), providing useful behavioral 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 sentences: first states the purpose concisely, second adds a critical prerequisite. No unnecessary words, front-loaded with key 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?
The description covers the tool's purpose and key conditions clearly. With no output schema, it lists the types of data returned (spend vs limit, percentage, forecast, overage risk). Could mention relationship to cost tools, but adequate for a simple read tool with annotations.
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% with the parameter 'provider' fully described. The description adds no additional meaning beyond the schema, only a conditional usage note. Baseline of 3 applies as per guidelines.
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 uses a specific verb 'Check' and resource 'budget status', clearly listing the metrics (current spend vs limit, percentage used, forecast, overage risk). None of the sibling tools mention budgets, so it distinguishes well.
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 condition for GCP usage (requires GCP_BILLING_ACCOUNT_ID) but does not explicitly state when to use vs alternatives like cost summary or forecasts. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare costs between two date ranges, showing per-service absolute and percentage changes.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| period_a_start | Yes | Period A start date (YYYY-MM-DD) | |
| period_a_end | Yes | Period A end date (YYYY-MM-DD) | |
| period_b_start | Yes | Period B start date (YYYY-MM-DD) | |
| period_b_end | Yes | Period B end date (YYYY-MM-DD) | |
| group_by | No | How to group costs: service or resource_group | service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a safe, read-only operation. The description adds value by specifying that output includes per-service absolute and percentage changes, providing transparency 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?
The description is a single concise sentence (13 words) that is front-loaded and free of superfluous information. Every word 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?
Given the lack of an output schema, the description adequately explains the return format (per-service absolute and percentage changes). For a tool with 6 parameters and rich annotations, this provides sufficient context for 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?
Since schema description coverage is 100%, the description does not need to add parameter details. The description does not elaborate on parameters beyond what the schema provides, which is acceptable at baseline.
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 action (compare), the resource (costs between two date ranges), and the output (per-service absolute and percentage changes). It effectively distinguishes this tool from sibling tools like get_cost_summary or get_cost_forecast.
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 implies usage for comparing cost periods but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares daily spending over the last N days against the prior N days to find cost spikes. Returns a list of services where spending increased above the threshold percentage, sorted by increase amount. Each entry includes service name, previous cost, current cost, percentage change, and absolute change in USD. Returns an empty list if no anomalies found. Use this when the user asks about unexpected cost increases, billing surprises, or wants to know if anything changed recently.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| days | No | Number of days to compare (default: 7) | |
| threshold | No | Minimum percentage increase to flag (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the comparison logic, sorting, and that it returns an empty list if no anomalies. Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about the output structure but not about rate limits or prerequisites.
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?
Four sentences, no fluff, front-loaded with the main action. 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?
Given the tool's simplicity (3 optional params, no output schema), the description covers what it does, what it returns, and when to use it. 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% with clear descriptions for all parameters. The description does not add extra parameter details beyond the schema, but it contextually explains how days is used for both periods. 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 the tool compares daily spending to find cost spikes, lists the output fields, and distinguishes its purpose from siblings like compare_periods by focusing on anomaly detection.
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 tells when to use the tool: when the user asks about unexpected cost increases, billing surprises, or recent changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds cloud resources that are provisioned but not actively used — unattached disks, orphaned network interfaces, unused IPs, idle VMs, and empty compute plans. Returns each resource with its name, type, resource group/project, reason it is idle, and estimated monthly cost in USD. Returns an empty list if no idle resources are found. Use this when the user asks about waste, idle or unused resources, cleanup opportunities, or wants to find resources to delete to reduce costs.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures basic read-only behavior, return format (name, type, group, reason, cost), and empty list case. Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds useful return details but could mention pagination or rate limits.
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, no redundancy. Front-loaded purpose, then return details, then usage guidance. 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?
Given the low parameter count (1), no required parameters, comprehensive annotations, and no output schema, the description adequately covers all necessary context including return format and empty result behavior.
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 the single 'provider' parameter having a clear description and enum. The description does not add new meaning beyond the schema, 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?
Description specifies exactly what the tool does: find provisioned but unused cloud resources (unattached disks, orphaned interfaces, unused IPs, idle VMs, empty compute plans). It clearly distinguishes from sibling tools like find_untagged_resources by focusing on idle resources.
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 states when to use: when user asks about waste, idle or unused resources, cleanup opportunities, or cost reduction. This provides clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds resources that have no tags or labels applied. Returns each resource with its name, type, resource group/project, and location. Untagged resources cannot be attributed to teams or projects, making cost allocation and chargeback impossible. Returns an empty list if all resources are tagged. Use this when the user asks about tagging compliance, governance, cost attribution gaps, or wants to identify resources that need tags or labels.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that results include specific fields, returns empty list if all tagged, and explains the business impact. Annotations already indicate it's safe and idempotent, but the description provides useful behavioral context beyond them.
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?
Four sentences, no wasted words. First sentence states purpose, second details output, third explains importance, fourth gives usage guidance. Efficient and well-structured.
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 tool with one parameter and no output schema, the description covers the output format, edge case (empty list), and business relevance. Complete and sufficient.
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?
The single parameter 'provider' is fully documented in the schema with enum values. The description adds meaning by explaining the output structure and the empty list case, going beyond what the schema provides.
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 finds resources without tags/labels, specifying the returned fields (name, type, resource group/project, location). It distinguishes from siblings like 'get_cost_by_tag' which deals with tagged resources.
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 to use when the user asks about tagging compliance, governance, or cost attribution gaps. Does not mention when not to use or alternatives, but the context is clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Breaks down costs by a specific tag or label key such as team, environment, or project. Returns a sorted table with each tag value, cost in USD, and percentage of total. Includes a total row and daily average. Returns an error if the date range is invalid or no tagged costs exist. Use this when the user asks about costs per team, per environment, cost allocation, chargeback, or wants to understand spending by any custom tag or label.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| tag_key | Yes | Tag/label key to group costs by (e.g. team, environment, project) | |
| start_date | No | Start date (YYYY-MM-DD). Defaults to first of current month. | |
| end_date | No | End date (YYYY-MM-DD). Defaults to today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by mentioning error conditions (invalid date range, no tagged costs) and output structure. It 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 two well-structured sentences. The first states functionality and output, the second gives usage guidance and error conditions. 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 no output schema, the description adequately covers purpose, output, and errors. It could mention sorting order or pagination, but the annotations (openWorldHint) imply results may vary. Overall, sufficiently complete for a read-only analytical 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 the schema already describes all parameters. The description adds context about default provider and grouping by tag_key, but doesn't significantly enhance meaning 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 breaks down costs by a specific tag key and returns a sorted table with cost, percentage, total, and daily average. It distinguishes itself from siblings like find_untagged_resources by focusing on cost allocation by tag.
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 tells when to use this tool (e.g., 'costs per team, per environment, cost allocation, chargeback'). It lacks explicit when-not-to-use or alternatives among siblings, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Projects future cloud spending for the next N days using a linear trend based on the last 30 days of actual costs. Returns the forecast period dates, projected total cost in USD, average daily projected cost, and the confidence basis (number of historical days used). Use this when the user asks "how much will I spend this month", wants to predict upcoming bills, or needs to plan budgets. Returns an error if insufficient historical data exists.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| days | No | Number of days to forecast (default: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. Description adds behavioral details: linear trend, 30-day historical basis, return fields, and error condition. 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?
Two sentences: first states functionality and outputs, second gives usage and error condition. No fluff, front-loaded, every sentence earns its place.
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 explains return values. Parameters are fully documented in schema. Error condition is mentioned. Complete for a forecast tool with given context signals.
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 for both parameters. Description does not add new meaning beyond that, but it implies the days parameter corresponds to 'next N days'. 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 the tool projects future cloud spending using a linear trend based on the last 30 days. It lists specific return values and distinguishes from siblings like check_budgets or get_cost_summary.
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 usage guidance is given: use when user asks about monthly spend, predicts bills, or plans budgets. It also mentions error condition for insufficient data. No mention of when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a cost breakdown for a date range grouped by service, resource group, tag, or region. Defaults to current month if dates are omitted. Output includes a sorted table with each group name, cost in USD, and percentage of total. Includes a total row, daily average, and collapses groups beyond the top 10 into an "Other" row. Returns an error if the date range is invalid. Use this when the user asks "how much am I spending", "what costs the most", "show me my cloud bill", or wants a spending overview.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| start_date | No | Start date (YYYY-MM-DD). Defaults to first of current month. | |
| end_date | No | End date (YYYY-MM-DD). Defaults to today. | |
| group_by | No | How to group costs: service, resource_group, tag, or region | service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds details beyond the annotations: it explains the output format (sorted table with percentage, total row, daily average, and 'Other' row for groups beyond top 10), and mentions error behavior for invalid date ranges. This complements the readOnlyHint and idempotentHint well.
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 four sentences, each serving a purpose: first defines the function, second explains defaults, third details output, fourth warns about errors and gives usage examples. It is well-structured and not overly long.
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 no output schema, the description compensates by detailing the output structure. It covers all four parameters implicitly and addresses common use cases. For a read-only summary tool with 15 siblings, it provides enough context to distinguish from related tools like get_cost_by_tag or compare_periods.
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 for all parameters. The description does not add new semantics beyond defaults (e.g., provider defaults to azure, dates default to current month/today) which are already in the schema. So minimally adds value.
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 cost breakdown grouped by service, resource group, tag, or region for a date range. It gives specific example queries like 'how much am I spending' and 'show me my cloud bill', which makes the purpose immediate and distinguishable from siblings.
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 says to use this tool when the user asks for cost overviews, providing concrete query examples. However, it does not mention when to avoid it or suggest alternatives like get_cost_by_tag for specific tag breakdowns, which would make it more complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a combined cost breakdown across multiple GCP projects sorted by total spend. Each project shows its name, total cost in USD, and percentage of the combined total. Use this when the user asks about costs across all GCP projects, wants to compare project spending, or needs an organization-wide cost overview.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Cloud provider (GCP-only tool) | |
| project_ids | No | Project IDs to include. Defaults to all known projects. | |
| start_date | No | Start date (YYYY-MM-DD). Defaults to first of current month. | |
| end_date | No | End date (YYYY-MM-DD). Defaults to today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds that results are sorted by total spend and include percentage, which is not in annotations. No contradiction. It does not mention rate limits or data freshness, but annotations cover safety adequately.
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, no wasted words. First sentence states the main result, second sentence details output fields, third sentence gives usage guidance. Front-loaded with action verb.
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?
Description explains what the tool returns and when to use it. It lacks details about default date ranges (handled in schema) and output format specifics, but is sufficient for an agent to select and invoke correctly given the annotations and schema coverage.
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 baseline is 3. Description does not add extra parameter semantics beyond the schema; it only restates the tool's purpose. No new constraints or formats explained.
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 returns a combined cost breakdown across multiple GCP projects, sorted by total spend. It lists the returned fields (name, total cost, percentage). The verb 'returns' is specific and the resource is well-defined. It distinguishes from sibling tools like get_cross_subscription_costs by specifying GCP.
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 explicitly mentions three use cases: when user asks about costs across all GCP projects, wants to compare spending, or needs organization-wide overview. It does not explicitly say when not to use, but the context and sibling list imply it's for GCP only. Could mention alternatives like get_cross_subscription_costs, but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a combined cost breakdown across multiple Azure subscriptions sorted by total spend. Each subscription shows its name, total cost in USD, and percentage of the combined total. Handles partial failures gracefully — if some subscriptions are inaccessible, returns results for the rest with a warning. Use this when the user asks about costs across all subscriptions, wants to compare subscription spending, or needs an organization-wide cost overview.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Cloud provider (Azure-only tool) | |
| subscription_ids | No | Subscription IDs to include. Defaults to all enabled subscriptions. | |
| start_date | No | Start date (YYYY-MM-DD). Defaults to first of current month. | |
| end_date | No | End date (YYYY-MM-DD). Defaults to today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, open-world. Description adds valuable context: partial failure handling with warning, sorting by total spend. 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?
Three well-structured sentences covering purpose, output and failure behavior, and usage guidance. No redundant 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?
Despite no output schema, description sufficiently explains output fields (name, total cost in USD, percentage), date range defaults, and subscription selection. Handles partial failures. 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% with descriptions. Description adds no further parameter meaning beyond defaults and output fields, but that is sufficient given high schema 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 returns a combined cost breakdown across multiple Azure subscriptions sorted by total spend, listing output fields. Distinct from siblings like get_cross_project_costs and get_cost_summary.
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 guides when to use: when user asks about costs across all subscriptions, wants to compare, or needs organization-wide overview. No explicit exclusions or alternative references, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns today's date and the start/end of current and previous months in YYYY-MM-DD format
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds specific behavioral details about what dates are returned (start/end of current and previous months), which goes 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?
Single sentence, front-loaded with the key purpose and format. 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?
Given no parameters, no output schema, and annotations covering safety, the description fully specifies what the tool returns. No gaps.
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, so baseline is 4. The description does not need to add parameter 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?
The description clearly states the tool returns today's date and start/end of current and previous months. It distinguishes from sibling tools focused on budgets, costs, and projects.
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?
No explicit guidance on when to use vs alternatives, but the tool is simple and unique among siblings, so usage is implied. Lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all GCP projects the current credential can access, with name, ID, and state. Shows which project is currently active. Use this when the user has multiple GCP projects and wants to see which ones are available, or before calling get_cross_project_costs.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Cloud provider (GCP-only tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds concrete return fields (name, ID, state) and active project indicator, which is useful but not exhaustive.
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, front-loaded with purpose and output, followed by usage 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 simple nature of the tool, the description covers purpose, usage, output fields, and safety (via annotations). No output schema needed.
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 one trivial parameter (provider const 'gcp'). Description adds no extra semantic value beyond the schema, 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?
Description specifies verb 'Returns' and resource 'GCP projects' with details on output fields (name, ID, state, active project). Distinguishes itself from sibling tools like get_cross_project_costs.
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 states when to use: when user has multiple projects and before calling get_cross_project_costs. Provides clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches cost-saving recommendations filtered by category. Returns a list of recommendations each containing: title, category, impact level (high/medium/low), estimated annual savings in USD, affected resource ID, and a short description of the suggested action. Returns an empty list if no recommendations exist for the selected category. Use this when the user wants to reduce costs, find waste, or optimize resource usage.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| category | No | Filter by category: all, compute, storage, or networking | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds meaningful detail: returns empty list if no recommendations, and lists return fields. 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 concise, with two functional sentences and a usage guideline sentence. Front-loaded with the core purpose, 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?
The description is complete for this simple tool: explains return structure, empty list behavior, and usage context. Annotations cover safety. No output schema needed.
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% with both parameters having descriptions and enums. The 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?
The description clearly states it fetches cost-saving recommendations filtered by category, with a specific verb and resource. It provides a usage directive but does not explicitly distinguish from sibling tools like find_idle_resources or check_budgets.
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 says to use this when the user wants to reduce costs, find waste, or optimize resource usage. However, it does not specify when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all Azure subscriptions the current credential can access, with name, ID, and state. Shows which subscription is currently active. Use this when the user has multiple subscriptions and wants to see which ones are available, or to confirm which subscription is being queried.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Cloud provider (Azure-only tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds transparency by specifying the returned fields (name, ID, state) and that it shows the active subscription. It doesn't contradict annotations and provides useful 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?
The description is two sentences: the first states the core functionality, the second provides usage guidance. Every sentence adds value, no fluff, and it is front-loaded. Ideal conciseness.
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 listing tool with one parameter and comprehensive annotations, the description is complete. It describes what is returned, when to use it, and the constraint (Azure-only). Output schema is not needed because the description enumerates returned fields.
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?
The schema covers the single parameter 'provider' with a const value 'azure' and a description, achieving 100% coverage. The description doesn't add further parameter semantics, but the schema description is sufficient, placing this at baseline 3.
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 returns all Azure subscriptions the credential can access, including name, ID, state, and active status. This verb+resource combination is specific and distinguishes it from sibling tools that deal with projects or costs.
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 advises using it when the user has multiple subscriptions and wants to see availability or confirm the active subscription. It doesn't explicitly state when not to use it, but given the tool's nature and sibling tools, 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.
Find the N most expensive individual resources over a time period. On GCP, requires the detailed billing export for resource-level data.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Cloud provider to query (azure or gcp) | azure |
| days | No | Number of days to look back (default: 30) | |
| limit | No | Number of resources to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds the prerequisite about GCP billing export, which is critical behavioral context. It 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?
Two concise sentences: one states purpose, the other adds an important prerequisite. No unnecessary words or repetition. Excellent front-loading of intent.
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 no output schema, the description could mention the sorting order or output format, but the purpose is sufficiently clear for a simple query tool. The GCP prerequisite adds useful context.
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?
The input schema has 100% coverage with clear descriptions. The description adds value by noting the GCP requirement for the provider parameter, which is not in the schema. This goes beyond the baseline for high schema 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?
The description clearly states the action ('Find the N most expensive individual resources'), the resource type (individual resources), and the scope (over a time period). It distinguishes itself from sibling tools like check_budgets or find_idle_resources by focusing on top spending.
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 implies usage for finding top spending resources but does not explicitly state when to use this tool versus alternatives. It mentions a GCP prerequisite but lacks direct comparisons to siblings like get_cost_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.3check_budgetscompare_periodsdetect_anomaliesfind_idle_resourcesfind_untagged_resourcesget_cost_by_tagget_cost_forecastget_cost_summaryget_cross_project_costsget_cross_subscription_costsget_current_datelist_projectslist_recommendationslist_subscriptionstop_spending_resourcesv0.3.1check_budgetscompare_periodsdetect_anomaliesget_cost_forecastget_cost_summaryget_current_datelist_recommendationstop_spending_resourcesv0.1.0check_budgetscompare_periodsdetect_anomaliesget_cost_forecastget_cost_summaryget_current_datelist_recommendationstop_spending_resourcesMost tools are clearly distinct by their focus (cost summary, tag breakdown, cross-project, anomalies, etc.). A minor potential confusion exists between get_cost_summary and get_cost_by_tag, but descriptions clarify the grouping dimension.
The majority of tools follow a verb_noun pattern (check_, compare_, detect_, find_, get_, list_). The exception is 'top_spending_resources' which uses a less standard verb form, but overall the pattern is consistent.
15 tools is well-scoped for a cloud cost management server, covering summary, breakdowns, forecasts, anomalies, optimization, and utilities without being overwhelming.
Core workflows are covered: cost review, forecast, anomalies, recommendations, and resource waste detection. Missing are write operations like budget creation or tagging, but the server appears read-only and covers its intended domain well.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for AWS cloud spend: service breakdowns, anomalies, savings and forecasts.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Cloudflare Workers MCP server: ai-cost-optimizer
FinOps MCP: query allocated, correlated cloud and AI cost across AWS, GCP, Azure and Snowflake.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexpota/cloudscope-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
