{"slug": "building-an-agentic-finops-platform-development-environment-setup-google-mcps", "title": "Building an Agentic FinOps Platform — Development Environment Setup, Google Antigravity, MCPs and Skills, and ADK Bootstrapping with Agents CLI", "summary": "A developer building the FinSavant FinOps platform on Google ADK shares a detailed guide for setting up an agentic development environment using Google's Antigravity IDE. The post covers environment configuration, MCPs, skills, and ADK bootstrapping with the Agents CLI, offering practical tips for building agentic solutions in the Google ecosystem.", "body_md": "**TL;DR — This article is going to be jam-packed with useful information, tips, tricks and hacks for setting up an agentic development in the Google ecosystem.**\n\nThis one isn’t really about the FinOps!\n\nWelcome back, friends!\n\nIn the [first part](https://dev.to/google-cloud/finsavant-part-1-building-an-agentic-finops-platform-with-google-adk-a2ui-and-gemini-enterprise-248f59cea3a0), I described the purpose of the [FinSavant](https://github.com/derailed-dash/smart-gcp-finops) FinOps solution, the motivation for creating it, its overall architecture and tech stack, and how it works.\n\nIn this part, we’ll use *FinSavant* as a case study in **how to set up a development environment** for the purposes of building such an ADK-based agentic solution. **Even if you’re not particularly interested in FinSavant itself, I hope you’ll find a bunch of useful information and tips here that will help you build your own agentic solutions more effectively and quickly.**\n\nWe’ll cover:\n\n`GEMINI.md`\n\n(or if you prefer, `AGENTS.md`\n\n)`Makefile`\n\nSound good? Let’s get cracking!\n\nLet’s see where we are in this series.\n\nThese days, my favourite coding environment *for any significant project* is Antigravity IDE. This is Google’s *agent-first* integrated development environment. You get a look-and-feel that’s familiar to VS Code users, but powered with autonomous, context-aware agents that can plan, execute, verify, and work in parallel.\n\nYou can get it [here](https://antigravity.google/product/antigravity-ide?utm_campaign=DEVECO_GDEMembers&utm_source=deveco).\n\nBy the way, Antigravity IDE is just one member of the Antigravity (aka Agy) suite.\n\nI’ve covered these before, but here’s a quick reminder of the four Agy solutions in the suite:\n\n`google.antigravity`\n\nwe can programmatically leverage Antigravity’s capabilities.Here’s the rough outline of the project structure we’ll be creating. We won’t be building all of this structure here; nor does this represent the final state of the project. But it gives you an idea of where we’re heading. (I’ll explain the `*`\n\nin a minute!)\n\n```\n  smart-gcp-finops/  \n  ├── agent/                # ADK agent package  \n  │   ├── finops_agent/     # Root agent  \n  │   ├── .env              # Agent specific environment vars  \n  │   ├── Dockerfile        # For deploying agent to Agent Runtime  \n  │   └── pyproject.toml    # Agent runtime dependencies  \n* ├── bff/                # Backend-for-Frontend (API)  \n* ├── deployment/         # Infrastructure & CI/CD (Terraform IaC)  \n* │   ├── terraform/      # Centralised IaC for Prod & Staging  \n  │   └── README.md         # Deployment documentation  \n* ├── docs/               # Project documentation  \n* │   ├── images/         # Diagrams and architectural visual assets  \n  │   ├── DESIGN.md         # Visual identity, components, and UI design  \n  │   ├── architecture-and-walkthrough.md # Solution blueprints, ADRs, and component data flows  \n  │   └── testing.md        # Testing strategy and verification instructions  \n* ├── frontend/           # React UI frontend  \n* ├── notebooks/          # Jupyter notebooks for prototyping and evaluation  \n* ├── scripts/            # Environment setup and other utility scripts  \n  │   └── setup-env.sh      # Configure local environment including Google auth / ADC  \n* ├── tests/              # Unit and integration test suites  \n* │   ├── eval/           # Agent evaluation  \n* │   ├── unit/           # Unit tests  \n* │   └── integration/    # Integration tests  \n* ├── .agents/            # Workspace customizations root  \n  │   └── mcp_config.json   # E.g. MCP servers  \n* ├── .github/            # GitHub Actions workflows and CI/CD  \n* ├── .env                # Root environment vars (dev setup, unified container, GitHub, etc)  \n  ├── .envrc                # Automatically launch when entering this directory  \n* ├── .gitignore          # Exclude from git  \n* ├── Makefile            # Centralised developer convenience commands  \n* ├── GEMINI.md           # Development agent context & guidelines  \n* ├── LICENSE             # Standard open-source license file  \n* ├── pyproject.toml      # Root project configuration / dependencies  \n* ├── README.md           # Developer documentation homepage  \n  └── TODO.md               # TODO list\n```\n\nIf you wanted to build such a structure from scratch, here’s a cool thing to try…\n\n`my-cool-project`\n\n```\n/grill-me Using this folder tree as a template, \ncreate the required folder structure in this workspace for my new Python \nproject. Only create folders and files that are marked as '*'. \nFor required files, provide initial starter-for-10 content. \n<< paste the tree structure here >>\n```\n\nWhy `/grill-me`\n\n? This is a built-in Agy command that causes the agent to ask questions to remove ambiguity. If you were to give the agent a slightly vague prompt without this prefix, then the agent might make some guesses about what you want. But with `/grill-me`\n\n, the agent will still make educated guesses, but it will also ask you questions to clarify your intent.\n\nThe prompt above is a good example of where this is useful. You’ll notice that my project tree has a `LICENSE.md`\n\nfile, which is a standard component to include in open-source projects. But my prompt doesn't specify which license to use. So when you use `/grill-me`\n\n, the agent will offer sensible license choices based on your project and context, and ask you to confirm.\n\nThis video demonstrates Agy scaffolding the entire project from scratch, in response to the prompt above:\n\nGive it a go!\n\nI like to describe skills as **units of knowledge that agents load on-demand**, when they need to do a particular task. I’ve previously written articles on the subject of my favourite skills, where to find them, and how to install them. I recommend you check out [this one](https://dev.to/google-cloud/dialling-our-agents-to-11-agent-skills-you-need-to-be-using-ccffa51e91df). You might want to go ahead and install all of my favourites!\n\nBut for now, let’s add a few skills that will definitely be useful for our current project. I recommend installing them globally, so they’ll be available to all of your development projects.\n\n```\nnpx skills add https://github.com/vercel-labs/skills -y -g --skill find-skills  \nnpx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g  \nnpx skills add https://github.com/google/skills -y -g  \nnpx skills add https://github.com/google-gemini/gemini-skills/ -y -g  \nnpx skills add https://github.com/shubhamsaboo/awesome-llm-apps/awesome-agent-skills -y -g --skill technical-writer\n```\n\nWe’re also going to install the *Google Agents CLI* and its associated skills, but we’ll get to that later.\n\n`GEMINI.md`\n\n- Context for Your Coding Agent\nThe `GEMINI.md`\n\nfile (or `AGENTS.md`\n\nif you prefer) is how you define your project's rules and context. It's where you tell the Agy Agent:\n\nWhen we create `GEMINI.md`\n\nin the root of a project then the file is scoped only to *that project*. (This project-specific context gets appended to any global `GEMINI.md`\n\nyou have defined.) When you launch any Antigravity tool from this workspace - such as Agy 2.0, Agy IDE, or Agy CLI - the Agent will automatically read this context.\n\nLet me show you what my `GEMINI.md`\n\nlooked like, when starting out with *FinSavant*:\n\n```\n# FinSavant - the Agentic FinOps Solution  \n\n## Project Goals  \n\nTo create an agentic FinOps solution for GCP that:  \n- Uses ADK for agent orchestration.  \n- Is able to examine billing and cost data in BigQuery, based on billing   \n  exports.  \n- Is able to understand Google Cloud infrastructure and services across   \n  multiple Google projects associated with a billing account.  \n- Considers projects associated with a particular Google Cloud organisation,    \n  associated with a billing account.  \n- Leverages Google Developer Knowledge API MCP for grounding:   \n  Google APIs, Google Cloud infrastructure, Google Cloud best practices.  \n- Is able to detect cost anomalies and inefficiencies, and trends.  \n- Is able to understand all deployed infra and services, and historical   \n  configuration changes, leveraging Google Cloud Asset Inventory  \n- Is able to invoke Google Cloud Assist for immediate logs investigation,   \n  RCA and recommendations.  \n- Is able to combine all of the above to provide actionable insights and   \n  recommendations to users.  \n- Provides a UI for users, which includes:  \n  - Dashboard of cost trends, billing data and anomalies  \n  - Cost forecasting  \n  - Cost analysis  \n  - Anomaly detection  \n  - Recommendations  \n  - Cost optimisation suggestions  \n  - A natural language chat interface  \n- The UI should be based on React. Use skills you have available to leverage   \n  React best practices.  \n- Leverage Google Stitch to design the UI, and use the Stitch MCP server to   \n  pull in the design, in order to convert to React.  \n- The UI is connected to the agent via FastAPI.  \n- The UI and API will be hosted in a single Cloud Run service. The service   \n  will be secured using IAP, using direct Cloud Run integration - no   \n  Load Balancer.  \n- The Agent will be deployed to Agent Runtime in Gemini Enterprise Agent   \n  Platform.  \n\n## Tool Use: Skills, Gemini Enterprise Agent Platform, Agent Runtime and ADK  \n\nBe sure to use all **agents** skills, **Gemini Enterprise Agent Platform**   \nskills, and **ADK** skills you have available for developing ADK agents and   \nbest practices, and use **adk-docs-mcp** for latest ADK documentation.   \n\nYou will have additional skills available to you, but always check if the   \nfollowing can help with a particular task.  \n\n### ADK & agents-cli Lifecycle Skills  \n\n- `google-agents-cli-workflow`: Entrypoint for building ADK agents (scaffold,   \nbuild, evaluate, deploy, publish, observe).  \n[skipping for brevity]  \n\n### Gemini Enterprise Agent Platform APIs  \n- `gemini-api`: Gemini Enterprise Agent Platform, Google Cloud, and   \nAgent Platform enterprise usage with the Google Gen AI SDK.  \n[skipping for brevity]  \n\n### Agent Platform Engine & Model Management  \n- `agent-platform-deploy`: Deploying models and tuned weights to Agent   \n  Platform endpoints.  \n[skipping for brevity]  \n\n## Key Internal Documentation  \n\n- README.md - Project README; the developer's front door  \n- TODO.md - High level plan for the project  \n- architecture-and-walkthrough.md - The main architecture, including design   \n  decisions  \n- DESIGN.md - Where we will capture the UI design  \n- testing.md - Where we will document test strategy, summary of tests,   \n  testing instructions, any manual testing processes  \n- docs/blog.md - A blog post document we will build along the way  \n- /deployment/README.md - Deployment and CI/CD documentation  \n\n## Essential Reading  \n\nYou should read and leverage these resources for guidance and best practices,   \nin addition to the skills and MCP servers you have available for knowledge.  \n\n| Resource | Description and Relevance |  \n| -------- | ------------------------- |  \n| https://docs.cloud.google.com/bigquery/docs/use-bigquery-mcp?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | Use the BigQuery MCP server |   \n| https://adk.dev/integrations/bigquery/?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | BigQuery tool for ADK |  \n| https://docs.cloud.google.com/gemini-enterprise-agent-platform?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | Gemini Enterprise Agent Platform Overview |  \n| https://adk.dev/deploy/agent-runtime?utm_campaign=DEVECO_GDEMembers&utm_source=deveco | ADK with Agent Runtime |  \n[skipping for brevity]  \n\n## Other Notes  \n\n- \"Vertex AI\" no longer exists as a product; the replacement is Gemini   \n  Enterprise Agent Platform.  \n- \"Vertex AI Agent Engine\" is no more; the replacement is \"Agent Runtime\",   \n  which is a part of the Gemini Enterprise Agent Platform.  \n- But APIs and Google internal resource names may still refer to legacy names,   \n  e.g. `reasoningEngine` rather than Agent Runtime. Always use the new names   \n  when creating documentation, but be mindful that we may need to use old   \n  names in API calls and certain resource definitions.  \n\n## Blog  \n\nI want to build a multi-part blog series, which I'll post on Medium and Dev.to.  \n\n### Documenting As We Go  \n\nAs we go, document steps taken, experience and findings in docs/blog.md.   \nLater, I will build a Medium blog from this content. During this \"as we go\"   \nphase, the blog.md does not need to be a collection of notes, code snippets, and observations. It should:  \n\n- Include all the key steps we did, in the order we did them.  \n[skipping for brevity]\n```\n\nIf you’re following along and you’ve just created your context file, give Agy a restart now, so it picks this up.\n\nI’m a big fan of having a consistent set of high-quality, continuously maintained documentation. I even have my own agent skill — `maintaining-core-documentation`\n\n- to automate much of this for me. Check out my previous blog on this subject: [Documentation as Context: A Skill to Automate Your Blueprints for the Agentic Era](https://dev.to/google-cloud/documentation-as-context-a-skill-to-automate-your-blueprints-for-the-agentic-era-2bec0cf041a3).\n\nIf you previously ran the `npx skills add https://github.com/derailed-dash/dazbo-agent-skills -y -g`\n\ncommand from above, then you already have this skill installed.\n\nWith this in place, you could issue this prompt to bootstrap a set of documentation for a brand-new project:\n\n```\nUse maintaining-core-documentation to bootstrap my project documentation.\n```\n\nCheck out this video to see the skill doing its magic!\n\nAs you evolve your project, this skill will automatically maintain your documentation.\n\nI’ve previously written about [some of my favourite MCP servers](https://dev.to/google-cloud/dialling-our-agents-to-11-my-favourite-mcp-servers-9549c1442a5e). There are only a couple that we’ll need for this project:\n\nNote that we won’t be using either of these in the *FinSavant* agent itself. These are purely to help us during development.\n\nLet’s try out the BigQuery MCP server first. In your workspace’s `.agents/mcp_config.json`\n\nfile, we configure the **Remote BigQuery MCP server** like this:\n\n```\n{  \n  \"mcpServers\": {  \n    \"bigquery-mcp-server\": {  \n      \"serverUrl\": \"https://bigquery.googleapis.com/mcp\",  \n      \"authProviderType\": \"google_credentials\",  \n      \"oauth\": {  \n        \"scopes\": [  \n          \"https://www.googleapis.com/auth/bigquery\"  \n        ]  \n      },  \n      \"headers\": {  \n        \"x-goog-user-project\": \"your-gcp-billing-project\"  \n      }  \n    }  \n  }  \n}\n```\n\nA few things to note about this:\n\n`your-gcp-billing-project`\n\nwith the Google project where your billing data export lives.`bigquery.googleapis.com`\n\n) is enabled on that project.`google_credentials`\n\nto authenticate, your local developer account (active in `gcloud auth`\n\n) must be authorised on Google Cloud. You need the `roles/bigquery.dataViewer`\n\nand `roles/bigquery.jobUser`\n\nroles on the project hosting the billing dataset.`roles/mcp.toolUser`\n\nrole, in order to use this managed MCP server to query the BigQuery database.And now, when you open the workspace in Antigravity IDE, it will load this configuration automatically. Your coding agent will be able to query schemas, inspect tables, and try out SQL queries in order to assist you when you actually create the *FinSavant* agent code.\n\nLet’s test it!\n\nFirst, I issue this prompt to the Agy agent:\n\n```\nWhat billing tables do I have? Explain their key functions.\n```\n\nYou can see the agent immediately finds the MCP server and asks for permission to invoke its tools. After I grant permission, I get this response:\n\nNice! You can see how helpful this is going to be.\n\nThe easiest way to scaffold a new ADK agent is to make use of **Google Agents CLI**. The Agents CLI is actually a bundle, containing:\n\nYou install the bundle using this one-time command:\n\n```\nuvx google-agents-cli setup\n```\n\nIf you already have it installed, then you can upgrade like this:\n\n```\nuv tool upgrade google-agents-cli\n```\n\n(It’s worth doing this occasionally — this CLI is evolving quickly!)\n\nWith this installed, we *could* create our top level `agent`\n\nfolder that contains a root agent called `finops_agent`\n\nby running this command:\n\n```\nagents-cli scaffold create agent \\\n  --agent adk \\\n  --prototype \\\n  --agent-directory finops_agent\n```\n\nYou’ll end up with the following inside of your workspace folder:\n\n```\nagent/  \n├── finops_agent/                 # Your agent code  \n│   ├── __init__.py               # Registers the app (exports `app`)  \n│   ├── agent.py                  # Agent definition — instructions, model, tools  \n│   └── app_utils/                # Utilities (telemetry, converters)  \n│       ├── __init__.py  \n│       ├── telemetry.py          # OpenTelemetry setup for Cloud Trace  \n│       ├── typing.py             # Request/response Pydantic models  \n│       └── gcs.py                # GCS utility functions  \n│  \n├── tests/  \n│   ├── eval/                     # Evaluation test cases  \n│   │   ├── datasets/  \n│   │   │   └── basic-dataset.json    # Default eval cases  \n│   │   └── eval_config.yaml          # Evaluation metrics configuration  \n│   ├── integration/  \n│   │   └── test_agent.py         # Integration test (runs agent end-to-end)  \n│   └── unit/  \n│       └── test_dummy.py         # Placeholder for unit tests  \n│  \n├── .env                          # Environment variables (project ID, location)  \n├── .env.example                  # Example environment variables  \n├── .gitignore                    # Git ignore file  \n├── pyproject.toml                # Project config and dependencies  \n├── agents-cli-manifest.yaml      # Configuration for agents-cli  \n├── Dockerfile                    # Dockerfile for the agent runtime  \n└── GEMINI.md                     # Guidance file for coding agents\n```\n\nBut since we now have the skills installed, there’s an easier way to accomplish this, that doesn’t require you to check the CLI documentation…\n\n```\nPlease bootstrap a new ADK agent project. The agent top-level project should   \nbe named `agent`, and it should contain a root `agent-directory` called   \n`finops_agent`, NOT the default of `app`. This means `pyproject.toml` and   \nother config files will live under `agent/`, and all Python source files   \n(like `agent.py` and `fast_api_app.py`) will live inside   \n`agent/finops_agent/`.\n```\n\nSure, this prompt is quite detailed, but I’m after a very specific folder structure.\n\nLet’s see a live demo…\n\nAs you can see from the demo, we can now use `agents-cli`\n\nto check if our newly scaffolded agent is working.\n\nFor example, by issuing a single test prompt on the command line:\n\n```\ncd agent  \nagents-cli run \"Hello! Who are you?\"\n```\n\nOr, we could run up the extremely powerful and useful **ADK Web** interface, using this handy shortcut:\n\n```\n# From the agent folder\nagents-cli playground\n```\n\nConcluding thought about `Agents-CLI`\n\n: if you know your way around the CLI, you can use it directly. It'll be faster and use fewer tokens. But when you're doing lots of agent related activities like boostrapping, adding CI/CD, deploying and evaluating, you'll probably find that natural language conversations are going to save you a lot of time and pain.\n\nIn a “monorepo” project setup like *FinSavant*, you quickly end up managing a lot of moving parts: building frontend assets, compiling Python environments, building and running multiple Docker images, executing test suites, and deploying resources to various target environments.\n\nRather than forcing yourself (or your team) to remember a massive list of commands and flags, wrapping them in a `Makefile`\n\nis a big win.\n\nBut what actually is a `Makefile`\n\n? At its core, it is a configuration file used by the classic `make`\n\nbuild automation tool. These days it has evolved into a lightweight, standardised task runner. It allows us to define short aliases (known as \"targets\") for complex shell commands, documenting project workflows in a single, standard file that is easy for both humans and agents to discover.\n\nEarlier, during the demonstration of bootstrapping the project, the agent actually created an initial `Makefile`\n\nfor us. If you followed along, you'll now have a `Makefile`\n\nthat looks something like this:\n\n```\n.PHONY: install lint format lint-fix test  \n\ninstall:  \n    @command -v uv >/dev/null 2>&1 || { echo \"uv is not installed. Installing uv...\"; curl -LsSf https://astral.sh/uv/0.11.16/install.sh | sh; source $HOME/.local/bin/env; }  \n    uv sync  \n\nlint:  \n    uvx codespell@latest -s  \n    uvx ruff@latest check .  \n\nlint-fix:  \n    uvx codespell@latest -w  \n    uvx ruff@latest check --fix .  \n\ntest:  \n    uv run pytest tests/\n```\n\nNow you can run any of these `make`\n\n*targets*, like this:\n\n```\nmake install\n```\n\nWith this in place, we can build on it in future articles as we develop the *FinSavant* solution.\n\nThese days, whenever I’m working on a project that makes use of Google services, I always create a helper `setup-env`\n\nscript to configure my environment for me.\n\nThis script:\n\n`.env`\n\ndirectly into the current shell session.`--noauth`\n\nflag), it runs `gcloud auth login --update-adc`\n\nto authenticate the user and configure Google Application Default Credentials (ADC).`gcloud`\n\ndefaults for the target project and billing quota project settings.`uv sync`\n\nto ensure all standard, development, and notebook dependencies are installed in the local environment.`.venv`\n\n) so the user is immediately ready to run code.You can find a copy of this `scripts/setup-env.sh`\n\nin my [GitHub repository](https://github.com/derailed-dash/smart-gcp-finops/blob/main/scripts/setup-env.sh). Because it uses standard environment variables defined in your `.env`\n\n, you can use it in any of your Google projects!\n\nYou run it from the project root directory like this:\n\n```\nsource scripts/setup-env.sh\n```\n\n`direnv`\n\nand `.envrc`\n\nIf you haven’t come across this before, I think you’re going to like it!\n\nManually sourcing the `setup-env.sh`\n\nscript every time I open a terminal in the project directory is a bit of a chore. To automate this, we can use `direnv`\n\n— an extension for your shell that automatically runs custom scripts and loads / unloads environment variables depending on your current directory.\n\nBy placing a `.envrc`\n\nfile at the root of the project, `direnv`\n\nautomatically executes it whenever you `cd`\n\ninto the directory.\n\nHere is what our `.envrc`\n\nlooks like:\n\n```\nif [ ! -d \".venv\" ]; then  \n  uv venv  \nfi  \n\n# Check if gcloud token is still valid to avoid re-authenticating  \nif gcloud auth print-access-token --quiet > /dev/null 2>&1; then  \n  echo \"gcloud token is valid, skipping authentication.\"  \n  source scripts/setup-env.sh --noauth  \nelse  \n  echo \"gcloud token is not valid, re-authenticating.\"  \n  source scripts/setup-env.sh  \nfi\n```\n\nThis configuration does a few smart things:\n\n`uv venv`\n\nif it doesn't already exist.`gcloud auth print-access-token`\n\nsilently to check if our Google Cloud session is active.`--noauth`\n\nflag, avoiding repetitive and annoying browser login prompts. If the session has expired, it triggers the full setup script to re-authenticate.There are a couple of one-off steps we have to do to get `direnv`\n\nup and running:\n\n`direnv`\n\n. On Debian/Ubuntu systems, this is `sudo apt install direnv`\n\n.`direnv`\n\n. Run `direnv allow`\n\nin the terminal, in the project folder where we've placed our `.envrc`\n\nfile.Now, when we enter our project folder, the script runs automatically, like this:\n\nPretty neat, right?\n\nOkay, we’re done with the environment setup. We’ve:\n\n`/grill-me`\n\n`agents-cli`\n\nand its skills`Makefile`\n\nfor standardising common development, testing and deployment tasks`scripts/setup-env.sh`\n\nscript for setting up our Google Cloud environment`direnv`\n\nand a `.envrc`\n\nfile to automate the setup process, every time we open a terminal in this directoryIn the next part, we’ll look at the actual code for our *FinSavant* agents and tools!\n\nSee you there!", "url": "https://wpnews.pro/news/building-an-agentic-finops-platform-development-environment-setup-google-mcps", "canonical_source": "https://dev.to/gde/building-an-agentic-finops-platform-development-environment-setup-google-antigravity-mcps-and-4c43", "published_at": "2026-07-13 15:31:20+00:00", "updated_at": "2026-07-13 15:45:39.875109+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure", "ai-tools", "mlops"], "entities": ["Google", "Antigravity IDE", "FinSavant", "ADK", "Gemini", "Agents CLI", "derailed-dash"], "alternates": {"html": "https://wpnews.pro/news/building-an-agentic-finops-platform-development-environment-setup-google-mcps", "markdown": "https://wpnews.pro/news/building-an-agentic-finops-platform-development-environment-setup-google-mcps.md", "text": "https://wpnews.pro/news/building-an-agentic-finops-platform-development-environment-setup-google-mcps.txt", "jsonld": "https://wpnews.pro/news/building-an-agentic-finops-platform-development-environment-setup-google-mcps.jsonld"}}