vertex-mcp-server
Server Details
free forever
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.1/5 across 11 of 11 tools scored. Lowest: 2.1/5.
Most tools have distinct purposes: prompt CRUD, optimization jobs, config writing, analysis, and reporting. However, 'analyze_data_driven_optimize_results' and 'generate_html_report' are closely related, and 'call_dashscope_mcp' seems out of place, potentially causing confusion.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_prompt, run_data_driven_optimize). No mixing of styles, making it predictable.
With 11 tools, the server covers prompt management and optimization workflows without being overly sparse or bloated. The count is well-scoped for its domain.
The prompt lifecycle (CRUD) is fully covered. The optimization workflow includes job execution, config writing, analysis, and reporting. Minor gaps: no tool to list optimization jobs or delete results. 'call_dashscope_mcp' is an outlier that doesn't align with the core domain.
Available Tools
11 toolsanalyze_data_driven_optimize_resultsCInspect
Analyzes results and saves the detailed data to files.
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | ||
| top_n_prompts | No | ||
| analysis_data_path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It mentions 'saves to files' but gives no details on file overwriting, permission requirements, or whether it is destructive. This is insufficient for a tool that creates output files.
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 extremely short (one sentence), but conciseness here sacrifices completeness. It could be shorter but more informative; instead, it is under-specified.
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 3 parameters (2 required) and no param descriptions, the description is incomplete. It does not explain what the tool does with the parameters, the nature of the analysis, or the file format. An output schema exists but is not referenced.
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. However, it does not explain any of the three parameters (output_path, analysis_data_path, top_n_prompts). The description adds zero value for 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 states it 'analyzes results and saves detailed data to files', which gives a general purpose but is vague. It doesn't specify what kind of results or analysis, and it doesn't clearly distinguish from siblings like generate_html_report.
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, what prerequisites are needed (e.g., results from run_data_driven_optimize), or alternatives. Users are left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
call_dashscope_mcpCInspect
调用 DashScope 的远程 MCP 服务并获取结果。
Args:
tool_name: DashScope MCP 中的工具名称
arguments: 传递给工具的参数字典
| Name | Required | Description | Default |
|---|---|---|---|
| arguments | Yes | ||
| tool_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'get results' without disclosing if the operation is read-only, destructive, or has side effects. No information on rate limits, idempotency, or error behavior for a tool that proxies another service.
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 short and front-loaded with purpose, but the 'Args' section is redundant with the schema. It is not overly verbose, but better conciseness would combine purpose and parameter info efficiently without repetition.
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 tool is a proxy to another MCP service, so it requires guidance on tool discovery, expected input-output contract, error handling, and authentication. None of that is present. Output schema is available but not referenced. The description leaves critical gaps for an agent to use it correctly.
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% with no property descriptions. The description adds basic meaning: 'tool_name' is the DashScope MCP tool name, 'arguments' is a parameter dictionary. However, it lacks details like accepted formats, default values, or constraints. The 'arguments' object is completely unspecified beyond being an object.
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 calls DashScope's remote MCP service and retrieves results. The verb '调用' (call) and resource are specific. However, it doesn't differentiate from siblings that also involve MCP-like calls, but siblings are for prompts/optimizations, so implicit distinction is sufficient.
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. There is no mention of prerequisites, context, or exclusions. An agent would not know if this tool should be preferred for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_promptCInspect
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 |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'create a prompt' without mentioning side effects, permissions, or error handling, providing 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 redundancy, directly conveys the core action. Highly 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?
The output schema likely documents return values, reducing the need for that detail. However, the description omits context about optional parameters and when to use them, making it slightly incomplete for full understanding.
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 coverage, the description should explain parameters. It names four required parameters but does not define them (e.g., what is 'system_instruction'?) and ignores the optional ones, offering little semantic value 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 it creates a prompt with specific fields, distinguishing it from update, delete, and read operations. However, it only mentions required parameters, omitting optional ones like project_id and location_id, which slightly reduces clarity.
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 update_prompt or read_prompt. The description implies creation but does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_promptCInspect
Delete a prompt with given prompt_id.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | ||
| project_id | No | ||
| location_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry full burden. It only states 'delete' but omits side effects (e.g., cascade, reversibility, permissions, idempotency). Inadequate for an agent to anticipate consequences.
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?
Extremely concise (one sentence) but omits critical details. Could be more informative without significant length increase. Efficiency is fair but at cost of completeness.
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 zero annotations, low schema coverage, and no output schema description, the description is insufficient for an agent to understand all aspects of deletion. Lacks error handling, return value, and conditions.
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 description only mentions prompt_id without clarifying the role of project_id and location_id. Does not add meaning beyond 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 uses specific verb 'Delete' and resource 'prompt', and specifies the unique identifier 'prompt_id', making the action very clear. It distinguishes from siblings like create, read, update by action alone.
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, no prerequisites or exclusions provided. Agent receives no help deciding context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_html_reportCInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the tool generates a report, with no mention of side effects, required permissions, data handling, or error conditions. This is completely inadequate 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 a single sentence, which is concise but severely under-specified. It fails to include essential information that could be added without significant verbosity. The structure is minimal but lacks necessary context.
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 five parameters, no schema coverage, and no annotations, the description is far from complete. It does not explain how input data is provided or what the output report contains. The presence of an output schema does not alleviate the need for description-level completeness.
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 by explaining the five parameters (e.g., report_path, analysis_data, top_n_prompts). It does not mention any parameter, leaving the agent with no semantic understanding beyond placeholder 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 that the tool generates an HTML report from Data-Driven Optimize analysis results. It uses a specific verb ('Generates') and resource ('HTML report'), and the context differentiates it from sibling tools like 'analyze_data_driven_optimize_results' which likely produce non-report outputs. However, it could be more precise about what 'comprehensive' entails.
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 provide any guidance on when to use this tool versus alternatives. Sibling tools exist for related tasks (e.g., running analysis, viewing results), but no usage context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_promptsCInspect
Lists Vertex prompts matching a given display name.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | ||
| project_id | No | ||
| location_id | No | ||
| display_name | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It fails to disclose important behaviors: what happens when display_name is null (lists all?), pagination behavior, ordering, error cases, or permissions. The description is too brief to provide confidence in the tool's side effects or limitations.
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 of 9 words, which is concise. However, it may be too concise for a tool with four parameters and no annotations. The structure is simple and front-loaded with the action, but it lacks explanatory details that could be added without much bloat.
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 4 optional parameters, no annotations, and an output schema present, the description does not adequately explain the tool's behavior. It omits crucial context about how project_id, location_id, and page_size affect the listing, and whether all parameters are needed for correct invocation. The description is not complete enough for an agent to use the tool effectively.
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%. The description only mentions 'display name' but does not explain the other parameters (page_size, project_id, location_id). It adds meaning only for one parameter, leaving users to infer the rest from names. The description should clarify the roles of project_id and location_id for scoping.
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'), the resource ('Vertex prompts'), and a filter condition ('matching a given display name'). It distinguishes from siblings like 'create_prompt' or 'read_prompt' by implying a list operation. However, it does not explicitly differentiate from a plain list or search tool.
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 (e.g., read_prompt for a single prompt). There is no mention of prerequisites, project/location scoping, or cases where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_promptBInspect
Get the prompt content with given prompt id.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt_id | Yes | ||
| project_id | No | ||
| location_id | No |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It implies a read operation but does not disclose behavior like error handling, permissions, or side effects. It is not misleading but lacks detail.
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 of 8 words, perfectly concise with no wasted words. It is front-loaded with the key verb and resource.
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 tool has an output schema and siblings. The description is minimal but sufficient for a simple read operation. However, it could mention the scope (single prompt) and contrast with list_prompts.
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 only mentions 'prompt id', ignoring the optional project_id and location_id. It adds no meaning beyond the parameter name for required param and nothing for optional ones.
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 'Get the prompt content with given prompt id' clearly indicates the action (get) and the resource (prompt content) and distinguishes it from siblings like list_prompts (listing all) or create_prompt (creating new).
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 siblings. It does not mention when to use read_prompt over list_prompts or the prerequisites like having the prompt ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_data_driven_optimizeAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers blocking behavior via 'wait_for_completion', return value details, and the need for a GCS config file. It could disclose more about side effects or error scenarios, but it is fairly transparent.
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 structured with Args and Returns sections and is informative without redundancy. It could be slightly more concise, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers parameters and return values adequately. It does not explicitly state the need to have a config file written beforehand, but it implies it. Overall, it is fairly 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?
With 0% schema description coverage, the description compensates fully by explaining each parameter: config_gcs_path format and requirement, service account requirement, allowed values for prompt_optimizer_method, and the effect of wait_for_completion.
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 explicitly states 'Starts a data-driven prompt optimization job on Vertex AI,' providing a clear verb and resource. 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 outlines required inputs and behavior but lacks explicit guidance on when to use this tool compared to siblings. It does not mention prerequisites like having a config file already written or that this should be used after configuration and before analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_few_shot_optimizationAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions returning an 'Optimized prompt', but does not disclose side effects (e.g., whether the original prompt is modified), permissions required, rate limits, or destructive nature. The mutation is implied but not explicitly stated.
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 efficiently structured as a docstring with Args and Returns sections. It is concise, with no unnecessary words, and all three sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and three straightforward parameters, the description is mostly complete. It explains each parameter and the return value. However, it lacks guidance on usage context and behavioral effects, which slightly reduces completeness.
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 compensates fully. It explains each parameter: prompt_to_optimize is a zero-based index, example_path is a GCS path to a CSV, and method is an enum with two clearly described options.
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 applies few shot prompt optimization using user-provided dataset and method. It specifies the action ('Applies few shot prompt optimization') and the resource ('a prompt'), distinguishing it from sibling tools like run_data_driven_optimize.
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 lists two methods (TARGET_RESPONSE, RUBRICS) with brief descriptions, but does not provide explicit when-to-use guidance or alternative scenarios. It lacks exclusions or context for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_promptCInspect
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 |
Output Schema
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states 'update' but does not clarify whether updates are partial (PATCH) or full replacement (PUT). No side effects (e.g., overwriting), permission requirements, or error behavior are mentioned. Expected behavior for a mutation tool is largely unspecified.
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 with no unnecessary words, but it is underspecified. Conciseness is acceptable, but the brevity sacrifices important information, making it borderline between concise and insufficient.
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 7 parameters and no annotations, the description should provide more context. It does not cover all parameters, lacks behavioral transparency, and offers no guidance on usage. An output schema exists but is not used to compensate. The description is incomplete for the tool's complexity.
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 lists four of the seven parameters (content, system instruction, model, display name) but fails to mention prompt_id (required), project_id, or location_id. No details are given about constraints, formats, or relationships beyond the schema, which has 0% 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 action (update) and resource (a prompt), and lists the updatable fields (content, system instruction, model, display name). It distinguishes from sibling tools like create_prompt, delete_prompt, and read_prompt by specifying the update operation.
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. It does not mention prerequisites (e.g., prompt must exist) or conditions that make it inappropriate. Sibling tools include create and delete, but no comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_data_driven_optimize_configAInspect
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 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully describe behavior. It states the tool generates a JSON config and uploads to GCS, and returns a success message with console link. However, it does not disclose overwrite behavior, error conditions, or required permissions, which are important 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 structured with a clear summary followed by an Args section. It is concise enough to be informative without being excessive, though the bullet-style format could be slightly more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and return value. An output schema exists for return structure. However, it lacks context on prerequisites (e.g., GCS bucket existence) and does not explicitly link to sibling tools like run_data_driven_optimize, which would improve workflow understanding.
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 provides all parameter explanations. It explicitly describes each of the 6 parameters, including allowed values for prompt_optimizer_method and conditions for target_model_endpoint_url. This fully compensates 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 tool constructs a JSON configuration for Data-Driven Optimize and uploads it to GCS. It specifies the verb ('constructs and uploads') and resource ('JSON configuration'), distinguishing it from siblings like run_data_driven_optimize which likely executes the 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 mentions the config is required for data-driven prompt optimization but does not explicitly state when to use this tool versus alternatives like run_data_driven_optimize. No exclusions or prerequisites are provided, leaving the agent to infer its placement in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!