Loading ToolBench
MCP server for managing Render platform resources including deployments, key-value stores, logs, and metrics
Render MCP Server demonstrates solid definition quality with explicit tool registration, clear descriptions, and comprehensive parameter schemas. All 12 tools are properly defined with JSON Schema input specs and descriptions. Tool annotations (ReadOnlyHint, DestructiveHint, IdempotentHint) are present and correctly applied. However, there are notable gaps: (1) output schemas are not documented, tools return JSON text but callers cannot predict the structure; (2) error handling lacks recovery guidance, errors are returned as plain strings without suggesting next steps; (3) parameter descriptions could be more prescriptive about formats and constraints; (4) two deprecated/compatibility tools (select_workspace, get_selected_workspace) hint at legacy session-state reliance. The tool set is well-composed with clear single-responsibility design. Average param count is 2.7, suggesting good simplicity.
Create a new Key Value instance in your Render account
Retrieve the details of a particular deploy for a particular service.
Retrieve a Key Value instance by ID
Get performance metrics for any Render resource (services, Postgres databases, key-value stores). Supports CPU usage/limits/targets, memory usage/limits/targets, service instance counts, HTTP request counts and response time metrics, bandwidth usage metrics, database active connection counts for debugging, capacity planning, and performance optimization. Returns time-series data with timestamps and values for the specified time range. HTTP metrics support filtering by host and path for more granular analysis. Limits and targets help understand resource constraints and autoscaling thresholds. Metrics may be empty if the metric is not valid for the given resource.
Get the workspace stored in the session compatibility fallback. Request-scoped workspaces supplied with an explicit workspaceId are not reflected by this tool.
Output schemas not documented. All tools return JSON text (mcp.NewToolResultText) but there is no formal schema definition for the structure. LLMs cannot predict field names, types, or nesting. This forces agents to reason about responses blind.
Error handling lacks recovery guidance. Errors are returned as plain strings (mcp.NewToolResultError(err.Error())) with no actionable next steps. Example: if serviceId is invalid, the error says 'service not found' but does not suggest list_services() to discover valid IDs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 75 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
List deploys matching the provided filters. If no filters are provided, all deploys for the service are returned.
List all Key Value instances in your Render account
List all values for a given log label in the logs matching the provided filters. This can be used to discover what values are available for filtering logs using the list_logs tool. You can query for logs across multiple resources, but all resources must be in the same region and belong to the same owner.
List logs matching the provided filters. Logs are paginated by start and end timestamps. There are more logs to fetch if hasMore is true in the response. Provide the nextStartTime and nextEndTime timestamps as the startTime and endTime query parameters to fetch the next page of logs. You can query for logs across multiple resources, but all resources must be in the same region and belong to the same owner.
List the workspaces that you have access to
Deprecated: this tool is scheduled for removal; pass the confirmed workspaceId directly on each tool call instead. Select a workspace for clients that rely on MCP session state. This tool should only be used after explicitly asking the user to select one, it should not be invoked as part of an automated process. Having the wrong workspace selected can lead to destructive actions being performed on unintended resources.
Trigger a new deploy for a service. Services with autoDeploy enabled deploy automatically when their branch or image is updated, so do NOT use this tool after pushing code to such a service — the push already triggers a deploy. Use it only when a deploy won't happen automatically: services with autoDeploy disabled, redeploying without a code change, or redeploying with a cleared build cache.
Parameter descriptions lack prescriptive format guidance. Example: 'startTime' and 'endTime' in list_logs and get_metrics accept RFC3339 but the description does not include an example format or pattern. LLMs frequently miscalculate timestamp conversions.
Deprecated session-state tools present. select_workspace and get_selected_workspace rely on MCP session state (Mcp-Session-Id), which is removed in the current 2026-07-28 spec. These tools are marked deprecated but still registered and functional, creating a compatibility crutch.
Minimal parameter descriptions for simple tools. list_key_value, list_workspaces, and get_selected_workspace have empty input objects but no description of when or why to call them. This is particularly problematic for discovery tools.
maxmemoryPolicy and persistenceMode parameters in create_key_value lack descriptions entirely. Their valid values are not documented, forcing LLMs to guess or call the API blindly.
No confirmation or dry-run step for trigger_deploy, a destructive operation. If an agent mistakenly triggers a deploy on production, there is no undo. Supporting a dry_run parameter or confirmation workflow would reduce risk.