free forever
Scored across 14 tools
Tools are mostly distinct: prompt CRUD, text generation, and optimization stages separate clearly. However, the data-driven optimize suite has several related tools, and run_data_driven_optimize vs run_few_shot_optimization could be confused without reading descriptions.
All names use snake_case and mostly follow a verb_noun pattern, with readable variants like generate_with_vertex. Minor inconsistency appears in optimization names (run_data_driven_optimize vs run_few_shot_optimization, optimize vs optimization).
14 tools is well within the 3-15 range and appropriately covers prompt CRUD, generation, optimization, reporting, and usage stats. Each tool maps to a distinct operation without excessive proliferation.
Prompt CRUD lifecycle is complete (create, list, read, update, delete), and the optimization pipeline includes config creation, job running, analysis, and reporting. Minor gaps exist for job management/cancellation or prompt versioning.
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 present, so the description must fully disclose behavior. It only mentions calling a remote service and getting results, omitting details about side effects, idempotency, error handling, or required permissions.
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 short and to the point, with no redundant information. However, it is too brief to be fully useful, so it scores average.
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 presence of an output schema and nested objects, the description is incomplete. It does not explain return value structure, error cases, or how to structure the arguments parameter.
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?
With 0% schema description coverage, the description must explain parameters. It merely names 'tool_name' and 'arguments' without describing valid values, format, or usage of the nested object, adding minimal 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 the tool calls DashScope's remote MCP service and retrieves results. It lists the required parameters, but lacks specificity about the nature of the service, making it less precise than a 5.
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 (e.g., sibling tools for prompts). There is no mention of prerequisites, context, or exclusions.
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.
使用 DeepSeek API 生成文本 (需要 DEEPSEEK_API_KEY)。
Args:
prompt: 用户提示词
model: deepseek-flash 或 deepseek-v4-pro
temperature: 生成多样性
max_tokens: 最大输出 token 数
top_p: Top-P 采样参数
system_instruction: 系统指令
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | deepseek-flash | |
| top_p | No | ||
| prompt | Yes | ||
| max_tokens | No | ||
| temperature | No | ||
| system_instruction | No |
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 does disclose a genuine behavioral prerequisite (DEEPSEEK_API_KEY) and implies a text return, but says nothing about cost, rate limits, latency, error behavior, or failure modes for what is an external API call.
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 purpose is correctly front-loaded in the first line, but the Args block is largely a restatement of parameter names with minimal added meaning, spending space without earning much.
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 6-parameter external-generation tool with no output schema and no annotations, the description covers the inputs at a basic level and flags the API-key requirement. It omits the return shape/format and any operational constraints, leaving an agent without enough to predict call 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 0%, so the description must compensate and it lists all six parameters. The explanations are thin (mostly restating names, e.g. 'temperature: 生成多样性'), but the model line adds real information not in the schema by naming the valid options 'deepseek-flash 或 deepseek-v4-pro' (no enum exists 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 first line states a specific verb+resource ('使用 DeepSeek API 生成文本'), which is clear and, via the provider name, implicitly distinguishes it from siblings like generate_with_vertex and call_dashscope_mcp. It does not explicitly state when to prefer this provider over those siblings, keeping it short of a 5.
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 only contextual guidance is the parenthetical requirement of DEEPSEEK_API_KEY. There is no when-to-use, when-not-to-use, or comparison against the many sibling generation/optimization tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 Vertex AI Gemini 模型生成文本。
Args:
prompt: 用户提示词
model: gemini-2.5-flash (默认), gemini-2.5-pro 或 gemini-2.5-flash-lite；其他名称会交由 Vertex 校验
temperature: 生成多样性
max_tokens: 最大输出 token 数。注意：Gemini 2.5 的 "thinking" token 也计入此上限，
过小的值（如 512）可能截断可见回答，建议 1024 以上
top_p: Top-P 采样参数
top_k: Top-K 采样参数
system_instruction: 系统指令
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | gemini-2.5-flash | |
| top_k | No | ||
| top_p | No | ||
| prompt | Yes | ||
| max_tokens | No | ||
| temperature | No | ||
| system_instruction | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It adds a genuinely useful behavioral note (Gemini 2.5 thinking tokens count toward max_tokens, values like 512 may truncate visible output, 1024+ recommended) and notes unknown model names are validated by Vertex. It omits auth requirements, latency/rate limits, failure behavior, and return shape.
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?
Purpose is front-loaded in a single sentence followed by an organized Args block; nothing is wasted. The only weakness is that three sampling-parameter lines add little beyond their names.
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 7-parameter generation tool with no annotations and no output schema, the description covers inputs adequately but never states what is returned (raw text, object, usage metadata) or how errors surface. Given the absent output schema, that return-value gap leaves the definition only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must document all parameters, and it does name all seven. model (with defaults and validation behavior) and max_tokens (with the thinking-token caveat) are explained well; temperature/top_p/top_k are thin restatements of their names, hence not a 5.
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?
States a specific verb and resource ('使用 Vertex AI Gemini 模型生成文本'), and the provider/model reference distinguishes it from generate_with_deepseek. It stops short of explicitly contrasting with sibling generation tools, but the provider-scoped phrasing is enough for an agent to tell them apart.
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?
There is no when-to-use guidance, no mention of alternatives such as generate_with_deepseek or call_dashscope_mcp, and no prerequisites. The model options are listed but framed as parameter detail, not as a reason to pick this tool.
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?
Without annotations, the description carries the burden and does well by disclosing the blocking behavior via wait_for_completion parameter and the format of config_gcs_path. However, it does not mention other behavioral aspects like potential costs, quota usage, or error conditions.
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 clear sections (Args, Returns) but is slightly verbose for a tool description. It could be more concise by removing docstring conventions like 'Args:' and integrating parameter details into flowing prose.
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 output schema exists, the description appropriately focuses on input parameters. It covers all key aspects of invocation: required parameters, format of config file, method options, and waiting behavior. However, it lacks context on prerequisites like IAM permissions or job lifecycle expectations.
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 description provides detailed meaning for all four parameters beyond the input schema. For each parameter, it explains the type, required status, and acceptable values (e.g., prompt_optimizer_method options are explicitly listed). This fully compensates for the 0% schema description 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 tool starts a data-driven prompt optimization job on Vertex AI, specifying the resource and action. It distinguishes from sibling tools like analyze_data_driven_optimize_results and write_data_driven_optimize_config by focusing on job initiation.
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 explains what the tool does and mentions required parameters and config file location, but does not provide explicit guidance on when to use this tool versus alternatives like analyze_data_driven_optimize_results or write_data_driven_optimize_config. No 'when not to use' information is given.
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?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It states it returns an optimized prompt but does not disclose side effects like whether the original prompt is modified, what happens with the result, or any authentication or rate-limiting requirements.
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 and well-structured, with a clear docstring format including Args and Returns sections. It uses bullet-like formatting for method options, making it easy to scan. 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?
The description explains inputs and output but lacks context on how the optimized prompt is stored or used (e.g., does it update an existing prompt? is it temporary?). No error conditions or result format beyond 'Optimized prompt' are mentioned. Given the tool's complexity and no annotations, more completeness is expected.
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 0% description coverage, but the tool description adds meaningful details: prompt_to_optimize is a zero-based index, example_path is a GCS path to a CSV file, and method lists allowed values (TARGET_RESPONSE, RUBRICS) which are not in the schema. This significantly aids parameter understanding.
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 applies few-shot prompt optimization using a user-provided dataset and method, specifically identifying the verb 'applies' and resource 'few shot prompt optimization'. It distinguishes from sibling tools like run_data_driven_optimize by focusing on few-shot optimization.
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 its siblings. It does not mention when to choose few-shot over data-driven optimization, nor does it specify prerequisites or 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.
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?
With no annotations provided, the description carries the full burden. It explains the main behavior (config generation and upload) and return value, but omits potential side effects, error conditions, or prerequisites (e.g., GCS permissions, config validation).
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 a docstring format, front-loading the main purpose. While somewhat lengthy, it is organized and each sentence adds value. Could be slightly more concise, but overall effective.
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 6 parameters (2 required) and an output schema, the description explains the return value and parameter roles. It does not address edge cases like conflicting base_config and base_config_path, but overall provides sufficient context for an agent to use the 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 compensates by providing clear explanations for each parameter (e.g., gcs_config_uri: 'The GCS URI where the generated VAPO config JSON file will be saved'). This adds significant meaning beyond the schema property 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 tool constructs a JSON configuration for Data-Driven Optimize and uploads it to GCS. It uses a specific verb-resource pair ('Constructs a JSON configuration... uploads it to GCS') and distinguishes itself from siblings by focusing on configuration generation rather than execution.
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 ('required to run data-driven prompt optimization') but does not explicitly state when to use this tool versus alternatives like run_data_driven_optimize or run_few_shot_optimization. No exclusions or alternatives are mentioned.
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.
generate_with_vertex1 field changedInput schema / properties / model / defaultPrevious value: -"gemini-2.0-flash"New value: +"gemini-2.5-flash"generate_with_deepseekgenerate_with_vertexget_token_usage_statsupdate_prompt1 field changedInput schema / properties / display_nameAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Display Name"
+}update_prompt1 field changedInput schema / properties / display_nameRemoved value: -{
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "default": null,
- "title": "Display Name"
-}analyze_data_driven_optimize_resultscall_dashscope_mcpcreate_promptdelete_promptgenerate_html_reportlist_promptsread_promptrun_data_driven_optimizerun_few_shot_optimizationupdate_promptwrite_data_driven_optimize_config
Add one secure layer between your agents and this server.