This server is an MCP bridge between Google Vertex AI and Alibaba Cloud DashScope, allowing local AI assistants to manage prompts, optimize them, and proxy to remote tools. Key capabilities:
Prompt CRUD: Create, read, update, delete, and list prompts on Vertex AI.
Prompt optimization: Run few-shot optimization (TARGET_RESPONSE or RUBRICS methods), configure and execute data-driven optimization via GCS, analyze results, and generate HTML reports.
Proxy: Call Alibaba Cloud DashScope MCP tools remotely.
Token usage: Get statistics on token usage.
Flexible connectivity: Supports stdio, SSE, streamable-http, hybrid protocols, and remote SSE proxy mode.
Provides integration with Google Vertex AI for prompt management (CRUD) and optimization (few-shot and data-driven).
这是一个全能型的 Model Context Protocol (MCP) 服务器，旨在连接 Google Vertex AI 的强大能力与您的本地 AI 助手。它不仅支持提示词管理与自动化优化，还集成了跨平台的工具代理（如阿里云 DashScope）。
官方 MCP 列表 (搜索 "Vertex AI Bridge")
详细部署指南 (Cloud Run) - 10 分钟内完成生产级部署。
Related MCP server: Xiaobai Print MCP
多传输协议支持:
stdio: 最适合 Cursor, VS Code 等本地 IDE。
sse: 标准 Server-Sent Events，适用于 Web 客户端。
streamable-http: (New) 更健壮的流式 HTTP 协议，适合云端长连接。
hybrid: (New) 同时启动多种协议，适配不同集成需求。
远程 SSE 代理模式: 即使您的本地工具（如 Cursor）不支持远程 SSE，您也可以通过 remote_sse 传输方式将云端服务透明地桥接到本地。
全方位提示词工程: 内置 Vertex AI Prompt Management 的 CRUD 及其最前沿的数据驱动优化工具。
跨云工具代理: 支持通过 call_dashscope_mcp 直接调用远程 DashScope 服务。
工具类别 | 工具名称 | 功能描述 |
Prompt CRUD |
| Vertex AI 提示词的全生命周期管理 |
Optimization |
| 少样本及数据驱动的提示词自动调优 |
Proxy |
| 代理调用远程 DashScope MCP 工具 |
直接运行我们提供的全自动部署脚本：
chmod +x deploy_cloud_run.sh
./deploy_cloud_run.sh如果您的客户端（如 Cursor）只支持本地 Stdio 命令行，但您希望使用云端部署好的服务：
python -m vertex.server --transport remote_sse --remote_sse_url https://YOUR-CLOUD-RUN-URL/sse{
"mcpServers": {
"vertex-bridge": {
"command": "/home/hzy9981/vertex-ai-mcp-bridge-local/.venv/bin/python3",
"args": ["-m", "vertex.server", "--transport", "stdio"],
"env": {
"GOOGLE_CLOUD_PROJECT": "your-project-id",
"DASHSCOPE_API_KEY": "your-key"
}
}
}
}Analyzes results and saves the detailed data to files.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | ||
| top_n_prompts | No | ||
| analysis_data_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions saving to files but doesn't disclose file format, overwrite behavior, required permissions, or side effects. With no annotations provided, the description carries full burden and fails to provide adequate transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It fails to front-load key information or organize details (e.g., input, output, behavior). Every word should earn its place; here, the sentence is too vague to be useful.
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 has 3 parameters, an output schema, and no annotations, the description is severely incomplete. It doesn't explain what analysis is performed, what files are saved, or how the output schema relates. The description adds minimal context beyond the tool name.
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 0%, and the description adds no parameter details. 'output_path' and 'analysis_data_path' are not explained, and 'top_n_prompts' is omitted entirely. For a 3-parameter tool with no schema descriptions, the description must compensate but does not.
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 states verb (analyze, save) and resource (results, data), but 'results' is vague and doesn't differentiate from sibling tools like generate_html_report. The name hints at data-driven optimization, but the description lacks specificity.
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 guidance on when to use this tool versus alternatives. Does not mention prerequisites or when not to use. Sibling tools like run_data_driven_optimize and generate_html_report suggest possible scenarios, but description gives no context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
调用 DashScope 的远程 MCP 服务并获取结果。
Args: tool_name: DashScope MCP 中的工具名称 arguments: 传递给工具的参数字典
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes | ||
| tool_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says it calls a remote service and gets results, without disclosing potential side effects, authentication needs, rate limits, or dependence on the called tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with purpose. It efficiently uses two sentences plus arg list. 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 it is a meta-tool calling other tools, the description lacks context about available tools, error handling, output details (though output schema exists), and prerequisites. Sibling tools are many specific ones, but no cross-reference provided.
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 0%. The description adds minimal meaning: 'tool_name' is the tool name, 'arguments' is the dict to pass. It does not clarify the source of valid tool names or constraints on arguments.
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 that the tool calls a remote MCP service and gets results, with arguments tool_name and arguments. It is a generic caller, distinct from the specific sibling tools, but does not explicitly differentiate itself.
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 guidance is given on when to use this tool versus the specific sibling tools (e.g., create_prompt, delete_prompt). The description merely explains what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a prompt with given content, system instruction, model and display name.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| content | Yes | ||
| project_id | No | ||
| location_id | No | ||
| display_name | Yes | ||
| system_instruction | Yes |
| Name | Required | Description |
|---|---|---|
| contents | Yes | The combined contents of the prompt. |
| promptId | Yes | The ID of the prompt. |
| displayName | Yes | The display name of the prompt. |
| systemInstruction | Yes | The system instruction for the prompt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks disclosure of side effects, required permissions, or behavior if a prompt with the same name exists. The description only states the basic creation action.
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, but it omits important details that would make it more useful, such as parameter descriptions or return value info.
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 6 parameters, no schema descriptions, no annotations, and an existing output schema (not detailed), the description is incomplete. It does not explain success behavior, errors, or idempotency.
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 0%, so the description should compensate. It only mentions 4 out of 6 parameters (missing project_id and location_id), and adds no extra meaning beyond the parameter names.
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 ('Create') and the resource ('prompt'), listing key parameters like content, system_instruction, model, and display_name. However, it does not differentiate the tool from siblings like update_prompt.
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 guidance on when to use this tool versus alternatives such as update_prompt or delete_prompt. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a prompt with given prompt_id.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | ||
| project_id | No | ||
| location_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Delete' implies destructive behavior, but there is no detail on irreversibility, required permissions, or side effects. The description is insufficient for a destructive action.
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 very brief (one sentence), which is concise but underspecified. While it is front-loaded, it lacks sufficient detail for a helpful description, falling into under-specification rather than true 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?
Given a 3-parameter tool with 0% schema coverage and no annotations, the description is incomplete. It does not explain optional parameters or their impact, leaving the agent uninformed about key usage details.
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 0%, yet the description only mentions 'prompt_id', ignoring 'project_id' and 'location_id'. It adds no meaning beyond the schema for these parameters, failing to compensate for the lack of schema descriptions.
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 ('Delete') and the resource ('prompt'), and explicitly identifies the required parameter ('prompt_id'). It effectively distinguishes from sibling tools like create_prompt, read_prompt, and update_prompt.
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 no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of consequences. It simply states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a comprehensive HTML report from Data-Driven Optimize analysis results.
| Name | Required | Description | Default |
|---|---|---|---|
| report_path | No | data_driven_optimize_analysis_report.html | |
| analysis_data | No | ||
| top_n_prompts | No | ||
| analysis_data_path | No | ||
| suggested_config_data | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks details on side effects (e.g., file creation), permissions, or output format. Fails to compensate for missing 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 is concise but under-specifies tool functionality. Front-loads purpose but omits critical details.
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 tool with 5 parameters and no output schema description, the description is too brief. Does not address input formats, optionality, or report content.
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 0%. Description does not explain any of the 5 parameters (report_path, analysis_data, top_n_prompts, etc.), adding no meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'generates' and resource 'HTML report', with source 'Data-Driven Optimize analysis results'. Distinguishes from siblings implicitly as they perform analysis or other operations.
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 guidance on when to use this tool versus alternatives like 'analyze_data_driven_optimize_results'. Context of 'after analysis' is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 MCP 服务的 token 使用统计信息。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. While 'get' implies a read-only operation, the description does not explicitly state that it is non-destructive or safe. For a zero-parameter retrieval, this is minimally acceptable.
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 with no redundant words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with no parameters and no output schema, the description covers the basic purpose. However, it does not specify the scope (e.g., time range, types of tokens) or return structure, which might be needed for precise 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?
There are no parameters (0 params), so the baseline is 4. The description adds no parameter information, but none is needed since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves token usage statistics of the MCP service, with a specific verb and resource. It is easily distinguished from sibling tools which focus on prompts, optimization, or reports.
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 guidance on when to use this tool versus alternatives. There is no mention of prerequisites or scenarios. The sibling list includes no similar 'get' tools, but usage context (e.g., before optimization) is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists Vertex prompts matching a given display name.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | ||
| project_id | No | ||
| location_id | No | ||
| display_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It implies a read-only operation but does not explicitly state that it is non-destructive, nor does it mention pagination, rate limits, or authentication requirements. The page_size parameter hints at pagination, but the description does not clarify return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it is too terse; it could include important context like pagination or parameter roles without becoming verbose. It is adequate but not excellent.
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 has four parameters, an output schema (not shown), and no annotations, the description is incomplete. It omits details about return format, pagination, error cases, and the roles of project_id and location_id. The output schema may cover return values, but the description still lacks needed 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?
Schema description coverage is 0%, so the description must compensate. It adds semantic value only for display_name, explaining it is used for filtering. However, it provides no explanation for page_size, project_id, or location_id, leaving their purpose unclear despite being declared in 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 action (lists) and resource (Vertex prompts), and specifies a filtering criterion (display name). This distinguishes it from siblings like create_prompt or read_prompt. However, it does not clarify what 'matching' means (e.g., exact or partial match), so it is not fully precise.
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 no guidance on when to use this tool versus alternatives. For example, if a specific prompt ID is known, read_prompt would be more appropriate, but this is not mentioned. There is no mention of when not to use it or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the prompt content with given prompt id.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | ||
| project_id | No | ||
| location_id | No |
| Name | Required | Description |
|---|---|---|
| contents | Yes | The combined contents of the prompt. |
| promptId | Yes | The ID of the prompt. |
| displayName | Yes | The display name of the prompt. |
| systemInstruction | Yes | The system instruction for the prompt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states 'get the prompt content', implying read-only, but no mention of side effects, permissions, or limitations. Minimal transparency.
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, no waste. However, it is too brief to be truly helpful—more detail would improve without damaging 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?
Despite having an output schema (signal true), the description omits any hint about return values. With 3 parameters (including optional ones), the description should provide usage context. Far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond field names. Parameters like project_id and location_id are not explained (e.g., whether they filter the prompt). Utterly insufficient for a 3-parameter tool.
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's function: 'Get the prompt content with given prompt id.' It uses a specific verb 'get' and resource 'prompt by id', distinguishing it from siblings like list_prompts, create_prompt, etc.
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 guidance on when to use this tool versus alternatives (e.g., list_prompts for listing, update_prompt for modifying). No context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Starts a data-driven prompt optimization job on Vertex AI.
This method uses a dataset and configurable metrics. The config_gcs_path
must point to a JSON file in Google Cloud Storage.
Args: config_gcs_path: The Google Cloud Storage URI (e.g., "gs://your-bucket/config.json") to a JSON file containing the Prompt Optimizer configuration. This is required. service_account: The service account email to run the job. This is required. prompt_optimizer_method: The method for prompt optimization. Either 'VAPO' or 'OPTIMIZATION_TARGET_GEMINI_NANO'. wait_for_completion: If True, the tool will block until the Vertex AI CustomJob completes. Defaults to False.
Returns: A string indicating the status and details of the optimization job, including a link to the Vertex AI console.
| Name | Required | Description | Default |
|---|---|---|---|
| config_gcs_path | Yes | ||
| service_account | Yes | ||
| wait_for_completion | No | ||
| prompt_optimizer_method | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool starts a job and can block if wait_for_completion is True. However, it does not mention destructive behavior (e.g., does it modify existing data?), authentication needs, rate limits, or side effects. The return value is described as a string with status and a console link, but no details on error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an introductory sentence, separate 'Args' and 'Returns' sections, and concise bullet-style explanations. It is not overly verbose, though the parameter descriptions could be slightly tightened (e.g., 'This is required' is redundant). The introductory sentence is front-loaded.
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 has 4 parameters, no annotations, and an output schema (content not provided), the description covers the inputs and return string adequately. However, it lacks information on error handling, prerequisites (e.g., having the config JSON file properly formatted), or consequences of failures. For a tool that kicks off a long-running job, more context would be beneficial.
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 0%, so the description must fully compensate. It does so by providing clear, detailed explanations for each parameter: config_gcs_path is a GCS URI to a JSON file, service_account is an email, wait_for_completion defaults to False, and prompt_optimizer_method accepts specific enum values. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it starts a data-driven prompt optimization job on Vertex AI using a dataset and configurable metrics. It names the specific resource (Vertex AI CustomJob). However, it does not explicitly differentiate from sibling tools like 'run_few_shot_optimization' or 'analyze_data_driven_optimize_results'.
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 guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites, such as the need to have a config file prepared or what types of optimization problems are suited for this tool. Sibling tools exist but are not referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Applies few shot prompt optimization to a prompt using user provided dataset and method.
Args: prompt_to_optimize: The zero-based index of the prompt to improve. example_path: GCS path to the csv file containg few-shot examples method: The optimization method to use for few shot prompt improvement. The method should be one of the following: - TARGET_RESPONSE: Optimize the prompt to match the target response. - RUBRICS: Optimize the prompt to improve the rubrics scores.
Returns: Optimized prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | ||
| example_path | Yes | ||
| prompt_to_optimize | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It describes that the tool 'applies' optimization and 'returns optimized prompt', but it does not state whether the original prompt is modified, what permissions are required, or any side effects. This lack of detail is insufficient for safe invocation.
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, fitting in a short paragraph with clear parameter details. However, the 'Args:' section is redundant given the schema, but it serves as the only documentation due to 0% schema coverage. It is efficient but could be slightly more 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?
Given that an output schema exists (though not detailed here), and the parameters are simple, the description covers the essential inputs and output. However, it lacks behavioral context like side effects, permissions, or expected behavior when optimization fails. For a tool with no annotations, this is a notable gap.
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 0%, the description provides all parameter meaning. It explains that prompt_to_optimize is a zero-based index, example_path is a GCS path to CSV, and method is an enum with two options (TARGET_RESPONSE, RUBRICS) and their purposes. This adds critical value beyond the schema, which only has titles.
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: 'Applies few shot prompt optimization to a prompt using user provided dataset and method.' It specifies the verb 'applies', the resource 'few shot prompt optimization', and the inputs. This distinguishes it from sibling tools like run_data_driven_optimize by explicitly naming 'few shot'.
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 no explicit guidance on when to use this tool versus alternatives such as run_data_driven_optimize or other siblings. It mentions method options (TARGET_RESPONSE, RUBRICS) but does not explain when each method is appropriate. The agent is left to infer usage context from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a prompt with given prompt_id and new content, system instruction, model, and display name.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| content | No | ||
| prompt_id | Yes | ||
| project_id | No | ||
| location_id | No | ||
| display_name | No | ||
| system_instruction | No |
| Name | Required | Description |
|---|---|---|
| contents | Yes | The combined contents of the prompt. |
| promptId | Yes | The ID of the prompt. |
| displayName | Yes | The display name of the prompt. |
| systemInstruction | Yes | The system instruction for the prompt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It states 'Update' implying mutation, but fails to disclose behavior on non-existent prompt_id, whether updates are partial or full, idempotency, or any side effects.
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 with no fluff, achieving conciseness. However, it omits some parameters, so it is not both concise and complete. Could benefit from listing all optional fields.
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 having an output schema (unseen), the description is incomplete: it covers only 4 of 7 parameters, offers no usage context, and lacks behavioral details. Given the tool's complexity (7 params, no annotations), more information is 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 0%. Description adds meaning for only 4 of 7 parameters (content, system instruction, model, display name) by labeling them as 'new', but omits project_id and location_id entirely. Does not explain format, constraints, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Update' and resource 'a prompt', listing several updatable fields (content, system instruction, model, display name). It distinguishes from sibling tools like create_prompt and delete_prompt. However, it omits optional parameters project_id and location_id, which could cause confusion.
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 guidance on when to use this tool vs alternatives. Does not mention prerequisites (e.g., prompt must exist) or that it modifies an existing prompt rather than creating a new one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Constructs a JSON configuration for Data-Driven Optimize and uploads it to GCS.
This tool generates a JSON configuration file based on the provided parameters and uploads it to the specified Google Cloud Storage URI. This configuration file is required to run data-driven prompt optimization.
Args:
gcs_config_uri: The GCS URI where the generated VAPO config JSON file will
be saved (e.g., 'gs://my-bucket/vapo/config.json').
prompt_optimizer_method: The method for prompt optimization. Either
'VAPO' or 'OPTIMIZATION_TARGET_GEMINI_NANO'.
target_model_endpoint_url: The custom endpoint URL for the target model.
Required for Gemini Nano target.
base_config: Optional. A dictionary representing the base configuration.
modifications: Optional. A dictionary representing the modifications to
apply to the base config.
base_config_path: Optional. Path to a base config file. If provided and
base_config is None, this config will be loaded.
Returns: A string containing a success message and details about the uploaded configuration file, including a link to the Vertex AI console.
| Name | Required | Description | Default |
|---|---|---|---|
| base_config | No | ||
| modifications | No | ||
| gcs_config_uri | Yes | ||
| base_config_path | No | ||
| prompt_optimizer_method | Yes | ||
| target_model_endpoint_url | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool generates JSON and uploads to GCS, and mentions the return value. With no annotations, it provides moderate behavioral context but lacks details on side effects like overwriting, permissions, 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?
The description is somewhat verbose with a docstring format including Args and Returns. It is front-loaded with the main action but could be more concise.
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 annotations and an output schema (though not shown), the description adequately explains the tool's actions, parameters, and return value. It covers the essentials for a config-generation 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 description coverage is 0%, but the description includes a detailed docstring explaining each parameter (gcs_config_uri, prompt_optimizer_method, etc.). This adds significant meaning beyond the schema's titles.
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 constructs a JSON configuration for Data-Driven Optimize and uploads it to GCS. It distinguishes itself from siblings like run_data_driven_optimize and analyze_data_driven_optimize_results by focusing on config generation.
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 does not specify when to use this tool versus alternatives, nor does it explain prerequisites or that this must precede run_data_driven_optimize. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_data_driven_optimize_resultscall_dashscope_mcpcreate_promptdelete_promptgenerate_html_reportget_token_usage_statslist_promptsread_promptrun_data_driven_optimizerun_few_shot_optimizationupdate_promptwrite_data_driven_optimize_configScored across 12 tools
Most tools have distinct purposes: prompt CRUD, data-driven optimization workflow, and few-shot optimization. However, 'call_dashscope_mcp' is a generic MCP caller that overlaps with the optimization tools' intent, and 'get_token_usage_stats' is unrelated, causing minor ambiguity.
Prompt tools follow a consistent CRUD pattern (create/delete/list/read/update_prompt). Optimization tools mix styles: 'run_data_driven_optimize' and 'run_few_shot_optimization' are consistent, but 'analyze_data_driven_optimize_results', 'write_data_driven_optimize_config', and 'generate_html_report' are long and vary in structure. 'call_dashscope_mcp' uses a different verb_noun pattern.
With 12 tools, the set covers two main domains (prompt management and prompt optimization) without being overwhelming. Each tool contributes to a clear workflow, and the count is appropriate for the scope.
Prompt management has full CRUD coverage. The optimization workflow includes setup, execution, analysis, and report generation. Missing features like job cancellation or monitoring are covered by links to the Vertex AI console. The addition of generic utilities ('call_dashscope_mcp', 'get_token_usage_stats') does not detract from domain completeness.
MCP-Native LLM Orchestration Agent
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for Google Veo AI video generation
LLM Orchestration Agent (Mcp)