render-useful-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.4.0
Disambiguation3/5
With 212 tools, there are numerous overlapping verbs and resource types. Pairs like render_add_or_update_secret_file vs render_update_secret_files_for_service or render_list_logs vs render_recent_logs could cause misselection, though systematic naming and detailed descriptions help. Overall, the sheer volume creates ambiguity beyond the 'one or two' threshold.
Naming Consistency3/5
Most tools follow render_<verb>_<resource>, but verbs are inconsistent: list/get/retrieve are used interchangeably, add and create both appear, and add_or_update differs from update. A few convenience tools (render_service_status, render_recent_logs) break the verb_noun pattern entirely, making the naming readable but not fully predictable.
Tool Count1/5
212 tools is an extreme mismatch for the typical 3-15 well-scoped range. Even for a comprehensive platform API, this exposes the entire surface with no curation, overwhelming agents and defeating the purpose of an MCP server. The count alone makes the toolset unwieldy.
Completeness5/5
The toolset covers nearly every Render API resource and lifecycle: services, deploys, env vars, secret files, disks, Postgres, Key Value/Redis, custom domains, routes, headers, webhooks, workflows, tasks, jobs, logs, metrics, blueprints, projects, environments, members, and notifications. No obvious gaps are apparent; even convenience tools like render_wait_for_deploy fill common workflow dead ends.
Average 3.7/5 across 212 of 212 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description should explain the mutating behavior. It only notes that it calls a PATCH endpoint, but does not disclose that the 'name' parameter is required (implying a full update of name) or any side effects like whether other attributes remain unchanged. The description adds minimal behavioral insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains three sentences, but the first two are redundant ('Update environment group' and 'Update the attributes of an environment group'). It wastes words without adding substance. A more concise version like 'Updates the name of an environment group' would be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter descriptions, output schema, and the tool's mutating nature, the description fails to provide sufficient context. It does not explain the return value, whether the operation is idempotent, or how to handle errors. The agent would struggle to use this tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the description does not explain them. It mentions 'attributes' but does not specify that 'name' is the only mutable attribute or that 'envGroupId' is the identifier. This leaves the agent guessing the meaning and usage of these required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'environment group', matching the tool name and title. It provides the API endpoint, which adds specificity. However, it does not differentiate from sibling tools like render_update_env_group_env_var or render_update_env_group_secret_file, which update sub-components of an environment group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. For instance, it does not mention that to update individual environment variables or secret files, one should use the dedicated sibling tools. The agent is left without context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read, non-destructive, and non-idempotent, but the description adds no further context about side effects, idempotency, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains repetition ('Create a webhook. Create a new webhook.'). It is front-loaded but wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 required parameters and no output schema, the description omits crucial return value information and parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (40%) and the description does not explain any parameter meaning, failing to compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a webhook and specifies the API endpoint. However, it does not differentiate from sibling tools like render_update_webhook or render_retrieve_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No prerequisites or context-specific instructions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=false. Description adds no behavioral context beyond stating the action, such as what happens to the instance 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short (two sentences) but lacks utility. Being concise is positive, but it sacrifices necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one required param, no descriptions, no output schema, and no return value info, the description leaves many questions unanswered for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description only says 'by ID' without explaining the format or source of postgresId. Does not compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it suspends a Postgres instance by ID, with the API endpoint. However, it does not differentiate from sibling tools like render_resume_postgres or other 'suspend' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like render_suspend_service or render_suspend_redis. No mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds no additional behavioral context, such as whether changes are instantaneous, require certain permissions, or have side effects. It merely restates the action without enriching understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Update notification settings.' is repeated in two consecutive sentences. The third sentence about the API endpoint is useful. It could be more concise by merging the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no output schema, many siblings), the description is incomplete. It does not explain optional parameters, default behavior, or response format. No connection to related tools like retrieve current settings. The agent lacks information to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description does little to explain the purpose of parameters like emailEnabled, notificationsToSend, and previewNotificationsEnabled. The ownerId description in the schema says 'workspace' which is inconsistent with the tool's owner focus. The description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates notification settings for a specific owner, and mentions the API endpoint. It distinguishes from sibling tools like 'render_retrieve_owner_notification_settings' (GET) and 'render_patch_service_notification_overrides' (service-level) by specifying 'owner'. However, it does not explicitly compare itself to any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as retrieving current settings first or understanding that this is a PATCH operation (partial update). No context on prerequisites or success conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only reveals the API call (PATCH) but does not elaborate on side effects, permissions required, or whether updates cause restarts. Annotations are limited to hints, so the description should fill the gap but fails to do so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences and front-loaded with the key action. However, the brevity sacrifices completeness, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, nested objects, no output schema), the description is completely inadequate. It does not mention return values, required fields beyond postgresId, or the effect of updates. The agent is left without essential context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description should compensate by explaining key parameters. Instead, it adds no parameter-level information beyond what the schema already provides, missing an opportunity to clarify complex fields like ipAllowList or readReplicas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update Postgres instance' and mentions the API endpoint, indicating the verb and resource. However, it does not differentiate from other postgres-related tools like create or suspend beyond the action name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as render_create_postgres or render_suspend_postgres. It lacks context about prerequisites or scenarios that call for an update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely repeats the tool's purpose without adding behavioral context beyond what annotations indicate (not read-only, not idempotent, not destructive). It does not disclose side effects (e.g., that the env group is immediately usable by linked services) or any rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, but the first two are redundant ('Create environment group. Create a new environment group.'). The HTTP call info is valuable. It could be more concise by combining the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (3 required) and no output schema, the description fails to explain the meaning and relationships of parameters like envVars (can have value or generateValue), secretFiles, and the role of ownerId. The agent is left with insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation for any of the 6 parameters (name, envVars, ownerId, serviceIds, secretFiles, environmentId). The agent cannot understand how to structure the envVars array or what ownerId refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'environment group'. It also specifies the actual API endpoint, which helps confirm the action. It distinguishes from sibling tools like 'update_env_group' and 'delete_env_group' by using a different verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives such as 'update_env_group' or 'link_service_to_env_group'. There is no mention of prerequisites, such as needing an existing owner (e.g., workspace or team) before creating an env group.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's not read-only, not destructive, and idempotent. The description adds value by mentioning the PUT HTTP method, reinforcing idempotency. However, it doesn't elaborate on behavioral details like whether it replaces or merges existing files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main action. It repeats 'Add or update secret file' but remains efficient. The sentence about the API call adds context without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter descriptions and no output schema, the description is incomplete. It does not explain optional parameters or behavior when content is omitted, which is necessary for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for its three parameters, and the description fails to explain what each parameter means or how to use them. With 0% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or updates a secret file in an environment group, using the verb 'Add or update' and specifying the resource. However, it does not explicitly differentiate from sibling tools like render_add_or_update_secret_file, which may serve a different context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, nor does it mention conditions or prerequisites. It only states what the tool does, lacking context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Calls `PATCH /webhooks/{webhookId}`' which adds minimal behavioral info beyond annotations. Annotations already indicate non-readOnly, non-destructive, non-idempotent. No additional traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise with two sentences, no fluff. However, could benefit from a bit more structure to highlight required fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description is too minimal. It lacks information about return values, constraints, or what happens on successful update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%) with only webhookId and eventFilter described. The description does not add any parameter-level context, leaving three parameters (url, name, enabled) undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a webhook using the provided ID, distinguishing it from create or delete webhook siblings. However, it is slightly repetitive and doesn't enumerate updatable fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 render_create_webhook or render_delete_webhook. Does not mention prerequisites or context like needing existing webhook ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds that the tool calls 'GET /maintenance', which provides transparency into the API endpoint. However, it does not disclose additional behavioral traits such as pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, which is concise but somewhat redundant (first sentence restates the tool name). It could be more efficient by combining the first two sentences and adding more detail without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional parameters, no output schema), the description is incomplete. It does not mention that the response is a list of maintenance runs or indicate pagination. The state parameter, which filters by status, is not elaborated upon.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), with only resourceId having a description. The description only hints at 'specified resources' (mapping to resourceId) but does not explain the state or ownerId parameters, which require additional context for effective usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'maintenance runs', with additional context about listing scheduled/recent runs for specified resources. It effectively communicates the tool's purpose, though it does not explicitly differentiate from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like render_list_deploys or render_list_services. The description implies usage for listing maintenance runs but lacks when-not-to-use or comparison with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly (write) and non-destructive. The description adds the API call detail but no extra behavioral traits like auth or side effects. Adequate but minimal addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but redundant: first sentence repeats the title. Could be one sentence. Structure is acceptable but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or return value description. The description omits key details about parameter effects and response format, making it insufficient for a mutation tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), and the description does not explain the two enum parameters (notificationsToSend, previewNotificationsEnabled) beyond their enum values. The agent must guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a notification override for a service, distinguishing it from list/retrieve siblings. However, it repeats 'Update notification override' without adding unique context, so not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like render_patch_owner_notification_settings or other update tools. The description does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description repeats 'update' but adds no behavioral details beyond the annotations (e.g., no mention of authorization requirements, rate limits, or what happens if logs are dropped). It does not disclose any side effects beyond the parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains three sentences. The first sentence repeats the title. The second provides context about precedence. The third gives the API call. It is functional but slightly redundant and could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return value or response format. It only mentions the API call. Annotations include openWorldHint, but the description lacks information about what the agent should expect after a successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions for each parameter. The tool description does not add further semantic meaning beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates log stream override information for a specific resource, and notes the precedence over workspace default. The API path is included, aiding clarity. However, it does not explicitly differentiate from similar sibling tools like render_update_owner_log_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. It does not mention alternatives or compare to render_update_owner_log_stream or render_delete_resource_log_stream. The description only states what it does, not when to use it versus other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive (destructiveHint=true) and idempotent behavior. The description only adds the API call detail (DELETE endpoint) but does not disclose side effects, safety considerations, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Contains redundancy: first two sentences essentially repeat the same information. The third sentence adds API context, but the description could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and annotations, the description is adequate but lacks details on return values (no output schema) or behavior when the cron job is not running or does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter cronJobId, with a clear description. The tool description does not add further semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a running cron job, using a specific verb and resource. It is distinct from sibling tools like render_run_cron_job, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 render_cancel_job or render_cancel_deploy. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a mutating operation and provides the API endpoint, but does not disclose behavioral traits like idempotency, error cases, or side effects. Annotations already show destructiveHint=false, but description adds minimal context beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, with first sentence redundant to title. Could be more concise by combining, but overall not overly verbose. Front-loading is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, nested objects, and no output schema, the description is insufficient. It does not explain return values, configuration details, or constraints, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 43% schema coverage, the description adds no additional meaning to parameters. It does not explain any parameter semantics beyond what is in the schema, missing an opportunity to clarify complex fields like buildConfig or envVars.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new workflow service, specifying verb (create) and resource (workflow). It distinguishes from siblings like render_get_workflow or render_create_workflow_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or exclusions. There is no mention of when not to use it or comparison with similar creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, signaling safe, read-only behavior. The description adds the API endpoint and the specific data returned (sequential scans per table), which is useful but not critical. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences. The first sentence states the action, the second provides detail, and the third gives the API call. No redundant phrases, though the first two sentences partially repeat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description does not explain the format or fields of the returned data (e.g., list of tables with scan counts). The openWorldHint annotation suggests variable output, but the description should still set expectations for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, postgresId, has 0% schema description coverage. The description merely says 'by ID' without clarifying the ID's format or purpose. While the tool name and parameter name hint at a Postgres instance ID, the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List table scans' and specifies it returns 'the number of sequential scans performed against each table on a Postgres instance by ID.' The verb 'List' is precise, and the resource is well-defined. However, it does not explicitly differentiate from sibling list tools like render_list_postgres_processes, though the focus on scans is implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives like render_list_postgres_top_queries or other monitoring tools. There is no discussion of prerequisites, context, or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds HTTP method (GET) and default behavior (returns all accessible if no filters). Annotations already provide safety profile (readOnly, idempotent, non-destructive). No mention of pagination behavior, rate limits, or other traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; the first sentence repeats the title. Could be more concise by removing redundancy. Structure is acceptable but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description does not explain return values or structure. Despite parameter count (7) and optional filters, the description lacks completeness about what information is returned for each task run.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, baseline 3. Description only generally mentions filtering without adding parameter-specific semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists task runs with optional filters and defaults to all accessible by user. However, it does not explicitly differentiate from siblings like render_get_task_run (single run) or render_get_task_runs_completed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 render_get_task_run for a single run or render_get_task_runs_completed. The description only states what the tool does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only (readOnlyHint=false), but the description does not explain side effects (e.g., triggers verification, updates domain state). The API call is POST, implying mutation, but no behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Verify DNS configuration' is repeated. Including the API endpoint is useful but could be more efficiently integrated. Overall, it is acceptable but not optimized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 parameters and no output schema, so the description covers the basic purpose. However, it lacks context on what verification entails (e.g., checking DNS records, response format) which could help the agent understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies DNS configuration for a custom domain. It includes the API endpoint, reinforcing the specific action. However, it does not differentiate from sibling tools like render_retrieve_custom_domain or render_create_custom_domain, 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.
Usage Guidelines2/5
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. For example, it does not mention that this should be called after creating a custom domain to check DNS readiness. No explicit 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) but not destructive. The description adds the specific POST endpoint, which implies mutation. However, it does not disclose details like order of addition, impact on existing rules, or idempotency beyond what annotations suggest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first repeats the title, second adds the API call. Concise but the first sentence is redundant. It could be more efficient without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters (4 required), no output schema, and no behavioral details, the description is insufficient. Users are left guessing about the effect of adding a route (e.g., order, conflict resolution) and how priority works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, but the description adds no parameter details. It does not explain the meaning of source, destination, priority, or type beyond the schema's enum and examples. Required parameters (type, source, serviceId, destination) lack contextual guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add redirect/rewrite rules') and the resource ('to the service with the provided ID'), referencing the specific REST API call. It distinguishes from siblings like render_delete_route and render_patch_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., render_patch_route, render_put_routes). Lacks context about prerequisites, limitations, or when adding is appropriate over updating/deleting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the tool performs a create operation (consistent with readOnlyHint=false), but it does not disclose side effects, such as whether prior versions are affected or if deployment is immediate. It adds the API endpoint detail, which is useful but not a deep behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose. However, it could be improved by including parameter hints without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no output schema, the description provides the essential action but does not explain what the tool returns or what 'deploy' entails. This is minimally adequate but leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention or explain the two parameters (commit and workflowId). With 0% schema description coverage, the description entirely fails to add any semantic value for the parameters, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates and deploys a new workflow version, distinguishing it from siblings like render_get_workflow_version (read) and render_delete_workflow (delete). It also specifies the HTTP method and path, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when an existing workflow must be present, or when to use other version-related tools. No prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds that it calls a GET endpoint, confirming read-only nature. However, it doesn't disclose additional behaviors like pagination behavior or rate limits. With good annotations, the description provides minor added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, minimal redundancy. Front-loaded with the core action. Could be slightly more efficient, but overall concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return format. The tool has 5 optional parameters with filtering capabilities, but the description doesn't explain filtering scope or pagination. For a list operation, the description lacks completeness about what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions 'with the provided ID' vaguely referencing workflowID parameter, but adds no substantive meaning beyond what the schema already provides. Does not explain how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists workflow versions and explicitly mentions the API endpoint. While it doesn't contrast with sibling 'render_get_workflow_version', the name and verb imply listing vs retrieval. Purpose is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'render_get_workflow_version'. No mention of prerequisites or filtering context. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the specific API endpoint, confirming the destructive nature. However, it does not disclose potential side effects, resource recovery options, or dependency handling beyond what annotations indicate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, but the first sentence is redundant with the title. It is front-loaded but lacks meaningful detail that justifies its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature, lack of output schema, and minimal annotation detail, the description is inadequate. It does not explain the effects of removal, allowed resource types, or any constraints. More detail is needed for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description fails to explain the two required parameters ('environmentId' and 'resourceIds'). It only vaguely mentions 'with the provided ID', which is insufficient for an agent to construct the correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('remove resources from environment') and the target resource. It specifies that it uses a DELETE API call, which differentiates it from sibling tools like 'render_add_resources_to_environment' and other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for removing resources from an environment but provides no explicit guidance on when to use this tool versus alternatives, such as when to delete individual resources instead. The API call hint is present but insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds no additional behavioral context such as expected downtime, connection loss, or data safety implications. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive ('Restart Postgres instance' appears twice in different forms). It could be condensed while maintaining clarity. The API call inclusion is useful but adds length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description provides the essential purpose and API call. However, it omits mention of the effect on the instance (e.g., downtime) and typical response. Annotations fill part of the behavioral gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only one parameter and 0% schema coverage, the description adds minimal meaning by stating 'by ID' and referencing the API endpoint. This is adequate for a single parameter, but does not go beyond basic identification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Restart' and the resource 'Postgres instance', and differentiates from siblings like suspend, resume, failover by specifying the restart action. It also includes the API endpoint for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use restart versus alternatives (e.g., suspend, resume, failover). Prerequisites such as the instance being running are not mentioned, and there is no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-idempotent, non-destructive behavior. The description adds no additional context about side effects, authentication needs, or rate limits, leaving behavioral disclosure minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded core purpose and API endpoint. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description provides minimal context. It omits return value behavior and field-level update semantics, which the schema partially covers. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), so the baseline is 3. The description adds no parameter-specific information beyond the schema, but it does not need to compensate due to existing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update Blueprint' and mentions the API endpoint, making the verb and resource explicit. It is not a tautology and distinguishes from siblings like render_disconnect_blueprint, though it could better differentiate from other blueprint tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., render_disconnect_blueprint, render_validate_blueprint). The description implicitly suggests modification but does not provide when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that changing plan, max memory policy, or persistence mode will restart the instance, which is a key behavioral trait beyond what annotations provide (readOnlyHint=false, destructiveHint=false). It adds useful context about the side effects of certain parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (three sentences) but contains redundancy: 'Update a Key Value instance' is repeated. The first two sentences could be merged. It does front-load the purpose, but the repetition slightly wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic update action and mentions the restart behavior, which is important context. However, given the tool has 6 parameters (1 required) and no output schema, it omits necessary details such as what happens on success, error conditions, or parameter constraints (e.g., that redisId is required). It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema description coverage, the description should compensate by explaining parameter meanings. It does not—no mention of what each parameter controls beyond the schema. The schema already provides some descriptions, but the description adds no further value for the undocumented ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates a Key Value instance by ID, with the verb 'update' and a specific resource. It also mentions the underlying API call. However, it does not explicitly differentiate from sibling tools like create or delete, which would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., create or delete). There is no mention of prerequisites, scenarios where update is appropriate, or when to avoid it. The note about restart is behavioral, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, confirming mutation. But the description adds minimal behavioral context beyond the API endpoint. It does not disclose side effects, permissions, or whether the change is immediate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the first is redundant with the title. The second sentence about the API call adds value but could be integrated. Not overly verbose, but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema, the description lacks mention of return values or confirmation. However, given low complexity, it provides adequate context for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds the API path, which confirms endpoint mapping but does not significantly enhance parameter understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a workspace member's role, using a specific verb and resource. It distinguishes from sibling tools like 'remove_workspace_member' and 'retrieve_owner_members' by focusing on role change.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like adding a member or removing a member. The description does not clarify that this is only for role updates, not for membership management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-destructive mutation. The description adds the API method (POST) but no additional behavioral details like idempotency or conflict handling. Minimal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences, but the first two are redundant. It includes the API endpoint, which is useful. It is mostly concise but has minor repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and many sibling tools, the description is incomplete. It does not explain preconditions (e.g., resources must exist), the effect on the environment, or how it relates to other tools. More context is needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on parameters. The schema provides some detail for resourceIds items, but no additional meaning is added by the description, despite 0% schema coverage for properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds resources to an environment, using a specific verb and resource. The sibling tool 'render_remove_resources_from_environment' provides clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as the remove counterpart or other add tools. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint: true and idempotentHint: true, so the description adds minimal value beyond stating the HTTP method and endpoint. No new behavioral traits (e.g., side effects on other resources) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and includes the HTTP call. However, the first sentence repeats the title verbatim, wasting words. Could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema). The description covers the core action and constraint ('running task run') but omits expected response or error cases. With no output schema, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the single parameter (taskRunId) with 100% coverage. The description merely echoes 'with the provided ID' without adding format, source, or validation details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a task run using a provided ID, with a specific REST API call. While the purpose is unambiguous, it does not differentiate from sibling cancel tools (e.g., render_cancel_cron_job_run), missing a chance to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No direct guidance on when to use this tool versus alternatives like render_cancel_deploy or render_cancel_job. The description implies usage only for running task runs, but no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a state-changing operation (create) which aligns with annotations (readOnlyHint=false, destructiveHint=false). However, it does not elaborate on potential side effects (e.g., duplicate detection) or exact behavior beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancies except repetition of the title. Efficient but could be more informative without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks prerequisites, return value information, and examples. For a creation tool with many required parameters and no output schema, the description is insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (registry) has a schema description. The tool description adds no further explanation for the remaining 4 parameters despite low schema coverage (20%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new registry credential, specifies the HTTP method and endpoint (POST /registrycredentials), and distinguishes from sibling tools like update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_registry_credential or delete_registry_credential. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it's a write operation ('kicks off a run'), consistent with readOnlyHint=false, but adds no additional behavioral context beyond what annotations already provide. No mention of permissions, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences conveying purpose and API endpoint efficiently. Could be slightly more concise by omitting the API call, but still succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic action but does not mention what the response contains (e.g., task run ID or status). With no output schema, this omission reduces completeness for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what the schema already explains. The description mentions 'passing the provided input data' but defers details to the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates a run of a workflow task by providing the task ID and input data, and specifies the API endpoint. It distinguishes itself from sibling tools like render_get_task and render_list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 checking if the task exists first or noting prerequisites. The description assumes the agent knows when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and idempotentHint: true. The description adds minimal context beyond stating the DELETE call. It does not disclose what happens if the owner ID does not exist or any cascading effects, providing little extra value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second references the API call. No fluff, front-loaded, and efficiently conveys the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description is adequate but lacks details on error handling, success response, or idempotency behavior (though annotations cover idempotentHint). It is minimally complete but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full coverage (1 parameter), but the schema description for ownerId incorrectly states 'return metrics stream information', which contradicts the delete action. The tool description clarifies the parameter's purpose ('for the specified workspace') but does not add meaning beyond the schema. The baseline of 3 is reduced due to the misleading schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource 'metrics stream', and specifies 'for the specified workspace'. It also provides the API endpoint, distinguishing it from sibling tools like render_get_owner_metrics_stream and render_upsert_owner_metrics_stream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool vs alternatives, such as conditions for deletion, prerequisites, or when not to use. Users must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds the API endpoint and ability to query multiple resources, but lacks behavioral details like pagination or error handling. With annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first is slightly redundant with the title, but the second provides useful context. Overall efficient with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 optional parameters and no output schema, the description is minimal. It does not explain the time range behavior, resolution, or return format. Adequate but lacks completeness for new users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds little beyond 'one or more resources', which aligns with the 'resource' parameter. No extra detail on parameter formats or defaults beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the CPU limit for one or more resources and specifies the API endpoint. It distinguishes itself from siblings like render_get_cpu (usage) and render_get_cpu_target (target) by focusing on 'limit', but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives (e.g., when to use for checking limits vs actual usage). No context is provided about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal value by specifying the HTTP method and endpoint. No contradictions, but no deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but has one redundant sentence ('Get disk capacity') that echoes the title. It is not fully optimized for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters and no output schema, the description lacks completeness. It does not explain return values, parameter interactions, or time range behavior, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional parameter meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('persistent disk capacity for one or more resources') with a specific endpoint. It is unambiguous and distinct from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 render_get_disk_usage or other metric tools. No conditions or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific HTTP method (GET) and endpoint path, plus implies time-range filtering. However, it does not disclose behavioral details like pagination, default time ranges, or limits. This adds some context but is not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the key information. No fluff. However, the first sentence is slightly redundant with the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or structure. It leaves some ambiguity about what data is returned. With many sibling tools, it could be considered adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds 'one or more resources' which aligns with the 'resource' parameter's OR behavior, but no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get instance count for one or more resources' and specifies the API endpoint. It uses a specific verb and resource, but does not explicitly differentiate it from sibling tools like 'render_list_instances' which might be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives (e.g., when to use metrics endpoints vs. list endpoints). The description does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the API endpoint and 'one or more resources' but lacks details on pagination, rate limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first sentence repeats the title. The second sentence adds minimal useful info. It could be more concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 6 parameters (none required), the description fails to explain the return format, common usage patterns, or how to interpret results. Minimal value beyond schema annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema description coverage means the schema already documents all parameters. The description adds no extra parameter meaning beyond the title and a vague reference to resources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get memory usage'), the resource (memory usage), and that it can be for one or more resources, distinguishing it from sibling metrics tools like get_cpu and get_bandwidth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as get_cpu, get_bandwidth, etc. The description does not specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. Description adds the API endpoint called. No further behavioral details beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, concise. However, the first sentence is redundant with the title. Still mostly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a read tool with 100% schema coverage and no output schema. But lacks description of return format or behavior when no resource is specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves memory limits for resources, using a specific verb ('Get'). It distinguishes implicitly from siblings like render_get_cpu_limit, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds value by specifying the API endpoint and that it supports multiple resources, enhancing transparency beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with three sentences, but the first two sentences repeat 'Get memory target'. It could be more efficient without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about return values, time range behavior, or how the memory target is expressed. Given no output schema, more context on the response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add additional meaning beyond what the schema already provides for parameters. The mention of 'one or more resources' is already covered by the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves memory target metrics for one or more resources. It uses a specific verb and resource, but does not differentiate from sibling tools like render_get_memory or render_get_memory_limit, 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.
Usage Guidelines2/5
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 exclusions or context are given, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that it calls GET, which is a minor behavioral detail. No contradictions, but no significant new information beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with slight redundancy (first sentence repeats title). Efficient but not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with good annotations and single parameter, the description is adequate. It does not cover return values, but that is acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description does not add extra meaning beyond the schema's parameter description, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies retrieving a specific workflow version by ID, using verb 'Retrieve' and resource 'workflow version'. It is clear but does not explicitly distinguish from sibling tools like render_get_workflow or render_list_workflow_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Among siblings, render_get_workflow retrieves a workflow (not a version) and render_list_workflow_versions lists versions; the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, and description mentions it calls GET /dedicated-ips, which is consistent. No additional behavioral info beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, short and to the point. First sentence is slightly redundant with title but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description doesn't mention return type (list of dedicated IPs) or any additional context like authentication. Adequate for a simple list tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter 100% with description. Tool description adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (list) and resource (dedicated IPs), and specifies it's for a workspace. However, does not differentiate from sibling tool 'render_retrieve_dedicated_ip' which retrieves a single dedicated IP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., render_retrieve_dedicated_ip). Does not mention when-not or provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, etc., covering safety. The description adds minimal behavioral context beyond the API call. For a read-only tool with strong annotations, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant: 'List webhooks. List webhooks...' repeats the same phrase. It could be consolidated into one sentence. It front-loads the action but wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return values (e.g., an array of webhook objects). It does not. The description is incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any meaning to parameters beyond the schema's own descriptions (limit, cursor, ownerId).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (webhooks), and explicitly mentions the API endpoint GET /webhooks. This distinguishes it from siblings like render_list_webhook_events (which lists events, not webhooks) and render_retrieve_webhook (single webhook retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., render_retrieve_webhook for individual webhooks). No when-to-use or when-not-to-use information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds only that it triggers recovery but does not disclose details like whether it creates a new database or replaces the existing one, or any side effects beyond the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, minimal and efficient. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of point-in-time recovery (7 parameters, no output schema), the description lacks details on expected return values, prerequisites (e.g., backups enabled), and behavior (e.g., does it create a new database?). Incomplete for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema already documents parameters well. The description does not add meaning beyond noting the API call; no parameter explanations beyond schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it triggers point-in-time recovery on a Postgres instance, using the verb 'Trigger' and naming the resource. It distinguishes from siblings like create_postgres or restore_snapshot by specifying the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., restore_snapshot, failover_postgres). The description only explains the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Resume' which implies a state change, but does not disclose any behavioral traits such as idempotency, error conditions, or potential side effects. The annotations show readOnlyHint=false, which is consistent, but no additional context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences. It efficiently conveys the action, resource, and API endpoint. No unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description is adequate but incomplete. It misses behavioral context such as idempotency or error handling. The presence of annotations helps slightly, but the description adds minimal extra value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'postgresId', with no description in the input schema. The tool description does not elaborate on its meaning or format. The schema coverage is 0%, so the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Resume' and the resource 'Postgres instance', and includes the API endpoint. It distinguishes from siblings like 'render_suspend_postgres' by specifying the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool. It doesn't mention prerequisites, alternatives, or situations to avoid. The sibling tool 'render_suspend_postgres' implies this is the reverse operation, but no explicit instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that connection info includes sensitive information, which is important for authorization awareness, and specifies the exact API call, providing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise but has slight redundancy: first sentence repeats title. The API endpoint line adds value. Could be improved by removing the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not specify what the connection info contains beyond 'sensitive information'. Missing details on error states, auth requirements, or response structure, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter redisId has no description in input schema (0% coverage). Description merely says 'by ID' which is minimal. No explanation of format, validation, or source for the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Retrieve' and resource 'Key Value connection info' by ID. Differentiates from sibling retrieval tools like render_retrieve_key_value and render_retrieve_redis_connection_info by specifying 'connection info', but does not explicitly distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: retrieve connection info for a Key Value instance. No explicit guidance on when not to use or alternatives, but the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the specific HTTP method and endpoint, which is useful but doesn't disclose additional behavioral details like reversibility or side effects on linked services.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first sentence 'Remove secret file' repeats the title, and the second rephrases it. Could be more concise while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with only 2 parameters and no output schema, the description lacks information about post-deletion effects (e.g., service restart) or error conditions. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), resource (secret file from an environment group), and the specific API endpoint. It distinguishes from sibling tools like render_delete_secret_file or render_delete_env_group_env_var by specifying 'from an environment group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like render_delete_secret_file or render_update_env_group_secret_file. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint. The description adds the HTTP method, but does not explain the behavior beyond that—e.g., whether the deletion is permanent, whether it requires the instance to exist, or what happens if already deleted. With annotations covering safety, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence restates the title, the second provides an API reference. It is concise and front-loaded, but could be slightly more efficient by combining.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one parameter and no output schema, the description is minimally sufficient. However, it lacks context about deletion semantics (permanence, authorization, response). Completeness is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not add any meaning to the redisId parameter. It simply states the tool deletes by ID without specifying the format or origin of the ID. The agent gets no additional semantic help beyond the schema's type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete), the resource (Key Value instance), and the identifier (by ID). It also names the API endpoint, making the tool's purpose unambiguous and distinct from sibling delete tools like render_delete_redis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives. It lacks context about prerequisites, consequences, or scenarios where this tool is appropriate. The usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the API endpoint and context of the Postgres instance, but does not disclose side effects (e.g., cascading deletes, impact on existing connections). It provides marginal extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no fluff. The title is front-loaded, and the description efficiently conveys purpose and API call. All sentences are necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% schema coverage, the description should explain parameters and return behavior. It does not mention success/error responses or confirm deletion. Incomplete for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'with the provided ID' and the endpoint includes {username}, but it does not explain what postgresId or username represent (e.g., format, constraints). Fails to add meaning beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete PostgreSQL User' and specifies the action of deleting a user from a Render Postgres instance. It includes the API endpoint for precise context, distinguishing it from create or other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It does not specify prerequisites (e.g., user must exist) or when to avoid using this tool (e.g., if the user has active connections). Alternatives or when-not-to-use are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description only adds the API endpoint 'DELETE /workflows/{workflowId}', but does not explain consequences, permissions, or whether deletion is reversible. It adds minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, direct sentences. No unnecessary words. Front-loaded with the action and resource. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and annotations cover safety. However, there is no output schema and the description does not mention return values, error conditions, or prerequisites. For a destructive tool, more context about effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no extra meaning to the single parameter 'workflowId'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete workflow' and specifies 'Delete the workflow service with the provided ID.' It uses a specific verb and resource, distinguishing it from sibling tools like render_create_workflow or render_list_workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., workflow must exist) or warnings about permanent deletion. The description does not help the agent decide between this and other delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it calls a GET endpoint and returns information per workspace, which slightly extends behavioral context but does not disclose significant traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the first sentence repeats the title ('Retrieve metrics stream'). It is otherwise concise and front-loaded with the action and result. Slight redundancy reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should clarify return values. It only says 'Returns metrics stream information' without elaboration on structure or contents, and omits error conditions, prerequisites, or pagination details. For a read tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description only paraphrases the schema's ownerId description ('for the specified workspace'). No additional parameter details, defaults, or constraints are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves metrics stream information for a specified workspace and includes the API endpoint. It distinguishes from siblings like render_get_owner_log_stream by specifying 'metrics stream' vs 'log stream', though it does not explicitly differentiate from other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading metrics stream info but provides no explicit guidance on when to use this vs alternatives like render_upsert_owner_metrics_stream or render_delete_owner_metrics_stream. No when-not or context-dependent advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint: false) already convey safety and idempotency. The description adds the endpoint but lacks details on rate limits, authentication, or error handling, which is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, though the first sentence slightly repeats the tool title. It is well-structured but could be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and only a minimal description, the tool lacks contextual completeness. It does not explain the output format, default values, or how to interpret the lag metric, which is insufficient for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters, so the description adds no additional meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves replica lag in seconds for a Postgres replica and specifies the API endpoint. The verb 'get' and resource 'replica lag' are unambiguous, and the tool is distinct from sibling metrics tools like get_cpu or get_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. It does not mention context such as monitoring replication health or when to prefer other metrics tools, and there is no exclusionary criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds the API endpoint and the concept of 'queryable instance values,' but does not significantly expand on behavioral traits beyond what annotations provide. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with the purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a read-only, idempotent tool with good annotations and full schema coverage. However, it does not explain what 'instance values' are contextually (e.g., application metrics filters) or how this tool relates to similar list-filter-value siblings. This could cause confusion for an agent unfamiliar with Render's API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 5 parameters have descriptions). The description adds no additional meaning or examples beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists instance values for filtering one or more resources, and names the API endpoint. However, it does not differentiate from sibling tools like render_list_http_filter_values or render_list_path_filter_values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of prerequisites, exclusions, or when not to use it. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the API method and path, but does not disclose further behavioral traits like rate limits, error handling, or the nature of audit logs. With annotations present, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the main action and include the API call. No redundant information; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the well-documented schema and annotations, the description covers the essential purpose but lacks detail on pagination mechanics, return format, and time range semantics. It is adequate but could be more complete for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description does not add additional parameter meaning beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing/retrieving organization audit logs with optional filtering and pagination. It explicitly mentions the API endpoint, which adds specificity. However, it does not differentiate from sibling tools like render_list_owner_audit_logs, so a 5 is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives (e.g., owner audit logs). It also lacks prerequisites or context for appropriate use. The description only states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, indicating a safe read operation. The description adds the API endpoint and confirms it is a retrieval. It does not disclose additional behavioral traits such as rate limits, potential empty results, or any side effects, but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and minimal. Every sentence adds value: the first states the action and resource, the second adds filtering/pagination and the API call. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could inform about the return format (e.g., a list of audit log entries) but does not. The tool is simple with well-described parameters, but the lack of output details reduces completeness. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with detailed descriptions for all 6 parameters. The description does not add extra meaning beyond stating 'optional filtering and pagination'; it relies on the schema. Therefore, the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List workspace audit logs' and explains it retrieves logs for a specific workspace with optional filtering and pagination. It references the API endpoint. While it distinguishes from sibling tools by specifying 'workspace' and using 'ownerId', it does not explicitly contrast with the sibling tool 'render_list_organization_audit_logs', which could be for organization-level logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic usage ('Retrieve audit logs for a specific workspace with optional filtering and pagination') but offers no guidance on when to use this tool versus alternatives like 'render_list_organization_audit_logs' or 'render_list_logs'. There are no when-not-to-use indications or explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds the HTTP method and endpoint, but does not disclose additional behavioral traits like state expectations (e.g., must be suspended first) or idempotency behavior. Given annotations, the description provides modest added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, fairly concise. The first sentence is slightly redundant with the title, but the overall structure is clear and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, no output schema), the description is adequate but could be more complete. It does not explain prerequisites (e.g., instance must be suspended) or side effects. With no schema descriptions, the description should compensate, but it falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter description (0% coverage), and the description merely says 'by ID' without clarifying what 'redisId' represents (e.g., 'the ID of the Key Value instance to resume'). No added semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Resume), resource (Key Value instance), and the specific API endpoint. It distinguishes from siblings like 'render_suspend_key_value' and other resume tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., 'render_suspend_key_value' for suspension, other resume tools for different resources). The context implies its use, but the description lacks explicit when/when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds that it is a GET request, which is consistent but does not disclose any additional behavioral traits such as authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no unnecessary information. The first sentence repeats the title, which is mildly redundant but acceptable. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description could explain what the API returns (maintenance run object). It implies this but does not elaborate. Low complexity tool but missing output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no explanation of the maintenanceRunID parameter beyond what the schema provides (pattern and example). It does not clarify that this is the unique identifier or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a maintenance run by ID and names the exact API endpoint GET /maintenance/{maintenanceRunID}. This distinguishes it from list and mutation siblings like render_list_maintenance and render_trigger_maintenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 explain that it is for fetching a single run versus listing all runs, nor does it mention prerequisites like having the maintenanceRunID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds little beyond stating the HTTP method (GET) and that it queries a specific endpoint. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, but the first two are nearly identical ('Retrieve notification settings.' followed by 'Retrieve notification settings for the owner with the provided ID.'). It could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and rich annotations, the description covers purpose, parameter usage, and the API endpoint. It is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes ownerId as 'The ID of the workspace to return resources for'. The description adds clarity that the owner ID is not a resource ID, providing important disambiguation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves notification settings for an owner. It specifies the verb 'Retrieve' and the resource 'notification settings for the owner'. However, it does not explicitly differentiate from sibling tools like render_patch_owner_notification_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance that an owner ID is required and that it is not a resource ID. It implies usage for retrieving settings but does not explicitly state when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds the API call details but doesn't disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the first repeats the title. Could be more concise, but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about what is returned (no output schema). For a single-parameter tool, the description should hint at the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description only says 'the provided ID' without adding format, constraints, or examples. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a project by ID, specifies the API endpoint, and the title matches. Among siblings, it's distinct from list and update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'retrieve' and the parameter 'projectId', but no explicit guidance on when to use this versus list or other retrieve tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description only restates the action without adding detail on side effects, permissions, or what suspension entails beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with minimal redundancy. Could be merged but remains readable and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter action with annotations, the description covers the essential purpose and API call. Lacks mention of return values or state after suspension, but given the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already describes the serviceId parameter. The description adds no additional context about the ID format or how to obtain it, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'suspend' and the resource 'service', specifying the exact action. It also includes the API endpoint, which disambiguates from sibling tools like render_suspend_postgres or render_resume_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, when not to use, or compare with related tools like resume_service.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=false and readOnlyHint=false, so the description's mention of PATCH is consistent but adds limited value. It does not disclose behavior on missing workflowId or partial updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous text. Minor redundancy with title ('Update workflow'), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks return value information despite having no output schema. Does not clarify that only provided fields are updated or that the updated workflow is returned. Nested buildConfig object is not explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60%, and the description adds no parameter-specific details beyond what the schema already provides (e.g., autoDeployTrigger enum is well-described in schema). No compensation for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a workflow by ID, using the specific verb 'update' and referencing the resource 'workflow service'. It distinguishes from sibling tools like render_create_workflow and render_delete_workflow by naming the PATCH endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives (e.g., create, delete, or other update tools). There is no mention of prerequisites, when not to use it, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation with destructive potential (`readOnlyHint: false`, `destructiveHint: true`). The description adds the API endpoint and a link to documentation, which is useful context but does not disclose additional behavioral traits such as side effects, requirements, or whether the operation replaces the entire config. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, consisting of three short sentences. The first sentence is somewhat redundant with the title, but the second and third add useful information (purpose and API endpoint). It is front-loaded with the core purpose, though the redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 required parameters, nested objects, no output schema) and the presence of many sibling tools, the description lacks important context: it does not mention prerequisites (e.g., service must have autoscaling enabled), what happens on success, or any side effects beyond the destructive hint. The documentation link helps but is not a substitute for in-description guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-level explanation beyond the schema. With schema coverage at 60%, several parameters like `enabled` and the nested `criteria` fields lack detailed descriptions. The description does not compensate by clarifying how parameters interact, leaving the agent to infer semantics from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update autoscaling config' for a service by ID, and distinguishes itself from related tools like `render_scale_service` and `render_delete_autoscaling_config` by specifying the exact API endpoint. The verb+resource combination is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to update autoscaling configuration, but it does not explicitly state when to use it versus alternatives like manual scaling (`render_scale_service`) or deleting autoscaling config. No exclusions or alternative recommendations are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds the HTTP method (POST), confirming mutation. However, it does not discuss permissions, rate limits, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (2 sentences) and front-loaded. It is efficient but could be slightly more structured (e.g., stating that it creates a project and optionally environments).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required params, including a nested 'environments' array. The description does not explain the implications of creating environments concurrently or return value, leaving some gap despite rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The description adds no extra parameter details beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('project'), and even specifies the API endpoint. This distinguishes it from sibling tools like render_update_project or render_get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it calls DELETE /services/{serviceId}, which is marginal beyond annotations. No additional details on side effects or irreversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, but the first two are redundant ('Delete service. Delete the service...'). Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete with one parameter and no output schema, the description is adequate but lacks information on prerequisites or consequences of deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'The ID of the service'. The description repeats this but adds no further meaning like format or source of the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (service), specifying it uses the service ID. It distinguishes itself from siblings like render_delete_postgres or render_create_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 render_suspend_service or render_restart_service. No prerequisites or context for deletion are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the specific HTTP method and endpoint, but does not elaborate on what 'log stream information' entails (e.g., format, size limits). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action. The first sentence is a bit terse ('Retrieve log stream.') but the second provides necessary context. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter and no output schema, the description gives the essential information (endpoint, param). However, it could clarify what the response contains or any pagination/formatting details, but it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for ownerId. The description reiterates that the ownerId specifies the workspace but adds no extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action is to 'retrieve log stream', specifies the resource as 'log stream information for the specified workspace', and explicitly names the API endpoint. This distinguishes it from sibling tools like delete or update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other log-related tools (e.g., render_list_logs, render_subscribe_logs). The description does not mention when not to use it or provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the API endpoint call, which provides some behavioral context beyond annotations (destructiveHint=true). However, it does not elaborate on irreversible consequences or auth requirements. Given annotations cover destructiveness, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point (3 sentences). The first sentence slightly repeats the title but overall is efficient. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and API call. For a simple tool with no output schema and only 2 required params, it is fairly complete. However, it omits potential error conditions or prerequisites, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add additional parameter semantics beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove workspace member') and the specific resource ('Remove a user from the specified workspace'). It also references the exact API endpoint, making it unambiguous. This distinguishes it from siblings like 'update_workspace_member'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives, such as permissions needed or prerequisites. No explicit when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds the specific API endpoint (GET /services/{serviceId}/deploys/{deployId}), but does not elaborate on response format or other behavioral details. Acceptable but not extra informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (two sentences) but first sentence is redundant ('Retrieve deploy.'). Second sentence combines purpose and API call. Could be more efficient by merging.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieve operation with 2 parameters and no output schema, the description explains what it does and the API call. However, it does not mention the format or structure of the returned deploy details, which could be helpful without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions. Description adds no new meaning beyond stating 'for a particular service' and 'particular deploy', which is already clear from parameter names and schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves details of a specific deploy for a specific service. Specifies verb (retrieve), resource (deploy details), and context (service). Distinguishes from sibling retrieve tools by focusing on deploys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like render_list_deploys or render_retrieve_service. No mention of when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's mention of 'GET' adds minimal value. No additional behavioral traits (e.g., caching, rate limits) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a redundant first sentence ('Retrieve disk.') that restates the tool name. It is short but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description provides sufficient context (endpoint, parameter usage). It does not describe the return object, but that is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the diskId parameter with description, pattern, and example. The description only restates 'the provided ID' without adding new meaning. Baseline score of 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a persistent disk by ID and specifies the API endpoint (GET /disks/{diskId}). This distinguishes it from sibling tools like render_list_disks (list all disks) and render_delete_disk (delete disk).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when to retrieve a single disk instead of listing disks or other disk-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds that the response includes sensitive information, which is valuable beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the deprecation notice and clear purpose. It is concise, though the second sentence is somewhat redundant with the third.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with annotations covering safety, the description covers purpose, deprecation, and sensitivity. However, the lack of parameter explanation and output details leaves gaps for an agent with no other context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'redisId' parameter beyond its name. The agent lacks guidance on what the Redis ID refers to or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves connection info for a Redis instance by ID. It distinguishes itself from other connection info tools implicitly through naming, but does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the tool is deprecated in favor of the Key Value API, providing an alternative. It also warns that connection info includes sensitive information, adding context for responsible use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, which cover safety and idempotency. The description adds the API endpoint (GET /webhooks/{webhookId}), which gives a bit more detail, but it does not disclose other behavioral aspects like response format, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only two sentences. It front-loads the purpose and includes the API call detail efficiently. No redundant or unnecessary words. However, it could be slightly more informative without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema), the description is minimally complete: it identifies the resource and action. However, it lacks context on when to use this tool over similar retrieval tools (like render_retrieve_deploy) or how to interpret the result, which may leave some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the required parameter. The description reiterates 'with the provided ID' but does not add any new meaning or clarify the parameter beyond what the schema already provides (type, pattern, example).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a webhook' and specifies retrieving by ID, leaving little ambiguity about its function. However, it does not explicitly differentiate itself from sibling tools like render_list_webhooks or render_delete_webhook, which could cause confusion about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a webhook ID, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., listing webhooks for ID discovery, or using update/delete for mutations). No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly (false) and non-destructive (false). Description adds the API endpoint but no extra behavioral context like permissions or side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first gives purpose, second adds API endpoint. Efficient with no fluff, though could integrate parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with 5 parameters and no output schema, the description is too brief. It lacks details on partial vs full update, required permissions, and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), but the description does not elaborate on any parameter beyond what the schema provides. Required parameter environmentId is only mentioned indirectly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Update' and identifies the resource 'environment' by ID. It clearly distinguishes from sibling tools like create/delete/retrieve environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool modifies an existing environment but provides no explicit guidance on when to use vs alternatives or what prerequisites exist. Usage is inferred from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readOnly, non-destructive, non-idempotent. The description adds that it calls a POST endpoint, confirming a write operation. However, it does not disclose other important traits like whether the operation is synchronous or async, potential side effects, or prerequisites. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus a documentation link. Every sentence adds value, and the action is front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (1 param, no output schema), the description is incomplete. It does not explain what the export creation returns (e.g., an export object or async task), whether it's synchronous, or any preconditions like permissions. With no output schema, these details are essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (postgresId) with 0% description coverage. The description only mentions 'by ID' without detailing what the ID represents or its format. This is minimal value beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create an export), the target resource (Postgres instance by ID), and references the API endpoint. It distinguishes from siblings like render_create_postgres (create a new DB) and render_list_postgres_export (list exports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for creating exports but lacks guidance on when not to use or when to prefer tools like render_list_postgres_export to check existing exports.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds the API endpoint (`DELETE /services/...`) and confirms the operation, but does not elaborate on consequences, permissions, or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second provides the parameters and API call. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers the basic purpose and identifiers. However, it does not mention that the domain is permanently removed, or any potential error conditions. Annotations partially compensate, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description merely reiterates their purpose ('given the service id and custom domain id or name') without adding new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource 'custom domain', and specifies the required identifiers (serviceId and customDomainNameOrID). It distinguishes from sibling delete tools by naming the specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives (e.g., render_delete_service or render_delete_disk). The context is implied but not explicit, leaving the agent to infer usage from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the API endpoint but does not elaborate on consequences (e.g., downtime, data consistency) beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first repeats the name slightly redundantly, but the second efficiently provides context and API detail. Almost succinct, but could merge to avoid repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (single parameter, no output schema) and annotations, the description provides minimal but sufficient context for an agent to invoke the tool. Missing prerequisites (HA instance) and potential outcomes beyond the annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should explain the 'postgresId' parameter (e.g., how to obtain it, its format), but it only names it. No added semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Failover') and the resource ('Postgres instance'), and differentiates from sibling tools like render_restart_postgres or render_recover_postgres by specifying it's for highly available instances and providing the API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'highly available Postgres', implying usage context, but does not explicitly excludenon-HA instances or mention alternatives like render_restart_postgres. No clear when-to-use vs when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover behavioral traits. The description adds the API endpoint but does not elaborate on additional behaviors like auth requirements, rate limits, or side effects beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains two sentences, but the first is redundant with the title ('Get CPU usage'). The second provides useful endpoint info. It could be more concise with minimal loss of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain what the response contains (e.g., time series data format). However, the parameters are well-documented in the schema, and the tool's complexity is low. It is adequate but missing return value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any extra meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get CPU usage for one or more resources' and includes the specific API endpoint (GET /metrics/cpu). This distinguishes it from sibling metric tools (e.g., render_get_memory) by specifying the metric type (CPU) and resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving CPU metrics but does not explicitly state when to use this tool versus alternatives (e.g., other get_* tools). No exclusion criteria or context for when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful context about the API endpoint and the ability to query multiple resources, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Get CPU target' is repeated. It could be more concise by merging the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only metrics tool with no output schema, the description is adequate but lacks details on what the response contains (e.g., time series, values). It does not explain how to interpret 'CPU target'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description does not add significant meaning beyond the schema, such as clarifying the difference between 'resource' and 'service' or usage of start/end times.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves CPU target metrics for one or more resources and specifies the API endpoint. This distinguishes it from sibling tools like 'render_get_cpu' and 'render_get_cpu_limit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives such as 'render_get_cpu' or 'render_get_cpu_limit'. The description does not mention use cases or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds the API endpoint and 'for one or more resources', but no additional behavioral traits (e.g., rate limits, filtering behavior). Adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and method. No redundant or unnecessary text. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a metrics tool with 8 parameters and no output schema, the description could explain the returned count (e.g., raw count vs time series) or pagination. It covers the core usage but leaves gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. Description adds no parameter-specific meaning beyond what's in the schema; it only loosely refers to resources. No compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'HTTP request count' with specific detail on resources and API endpoint. Distinguishes from sibling metrics tools like get_cpu and get_memory by focusing on HTTP requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives (e.g., render_get_http_latency) or when not to use. The description only states what it does, not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds the API endpoint and verb but does not disclose additional behavioral traits such as response structure or pagination behaviour beyond what the schema provides. Since annotations cover safety, the description adds limited value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: the first restates the title, the second specifies the blueprint ID, and the third gives the API endpoint. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema and well-documented parameters (100% coverage), the description is minimally adequate. It states the purpose and endpoint but lacks details about the response format or pagination usage, which the schema partially covers via links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description does not add any new meaning for the parameters; it merely references the blueprint ID. The schema already describes each parameter adequately, including links to pagination docs for limit and cursor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Blueprint syncs', and specifies that it lists syncs for the Blueprint with the provided ID. It distinguishes from sibling tools like render_list_blueprints by focusing on syncs of a specific blueprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies the need for a blueprint ID but does not explain prerequisites (e.g., obtaining a blueprint ID from list_blueprints) or mention pagination handling. Context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this by specifying the GET method but adds no new behavioral details (e.g., error handling, permissions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; first sentence repeats the title, second adds the API call. Not overly verbose but could be more concise by combining them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with rich annotations and a single parameter, the description covers the essential purpose and API call. It does not describe the return object, but no output schema exists, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (blueprintId) with description, pattern, and example. The description adds no additional semantic value beyond 'with the provided ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action (Retrieve), resource (Blueprint), and uses the HTTP method (GET /blueprints/{blueprintId}). Distinguishes from siblings through the specific resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over the many other retrieve tools (e.g., retrieve_service, retrieve_postgres). The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, etc. The description adds 'Calls GET /postgres/{postgresId}', confirming a safe read operation. However, it does not disclose any behavioral traits beyond what annotations imply, such as rate limits or data potentially returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: a one-line summary and a line specifying the HTTP call. It is concise and front-loaded with the purpose. Every sentence serves a function, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 required parameter, read-only), but there is no output schema and the description does not explain what is returned. For a retrieval tool, knowing the response structure would aid an AI agent. The annotations cover safety but not completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (postgresId) with 0% description coverage. The description only says 'by ID' without explaining the format, source, or context of the ID. No additional semantics are provided beyond the schema's type and requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve Postgres instance' and 'Retrieve a Postgres instance by ID', specifying the verb and resource. Among sibling tools like render_retrieve_blueprint and render_retrieve_service, the name and description distinguish it by focusing on 'postgres', making differentiation straightforward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a postgres ID and want instance details, but it does not explicitly state when to use this tool over alternatives (e.g., use render_retrieve_postgres_connection_info for connection info). No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only operation; description adds value by noting that connection info includes sensitive information. This helps the agent understand the nature of the data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, but the first sentence repeats the title. Could be more concise by merging the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with one parameter and annotations, the description adequately covers the resource, action, endpoint, and sensitive data. Missing permissions or response structure, but output schema is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only says 'by ID' without explaining the parameter format, constraints, or how to obtain the postgresId. No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (retrieve), resource (Postgres connection info), and the specific endpoint. It distinguishes from siblings like render_retrieve_postgres and render_retrieve_postgres_recovery_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 when-not-to-use instructions. The description only says what it does, without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it calls GET /postgres/{postgresId}/recovery, which is consistent but does not reveal additional behavioral traits like response format 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but slightly repetitive ('Retrieve point-in-time recovery status' and 'Retrieve information on the availability...'). It is front-loaded but could be condensed into one sentence without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, clear annotations, and no output schema, the description adequately specifies the action and API endpoint. It covers the core purpose but lacks detail on the output structure or what 'availability' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'postgresId' with 0% documentation coverage. The description mentions 'by ID' and the API endpoint includes {postgresId}, providing implicit meaning but no explicit format or constraints. Baseline 3 is appropriate given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieve'), the resource ('point-in-time recovery status for a Postgres instance'), and includes the API endpoint. It distinguishes from sibling tools like render_retrieve_postgres or render_get_replication_lag by specifying the exact recovery status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool vs alternatives, such as render_retrieve_postgres or render_retrieve_postgres_connection_info. No context on prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds that the disk is persistent and requires redeployment, which is valuable context beyond annotations. No contradiction detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the key action and then adds context. It could be slightly improved by connecting the first sentence more naturally, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not mention what the tool returns (e.g., disk object or confirmation). It also lacks prerequisites like service existence or disk size limits. For a creation tool with 4 required parameters, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain parameters. It does not define name, sizeGB, mountPath, or serviceId, leaving the agent without guidance on what each parameter means or how to use them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add disk' and specifies the resource (persistent disk) and targets (web service, private service, background worker). It distinguishes from sibling tools like render_update_disk and render_delete_disk by focusing on attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the service must be redeployed after using this tool, providing a key requirement. However, it does not explain when to use this vs alternatives like render_update_disk, nor does it list prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description adds minimal behavioral context beyond stating it is a POST request. No additional traits like authentication needs or side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the essential purpose and provide the API endpoint with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description lacks details about the return value, constraints like name uniqueness, or what the created environment represents, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (40%), and the description does not compensate by explaining parameters beyond what the schema provides. For example, 'name' and 'projectId' have no description, and the description does not elaborate on their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Create' and the resource 'environment', and distinguishes from sibling tools like render_delete_environment, render_update_environment, and render_retrieve_environment by specifying creation and the API endpoint POST /environments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage (create new environment for a project) but does not provide explicit guidance on when to use versus alternatives like render_update_environment, nor does it mention any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description accurately conveys a state change. However, it does not disclose other behavioral traits such as impact on existing connections, reversibility, or potential side effects. The mention of the API endpoint adds minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each adding value. The first sentence restates the title (slightly redundant) but the second and third provide unique detail. No unnecessary words, but could be further streamlined by merging the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and no output schema, the description covers the action and key effect. However, it omits important contextual details like idempotency (what if user exists?), prerequisites, and whether the operation is reversible. For a creation tool, this leaves gaps in agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (username described, postgresId not). The description adds context by linking 'new user' to username and 'provided ID' to postgresId, partially compensating for the missing schema description. However, it does not fully clarify the format or constraints of postgresId, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Create PostgreSQL User', the resource 'for the Render Postgres instance with the provided ID', and a key side effect: 'becomes the new default user'. This clearly distinguishes it from sibling tools like render_list_postgres_users and render_delete_postgres_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage on a specific Postgres instance but does not explicitly state when to use this tool versus alternatives. It lacks prerequisites (e.g., postgres must exist, required permissions) and fails to differentiate from other postgres creation or user management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true, so the description adds little extra. It repeats 'Delete' and the API call but does not disclose potential side effects, reversibility, or permissions beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no unnecessary words. It front-loads the purpose and adds the API call as a detail, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description is mostly complete. It covers the action and resource, but lacks any context about consequences or preconditions, which would be helpful for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter fully (100% coverage). The description does not add any additional meaning or context for the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'dedicated IP set', and specifies the required ID. It also references the exact API call, making the purpose unambiguous and distinct from other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 versus alternatives, nor are any prerequisites or conditions mentioned. The implied usage is simply having the ID, which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the API endpoint and scope ('for one or more resources'), which provides some context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, front-loading the purpose and efficiently conveying the action and API call. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with good annotations and full parameter descriptions, the description is mostly complete. However, it omits details about return format or pagination, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described in the schema. The description does not add extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'bandwidth usage', and specifies the API call. It distinguishes itself from sibling tools like render_get_cpu and render_get_memory by focusing on bandwidth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., other metric tools). It only states what it does, without context on usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it calls GET /services/{serviceId}/env-vars, confirming it's a read operation. It does not disclose pagination behavior or rate limits, but the schema provides pagination params. Overall, adequate beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the key action first. No redundant words. Efficient and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the return value or response structure. Although no output schema is provided, for a list tool it would be helpful to indicate what fields are returned (e.g., list of environment variable objects). This is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The description adds no further meaning beyond restating that serviceId is needed. Baseline 3 applies as schema handles semantics completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists environment variables for a specific service, using a specific verb ('List') and resource ('environment variables'). It distinguishes from sibling list tools by focusing on env vars and requiring a service ID, which is unique among list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide when-to-use or when-not-to-use guidance, nor does it mention alternatives. It is straightforward, but lacks explicit usage context relative to siblings like 'render_list_secret_files_for_service' or 'render_update_env_vars_for_service'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP method and endpoint path, which provides minimal extra behavioral context beyond the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose. Each sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and mentions optional filters, but lacks details on return format, handling of multiple resources, and the impact of resolutionSeconds. For a metrics tool with 6 parameters and no output schema, minor gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description only reiterates the state and aggregateBy parameters, adding no new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the count of completed task runs, with optional state filtering and aggregation. However, it does not differentiate from siblings like render_get_task_runs_queued or render_list_task_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for counting completed runs but lacks explicit guidance on when to use this tool over alternatives, such as listing detailed runs or queued counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds the endpoint and return type (count) but not additional behavioral traits like auth requirements or rate limits. With annotations covering safety, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes the API call. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the purpose and endpoint but does not detail the return format. The schema covers parameters well. The description is fairly complete but could mention that the result is a count or array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters having descriptions. The description does not add further meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get task runs queued count' and description clearly state the verb 'Get', the resource 'task runs queued count', and scope 'for one or more tasks'. It also mentions the API endpoint, distinguishing it from siblings like render_get_task_runs_completed and render_list_task_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool versus alternatives like render_list_task_runs or render_get_task_runs_completed. No when-not-to-use or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint false) and non-idempotent behavior (idempotentHint false). The description adds context by stating the API endpoint (POST) and the effect, but it does not disclose error conditions (e.g., if the link already exists) or whether the operation is reversible. It provides some transparency but lacks full detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences and an API call reference. However, the first sentence 'Link service.' is redundant given the title and second sentence. It is efficient but contains a minor repetition, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple linking operation with two parameters and no output schema, the description covers the primary purpose and effect. However, it omits details such as prerequisites (e.g., service must exist), error handling, or confirmation of the operation. The description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The tool description does not add any additional meaning beyond what the schema provides; it merely references the parameters without giving examples, constraints, or further semantics. Baseline score of 3 is appropriate as the description offers no extra value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Link', the resources involved (service to environment group), and the specific effect: access to environment variables and secret files. It also distinguishes the tool from its sibling 'render_unlink_service_from_env_group' and other linking operations by specifying the action and consequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the outcome of using the tool (service gains access to env vars/secret files) but does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions. While the purpose is clear, the lack of usage criteria or differentiation from similar tools limits the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it calls a GET endpoint, which is consistent and reinforces the non-destructive nature. No contradictions; the description provides minimal extra behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, focused and front-loaded with the action. However, the first sentence 'List events.' is slightly redundant with the second sentence. Could be more concise by combining them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and endpoint but does not explain return values or pagination behavior (though pagination parameters are described in the schema). For a simple list tool, this is adequate but lacks full completeness given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented in the input schema. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it lists events for a service, using the verb 'list' and specifying the resource ('events for the service with the provided ID'). It mentions the API endpoint. However, it does not explicitly distinguish from the sibling tool 'render_retrieve_event' which retrieves a single event, so it misses a slight differentiation opportunity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to list recent events for a service. There is no explicit guidance on when to use this tool versus alternatives like 'render_retrieve_event' or 'render_list_logs'. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it operates on logs matching filters and invokes a specific API endpoint, which is useful but not rich behavioral context. It does not mention pagination behavior, rate limits, or that unique values are returned. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main purpose. However, the first sentence 'List log label values' is redundant with the title and does not earn its place. The remaining sentences are concise and informative, making it almost ideal but with a minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain return values, and it lacks details about behavior such as whether it returns distinct values or how pagination works. However, the input schema is comprehensive (covering all 18 parameters with defaults and examples) and annotations cover side-effect transparency. The description provides adequate context for a basic understanding but is not fully complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so the baseline is 3. The description mentions 'given log label' and 'provided filters' but adds no additional meaning beyond the schema's detailed per-parameter descriptions. It does not explain parameter interactions or output format, and with 18 parameters, the schema carries the full semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all values for a given log label in the logs matching the provided filters.' It specifies the action (list), the resource (log label values), and the scope (matching filters), and distinguishes it from sibling tools like render_list_logs or render_list_application_filter_values by focusing specifically on label values. The mention of the API endpoint adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives or mention exclusions. It implies usage for discovering possible values of a log label, but it lacks clear guidance such as 'use this to enumerate filter values' or 'for listing actual logs, use render_list_logs instead.' Thus, usage context is only implied, not explicitly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint = false, indicating a safe read operation. The description adds the HTTP method and endpoint but no additional behavioral traits like pagination behavior or rate limits. With high annotation coverage, the bar is lower, but no extra context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the first sentence 'List secret files' is redundant with the title. It is front-loaded with the purpose, but could be slightly more concise. Overall, it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with pagination. The description omits details about pagination behavior (cursor/limit usage) and the response format. However, the schema provides links to pagination docs, and the tool's output is likely standard. Adequate but lacks completeness for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description does not add any meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List secret files for the service with the provided ID' and names the API endpoint. It uses a specific verb and resource, and distinguishes from sibling tools like `render_delete_secret_file` and `render_retrieve_secret_file`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to list secret files for a service) but does not explicitly state when not to use it or mention alternatives among siblings. Some implicit guidance exists, but no clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent behavior. The description adds the specific API endpoint (GET /disks/{diskId}/snapshots) and explains snapshots are point-in-time copies, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'List snapshots' appears twice. It could be more concise by removing the first sentence or merging it with the second. Information is front-loaded but not efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one required parameter and rich annotations, the description covers the purpose, resource, and API call. It does not mention response format or pagination, but these are not critical given the tool's simplicity and lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, diskId, is described in the schema as 'The ID of the disk'. The description adds no extra meaning, format, or examples beyond this. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (snapshots) and action (list), and clarifies it's for a persistent disk. However, it begins with a tautological 'List snapshots.' that repeats the title, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by requiring a disk ID but does not explicitly state when to use this tool over other list tools or provide alternative approaches. Given many sibling list tools, more guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which indicate a non-destructive, idempotent read operation. The description adds the API call path, confirming it's a GET request, but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. The first sentence is a direct statement of the purpose, and the second provides the API endpoint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description is adequate. It specifies the resource and endpoint. It could mention that the custom domain must belong to the provided service ID, but this is implicit from the API call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (serviceId and customDomainNameOrID). The description adds no extra meaning beyond the schema; therefore, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a specific custom domain for a specific service, which matches the verb 'retrieve' and resource 'custom domain'. It distinguishes from sibling tools like `render_create_custom_domain` and `render_list_custom_domains` by focusing on a single resource retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., listing all custom domains). The readOnlyHint and idempotentHint imply safe usage, but the description does not provide context-specific advice or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the HTTP method (GET) and endpoint pattern, which is consistent but does not disclose additional behavioral traits beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the first sentence is somewhat redundant with the name. It effectively communicates the core purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits details about the return value or response structure, which is important given no output schema. However, it does mention the API endpoint, providing some context. Overall, it is adequate but could be more complete for a retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described adequately in the schema. The description does not add any additional meaning or context beyond the schema's parameter descriptions, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a specific environment variable within a specific environment group. It distinguishes from sibling tools like render_retrieve_env_var (for service env vars) and render_delete_env_group_env_var by mentioning the specific scope and API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to retrieve an env var from an env group) but does not explicitly contrast with alternatives such as render_retrieve_env_var for service env vars or list tools for env group env vars. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so description adds only the API endpoint. No extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Slight redundancy: 'Retrieve registry credential' repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Does not describe return value or structure, which would be helpful given no output schema. Adequate for a simple GET call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, parameter described. Description adds no new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a registry credential by ID, explicitly cites the API call. Distinguishes from sibling tools for create/update/delete registry credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives, but the name and operation make it obvious. Lacks comparison to other retrieve tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the HTTP method (GET) and mentions the API call, which aligns with annotations but does not significantly extend behavioral disclosure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences but the first sentence repeats the title. While concise, it could be more efficient by merging into a single sentence. Still, it is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with no output schema, the description covers purpose and API endpoint. However, it does not mention what the response contains, which could be helpful given no output schema. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for serviceId with a clear description. The tool description does not add additional meaning or context beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a service by ID and explicitly mentions the API endpoint (GET /services/{serviceId}), distinguishing it from sibling retrieval tools like render_retrieve_deploy or render_retrieve_postgres.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a service by ID but does not explicitly state when to use it versus alternatives or provide any conditions or exclusions. No mention of 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds valuable context about SSE protocol, unidirectional stream, and timeout return behavior, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise (4 sentences) and front-loaded with purpose, but the first sentence redundantly restates the title. Structure is logical: purpose, protocol, client requirements, behavior, endpoint call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers streaming nature, protocol, and return behavior, but lacks details on timeout configuration, error handling, or how to close the stream. With no output schema, more context would improve completeness for an SSE tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for the single required parameter taskRunIds. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool streams realtime events (SSE) for task runs, specifying it establishes a unidirectional event stream and returns events before timeout. However, it does not explicitly differentiate from sibling streaming tools like render_subscribe_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides client guidance (setting Accept header, keeping connection open) and mentions timeout behavior, but lacks explicit instructions on when to use this tool versus alternatives like render_list_task_runs or render_subscribe_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description adds context: requires active service, PATCH endpoint, resize constraint. However, it does not disclose error conditions, partial update behavior, or side effects, especially given openWorldHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences + API endpoint) and front-loaded with the core action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and low schema coverage, the description leaves gaps: it does not explain return values, error scenarios, or whether updates to name/mountPath have constraints. The openWorldHint suggests undocumented side effects. More detail is needed for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%). The description adds specific meaning for sizeGB (resize constraint) and implies diskId usage. Name and mountPath remain unexplained. The added information is useful but insufficient to fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a persistent disk by ID, matching the tool name and title. It specifies the verb 'update' and the resource 'disk', and distinguishes well from sibling tools like render_add_disk or render_delete_disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a crucial prerequisite: the associated service must be deployed and active. It also includes a specific constraint for resizing (new size > current). However, it does not offer exclusions or compare to alternative operations, which limits guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. Description adds that this is a PATCH request (mutation). No additional behavioral details like authorization needs, rate limits, or side effects beyond the update. Adequate but minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences; first two are redundant ('Update project. Update the details of a project.'). Could be merged. The rest is useful. Slightly verbose but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has two parameters, no output schema, and simple function. Description covers purpose and basic distinction from sibling, but lacks parameter details, return value, and behavioral context. Sufficient for a simple update but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description provides no parameter explanations. The schema lists 'name' and 'projectId' but their meaning and usage are not clarified. Agent must infer from schema alone. Should have described required projectId and optional name update behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool updates a project, distinguishes from updating an environment with a sibling tool reference. Specific verb 'Update' and resource 'project' are used. The call to `PATCH /projects/{projectId}` reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (update project) and when to use an alternative (Update environment for environment updates). Provides a link to the endpoint documentation for context. No prerequisites or exclusions mentioned, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is non-readOnly, non-destructive, and open-world. The description adds the HTTP method (POST) and endpoint, which provides useful behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but slightly redundant (first sentence repeats the title). It could be more concise by merging the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic operation but lacks information about the response or prerequisites (e.g., service must exist). With no output schema, the agent might miss expected output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. It adds no additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Add' and the resource 'response header rule', and references the specific API endpoint. This clearly distinguishes it from sibling tools like render_list_headers or render_delete_header.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like render_update_headers or render_delete_header. The context is implied by the name and description, but no explicit when/when-not or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and destructiveHint=false, and the description mentions POST call implying mutation. However, no additional context about side effects, idempotency, or error handling beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences front-loading the action. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not mention return values or success indicators. For a simple creation tool, the missing output description leaves agents without expectations of response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with serviceId described; the 'name' parameter lacks description. The tool description does not clarify 'name' meaning (e.g., full domain string). Adequate but not compensating for missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool adds a custom domain to a service, specifies the REST API call, and distinguishes from siblings like render_list_custom_domains and render_delete_custom_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like listing or refreshing domains. The description implies usage when adding a domain but lacks when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, marking this as a mutation. The description adds only the endpoint call 'POST /redis' and the deprecation reason. It does not explain behavior such as synchronous vs asynchronous creation, resource provisioning details, or side effects beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the deprecation notice. However, it repeats 'Create Redis instance' and could be more structured (e.g., separating deprecation from action). Still efficient for the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters (including required ownerId and plan) and no output schema, the description is too sparse. It does not mention required parameters, default values, or the relationship to the Key Value API beyond naming it. The agent would need to inspect the schema independently for essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 63%, falling in a moderate range. The description provides no parameter-level details or context. The schema itself describes some parameters (name, ownerId, region, persistenceMode, maxmemoryPolicy) but the description adds no additional meaning. A score of 3 is appropriate as a baseline given the coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Redis instance, and explicitly calls out its deprecation and the alternative Key Value API. It distinguishes itself from siblings like render_create_key_value by marking itself as deprecated and directing users to the replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is deprecated and recommends using the Key Value API instead, providing clear when-to-use and when-not-to-use guidance. This effectively tells the agent to avoid this tool in favor of the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that deletion is irreversible and all data is lost, and it explicitly names the API endpoint called. This provides valuable context for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loaded with the core action. Every sentence adds value—action, irreversibility, API call. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive one-parameter tool with no output schema, the description covers the essential: what it does, the effect, and the API call. Minor missing items like error handling or prerequisites do not significantly harm completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain the 'postgresId' parameter beyond its name. No format, source, or validation details are given, which is a gap for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete Postgres instance' and specifies the operation is irreversible and all data will be lost. It uses a specific verb+resource and distinguishes from siblings like render_suspend_postgres or render_create_postgres.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. While it warns of irreversibility, it does not mention alternatives like suspend or failover, nor any prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds the API endpoint but doesn't disclose behavioral traits beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. Minor redundancy ('Retrieve task' then 'Retrieve the workflow task') but no wasted words. Acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with full schema coverage and annotations, the description is sufficient. It explains what it does and the API call, though no output details are expected. Complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (taskId) with a clear description. The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('task'), clarifies it's a workflow task, and distinguishes from sibling tools like 'render_get_task_run' and 'render_list_tasks' by focusing on a single task retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single task by ID but lacks explicit guidance on when not to use or alternatives (e.g., listing tasks). The context is clear but no exclusions or comparisons are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds the API endpoint but does not disclose error behavior or rate limits. The combination is sufficient but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action. The first sentence repeats the title, which is slightly redundant but acceptable. Overall concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and good annotations, the description is adequate. It provides the endpoint and confirms the purpose. No output schema exists, so the description does not need to explain return values, but it could mention what is returned. Still, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes taskRunId as 'The ID of the task run' (100% coverage). The description adds no additional meaning beyond what is in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and the resource ('task run'), and specifies it retrieves a specific one by ID. It also mentions the API endpoint, making the purpose unambiguous and distinguishing it from list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance versus siblings like 'list_task_runs' or 'get_task'. However, the name and description imply it is for fetching a single task run by ID, which is adequate but could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safety. The description adds the HTTP GET endpoint but does not elaborate on other behavioral aspects like pagination or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains slight redundancy ('List instances' repeated). It is front-loaded with the purpose but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is adequate. It states the purpose and the API call, though it omits potential details like response structure or permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single 'serviceId' parameter with a description. The description does not add significant meaning beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists instances for a given service, using a specific verb and resource. It distinguishes itself from siblings like render_list_services or render_list_deploys by focusing on 'instances' for a specific service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing instances of a service but lacks context like prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the API endpoint and clarifies that events are retrieved for a specific webhook with optional time filters, which aligns with and slightly extends the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant text. The API endpoint is included efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain return values or structure. However, for a simple list tool with good annotations, it is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions 'optional filtering by timestamp' but does not add syntax or format details beyond what the schema provides for parameters like sentAfter/sentBefore.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (list), resource (webhook events), and includes optional filtering by timestamp, making it distinct from sibling tools like render_list_webhooks (lists webhooks) and render_retrieve_webhook (single webhook details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. It does not mention exclusions or comparison to other list tools like render_list_events, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which convey safety. The description adds the API endpoint call but no additional behavioral context such as error handling, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences front-load the action and specify the API call. No unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description explains the core function and the underlying API call. Missing are details on return value structure (no output schema) and potential error conditions, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage but the description for envGroupId ('Filter for resources that belong to an environment group') is misleading for a retrieval operation. The tool description does not clarify this, relying on an inaccurate schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve an environment group by ID,' specifying the verb (retrieve) and resource (environment group) with a concrete method (by ID). This distinguishes it from sibling tools like render_list_env_groups and render_create_env_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only states the action and HTTP method; no comparison to render_list_env_groups or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint= false. The description adds the HTTP method and exact endpoint, which confirms the read-only, idempotent nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately convey the purpose and API call. No wasted words; front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with annotations covering safety, the description provides the endpoint. It lacks explanation of return values (no output schema) but is adequate for a straightforward retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description mentions 'with the provided ID' but does not explain the format or constraints of environmentId. For a single simple parameter, this is minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves an environment by ID, and specifies the exact REST endpoint. This distinguishes it from list (render_list_environments), create, update, and delete sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like render_list_environments or other retrieve tools. It simply states the action without context about prerequisites, filtering, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint; description adds the specific HTTP method (GET) and resource path, confirming it's a safe retrieval operation without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point, but the first sentence is somewhat redundant (repeats title). Could be tightened into one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no indication of what the response contains. For a retrieval tool, knowing the returned fields would help. Annotations partially compensate but not fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description mentions 'by ID' but does not explain what redisId means or provide any additional semantic context beyond the schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a Key Value instance by ID, specifying the exact API endpoint. Distinguishes from list/create/delete siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like render_retrieve_redis or render_retrieve_key_value_connection_info. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, so the description need not repeat that. It adds the API call detail but does not explain effects (e.g., data persistence, resumability). Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first declares purpose, second provides API endpoint. Efficient and front-loaded, no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose and endpoint. Missing usage guidance, but overall sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 the parameter name 'redisId'. While the parameter is self-explanatory, the description should compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it suspends a Key Value instance by ID and specifies the API endpoint. It is distinct from sibling tools like render_delete_key_value (deletion) and render_resume_key_value (resume).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when suspension is needed, but lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond annotations. Annotations already indicate idempotentHint=true and destructiveHint=false. The description mentions the HTTP PUT method, which aligns with idempotency, but does not disclose side effects, error conditions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences. Each sentence serves a purpose: stating the action, clarifying the scope, and specifying the API call. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (one required) and no output schema, the description lacks details about return values, error handling, and prerequisites (e.g., workspace existence). However, annotations fill some gaps, and the schema covers parameter descriptions, resulting in adequate but not complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. The description does not provide any additional meaning beyond the schema's parameter descriptions, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create or update metrics stream' and specifies that it operates for the specified workspace. The API endpoint is provided, making the action unambiguous and distinct from sibling tools like get or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., get or delete metrics stream). It is implied by the 'upsert' nature, but no when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the description's mention of cancellation adds no new safety info. It does add the cron job exclusion and the API endpoint, which are useful externally but do not deepen understanding of side effects or behavior beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at three sentences, but the first sentence ('Cancel deploy.' is redundant given the title. The remaining sentences are clear and front-loaded. Could be slightly more concise by removing the first sentence, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no output schema, the description explains the action and the limitation but fails to mention the result (e.g., what is returned) or whether cancellation is immediate or asynchronous. Given the presence of sibling tools like 'render_wait_for_deploy', more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add any additional meaning to the parameters beyond what the schema already provides ('The ID of the deploy' and 'The ID of the service'). Following the guidelines, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels an in-progress deploy for a service, with the specific verb 'cancel' and resource 'deploy'. It also notes it's not supported for cron jobs, which distinguishes it from the sibling tool 'render_cancel_cron_job_run'. The API call is given, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use (cancel an in-progress deploy) and when not (not for cron jobs). While it doesn't explicitly name an alternative like 'render_cancel_cron_job_run', the sibling tool exists and the exclusion implies it. Slight improvement would be to mention the alternative directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds the API call but no additional behavioral details (e.g., permissions, error handling). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with the action and resource. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete with no output schema, the description is mostly adequate. Could be improved by noting that the operation is idempotent (already hinted) and what happens if the variable doesn't exist, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only envVarKey has description). The description mentions both parameters via the API path but does not explain envGroupId (how to obtain it) or add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (environment variable from environment group), and the API endpoint. It distinguishes from siblings like render_delete_env_var by specifying 'from a particular environment group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for environment group-scoped variables but does not explicitly state when to use this tool over alternatives like render_delete_env_var or render_delete_env_group_secret_file. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true and idempotentHint=true, so the description's mention of calling DELETE API adds minimal extra transparency. No additional behavioral traits (e.g., irreversibility, side effects) are described beyond what is in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loaded with the main action, and contains no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, annotations present, and no output schema, the description provides sufficient information. It could optionally note the response behavior (e.g., no content), but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the sole parameter 'ownerId'. The description essentially repeats schema info ('for the specified workspace' maps to 'ownerId'), adding no new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete log stream' and specifies the resource and action. It mentions the specific API endpoint, and from sibling tool names it's evident this is distinct from other log stream operations like 'render_get_owner_log_stream' and 'render_update_owner_log_stream'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as 'render_delete_resource_log_stream' or other delete tools. The usage is implied by the tool name and description ('for the specified workspace'), but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and idempotent. The description adds valuable behavioral details: the prerequisite that environments must be empty, the 409 failure response, and workarounds for non-empty projects. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a one-sentence summary followed by a condition, failure detail, and workarounds. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description is comprehensive. It covers prerequisites, failure scenarios, and alternative actions. Minor omission: no mention of return behavior or what happens on success (e.g., returns 204).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions 'with the provided ID' but does not explain the format, validation, or source of projectId. This is insufficient compensation for the lack of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool deletes a project and specifies it by ID. It distinguishes itself from sibling deletion tools by focusing on project-specific requirements, but does not explicitly name alternatives like render_delete_service or render_delete_environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool: when you want to delete an entire project, with the condition that all environments must be empty. It also offers alternatives for non-empty projects (manual cleanup or Dashboard), adding practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, which the description reinforces by stating 'Delete'. The description also adds transparency by revealing the exact API endpoint called (DELETE /services/{serviceId}/routes/{routeId}). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences), but the first sentence ('Delete redirect/rewrite rule') is redundant with the title. It earns its place by adding the second sentence about the API call, though overall structure is efficient but slightly repetitive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters, the description covers the action and the API endpoint. Annotations fill in idempotency and destructiveness. No output schema is needed. However, it does not mention prerequisites (e.g., route must exist) or error handling. Still, it is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (routeId, serviceId) are 100% covered in the input schema with descriptive names and descriptions. The description's mention of 'a particular redirect/rewrite rule for a particular service' adds minimal semantic value beyond the schema. Schema coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Title and description clearly state the tool deletes a redirect/rewrite rule. The specific verb 'Delete' and resource 'redirect/rewrite rule' are used, and the description distinguishes from sibling tools like render_add_route and render_put_routes by focusing exclusively on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool is used to delete a particular route for a particular service, which implies the context of use. However, it does not provide when-not-to-use guidance or mention alternatives (e.g., use render_patch_route for updates or render_disable_route). No explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true, and the description adds the API endpoint. However, it does not elaborate on side effects or permissions beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient and front-loaded with the action. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one required parameter and no output schema, the description is sufficiently complete. It could mention irreversibility but annotations partially cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description and example for webhookId. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a webhook' and specifies the action with the provided ID. It distinguishes itself from sibling tools like create, list, update, and retrieve webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when to use this tool vs. alternatives. The name implies usage for deleting a webhook, but no guidance on prerequisites or conditions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the API endpoint (GET /metrics/active-connections) but does not cover other behavioral aspects like authentication requirements, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with two sentences: one stating the purpose and the second providing the API endpoint. No redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only metric retrieval tool with good annotations and full schema coverage, the description is largely sufficient. It lacks information about the return shape (since no output schema) but the task is simple enough. Minor gaps like default time ranges are documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all 4 parameters with descriptions and examples. The tool description does not add any additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'active connection count', and clarifies it applies to Postgres or Redis instances. It distinguishes from sibling tools that retrieve other metrics (e.g., CPU, memory) or perform mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when querying active connections for supported databases but does not explicitly state when to use this tool versus alternatives like render_get_cpu or render_get_memory. No exclusion or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds the API endpoint and mentions 'persistent disk usage', but no additional behavioral traits like rate limits or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of response format or pagination, but tool is straightforward read-only data retrieval. Annotations and completeness of schema compensate slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add extra meaning; it only states the API call. Parameters are well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'disk usage', specifying it can retrieve for multiple resources. Differentiates from sibling tools like render_get_disk_capacity and render_list_disks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives like render_get_disk_capacity or render_list_disks. Implied usage through parameter descriptions but lacks when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying the endpoint. No contradictions; the description reinforces the safe, read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but slightly redundant ('Retrieve workflow' repeated). The endpoint detail is useful and front-loaded. Minor waste in repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not mention what the response contains (e.g., workflow details). It also lacks error handling or permission context, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no extra meaning beyond the schema's parameter description. The phrase 'with the provided ID' merely restates the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve workflow' and specifies the API call, making it obvious that this tool fetches a specific workflow by ID. It distinguishes from siblings like 'render_get_workflow_version' and 'render_create_workflow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving workflows but does not explicitly state when to use this tool over alternatives or provide any conditions. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the API endpoint (GET) which aligns, but adds no new behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences with no wasted words. It front-loads the purpose and then adds filtering context and API endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the description lacks return value or pagination details. With 10 parameters and no output schema, it should explain common filter combinations or pagination behavior to aid agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description does not add any parameter-specific meaning beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List deploys' and mentions filtering, which distinguishes it from sibling list tools for other resources. The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: 'If no filters are provided, all deploys for the service are returned.' This tells when to use the tool. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description merely mentions the GET endpoint, adding minimal behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and reinforce the action. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not specify the return format or type. It also omits guidance on parameter combinations despite 7 available parameters. This leaves gaps for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra parameter semantics. The baseline score of 3 is appropriate as the schema already fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List queryable status codes and host values' and mentions the specific API endpoint. It distinguishes from sibling tools like render_list_application_filter_values by focusing on HTTP metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining filter values for HTTP resources but does not explicitly state when to use this tool versus alternatives like render_list_path_filter_values. However, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it calls GET /key-value on the Render Public API, which confirms the read-only nature and provides the HTTP method. This adds useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the purpose and key behavior. Every sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough given the rich input schema (100% coverage) and the fact that this is a straightforward list operation. While it does not describe the return format, the agent can infer that it returns a list of key-value objects, and the operation is simple. The annotations cover safety aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides (e.g., filter by name, region, etc.). It only generally mentions 'matching the provided filters', which adds no new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists Key Value instances with optional filters, and falls back to listing all if no filters are provided. It specifies the API endpoint. However, it does not explicitly differentiate from the sibling 'retrieve' tool, though the verb 'list' vs 'retrieve' implies a collection vs single instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'if no filters are provided, all Key Value instances are returned', which implies the tool is for listing. It does not provide guidance on when to use this tool vs alternatives like 'retrieve_key_value' for a single instance, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it calls `GET /owners`, returns workspace IDs, and is the intended mechanism for discovering which workspace to set as RENDER_WORKSPACE_ID. This goes beyond the annotations with practical insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly efficient but opens with a redundant 'List workspaces.' that restates the title and the immediately following sentence. The 'Usage:' section adds value, but the first sentence could be removed. Overall, it is slightly repetitive but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description provides sufficient context: what it lists, optional filters, the endpoint, and how to use the result (setting RENDER_WORKSPACE_ID). It does not detail pagination behavior, but the schema documents the `limit` and `cursor` parameters, so this gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the parameters are fully documented. The description adds minimal extra meaning by mentioning optional filtering by name or owner email, but this is already implied by the schema. No additional semantics are provided for `limit` or `cursor` beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists workspaces accessible by the API key, optionally filtered by name or owner email. It identifies the specific resource (workspaces) and endpoint (`GET /owners`), which distinguishes it from other list tools in the sibling list. However, it does not explicitly differentiate itself from sibling tools like `render_list_projects` or `render_retrieve_owner`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool returns workspace (`tea-…` ids) your API key can reach, and advises setting RENDER_WORKSPACE_ID so other tools needing an `ownerId` stop asking. This is actionable usage guidance, though it does not mention when not to use it or name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it calls GET /postgres, which aligns with these annotations and provides minor additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, but the first two sentences repeat 'List Postgres instances', which is slightly redundant. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 12 parameters with full schema coverage and no output schema, the description is adequate but could mention the return format (list of Postgres instances) for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already well-documented in the schema. The description does not add extra meaning beyond mentioning 'filters' generically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Postgres instances and distinguishes from sibling tools like render_create_postgres and render_retrieve_postgres by focusing on listing with optional filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that filters are optional and all instances are returned if none are provided, but does not explicitly state when to use alternatives like render_retrieve_postgres for single instance retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe, read-only, and idempotent nature of the tool. The description adds the API endpoint called but does not disclose any additional behavioral traits (e.g., whether results are paginated, any rate limits, or potential errors). The extra context is minimal, leaving the description adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with three sentences, but the first two are slightly redundant. Overall, it is front-loaded with the core purpose and efficiently conveys the necessary information without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description adequately covers purpose and parameter. However, it does not hint at the return format (e.g., a list of objects with names and sizes), which would improve an agent's understanding of the output. The openWorldHint annotation partially mitigates this, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains that 'postgresId' identifies the Postgres instance, adding meaning beyond the bare schema. For a single parameter, this is sufficient, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resources ('database, table, and index sizes') and specifies the target ('on a Postgres instance by ID'). It distinguishes the tool from siblings that list other Postgres attributes (e.g., processes, table scans, top queries) by focusing exclusively on sizes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving size information but provides no explicit guidance on when to choose this tool over alternatives, nor does it mention any prerequisites or exclusions. The purpose is clear, but the lack of comparative context limits its helpfulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructively false, so the safety profile is clear. The description adds the API endpoint detail, which is extra useful context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant information. Efficiently conveys purpose and API endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about return format (list of users/credentials) and potential pagination. Despite annotations, the description could be more complete for a list operation without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate, but it only mentions 'with the provided ID', which adds minimal meaning beyond the schema's type: string. No format, validation, or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists PostgreSQL users for a specific Postgres instance, using a specific API call. This distinguishes it from siblings like render_list_postgres (list instances) and render_create_postgres_user (create user).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing users, but does not explicitly state when to use it versus alternatives or provide any exclusion criteria. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds the API call detail and no-filter behavior, but no new behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with three short sentences, though slightly repetitive ('List projects' appears twice). Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not specify return structure. While implied by name, could be more complete for a list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not elaborate on parameter usage beyond what schema provides, only mentions 'matching filters' generically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists projects and describes filtering behavior. Distinguishes from sibling tools like render_retrieve_project and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for listing projects with optional filters. Does not mention alternatives but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is mutating and not destructive. The description adds the condition (only if suspended) and the endpoint, but lacks details on side effects, permissions, or error states. It provides some additional context but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: the first sentence 'Resume service' restates the title. The second and third sentences are useful. Could be more concise by merging.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the purpose, condition, and API call. It is sufficiently complete given the low complexity, though it could mention the expected state after resumption.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for 'serviceId'. The tool description does not add any new meaning or context beyond what the schema already provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume'), the resource ('service'), and a key condition ('if it's currently suspended'). It distinguishes itself from sibling tools like render_suspend_service (opposite) and render_restart_service (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition ('if it's currently suspended'), guiding when to use the tool. However, it does not explicitly list alternatives or state when not to use it, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the API call method (GET) and confirms the retrieval action, which aligns with annotations (readOnlyHint, idempotentHint). However, it does not disclose any additional behavioral traits such as rate limits or authentication requirements, but annotations sufficiently cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action, and includes the API endpoint. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is adequate. It clearly states the operation and the API call. The lack of description about the return value is acceptable given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'dedicatedIpId'. The description does not add any extra information beyond what the schema provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve dedicated IP set' and specifies retrieving by ID. It distinguishes from sibling tools like render_list_dedicated_ips, render_create_dedicated_ip, etc., which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a dedicated IP ID and need its details, but it does not explicitly state when to use this tool over alternatives like listing or creating. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds the scope constraint about direct service variables, which is useful but not extensive. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, with the first sentence repeating the title. It could be more concise by merging the first two sentences. However, overall it is short and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two parameters and no output schema, the description explains what is retrieved, the scope, and the API endpoint. Annotations cover safety. It is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (envVarKey and serviceId) having clear descriptions. The description does not add additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve', the resource 'environment variable', and specifies 'for a particular service', distinguishing it from retrieval of environment group variables. Sibling tools include 'render_get_env_vars_for_service' (list all) and 'render_retrieve_env_group_env_var', so this tool's purpose is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that this tool only applies to environment variables set directly on the service, not in a linked environment group. This provides clear context on when to use and when not, but does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds the specific API endpoint, but does not elaborate on behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but slightly redundant ("Retrieve event. Retrieve the details..."). It could be tightened to a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema), the description provides necessary context: purpose and API endpoint. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning to the eventId parameter beyond what the schema's description already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves details of a particular event, using a specific API call. It distinguishes from sibling tool render_list_events by targeting a single event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving event details, but does not explicitly contrast with alternatives like render_list_events. However, given the sibling name, the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the create behavior is known. The description adds the API call detail and a key caveat: the connection string is not returned by list/retrieve, requiring a separate credential lookup. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes redundancy: 'Create Key Value instance.' and 'Create a new Key Value instance.' say the same thing. The remaining sentences (API endpoint, Redis-compatible note, credential guidance) are useful, but the duplication pads the text unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not describe the return value or prerequisites for creating an instance. It provides useful context about credential retrieval and the Redis-compatible nature but falls short of explaining the full behavior of a create operation, such as what the response contains or what resources are provisioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, with descriptions for name, region, maxmemoryPolicy, persistenceMode, and ipAllowList. The description adds no parameter-specific guidance and does not compensate for undocumented parameters like plan and environmentId. It neither clarifies nor obscures, thus meeting baseline but not adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Create a new Key Value instance.' It also specifies the API endpoint (POST /key-value) and differentiates from siblings by explaining that Key Value is Render's Redis-compatible store superseding deprecated Redis endpoints, which is a unique resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives usage context: 'Key Value is Render's Redis-compatible store and supersedes the deprecated toolset's Redis endpoints,' indicating it should be used over deprecated Redis tools. It also provides a follow-up action: read credentials with render_retrieve_key_value_connection_info since the connection string is not returned by list or retrieve. However, it lacks explicit exclusions or alternatives beyond the deprecated toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the destructive nature is clear. The description adds the HTTP method and endpoint (DELETE /registrycredentials/{registryCredentialId}), providing API-specific context. No additional behavioral traits (e.g., permanence, auth needs) are disclosed, but it is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, clear and direct. The first sentence states the purpose, and the second repeats with the API call. Minor redundancy but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, destructiveHint annotation), the description sufficiently covers the action and endpoint. It lacks prerequisites or side effects, but the annotations fill some gaps. Adequate for expected complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (registryCredentialId) described as 'The ID of the registry credential.' The description adds 'with the provided ID' but does not enhance meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'registry credential', matching the tool name. It differentiates from sibling tools like render_create_registry_credential, render_update_registry_credential, and render_retrieve_registry_credential by specifying the deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide guidance on when to use this tool versus alternatives. It only describes the deletion action without mentioning exclusions or related operations like update or create. Use context is implied by the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds specific context: it stops syncing via `render.yaml` and does not delete managed resources, clarifying the scope of the destructive action. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are relatively concise, but the first sentence ('Disconnect Blueprint') is redundant with the title. The structure is clear: purpose, effect, and API route.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description provides sufficient context: what it does, what it does not do, and the underlying API call. Could optionally mention idempotency but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter blueprintId has 100% schema coverage with its description. The tool description adds no further meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Disconnect Blueprint' stops automatic resource syncing, clearly differentiating it from sibling tools like render_list_blueprints, render_update_blueprint, and render_delete_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for stopping syncing but does not explicitly state when to use it versus alternatives. It mentions that it does not delete resources, offering indirect contrast, but lacks clear when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds the API call path, which provides useful context. No additional behavioral quirks are disclosed, but the annotations suffice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences. The first sentence states the purpose directly, and the second adds the API endpoint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description is somewhat incomplete. It does not describe the structure or format of the returned latency data, leaving the agent to infer from the parameter names. The annotations cover safety, but the description could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters are fully described in the schema (100% coverage). The description mentions 'one or more resources' which adds minimal context about the resource parameter, but does not provide significant additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves HTTP latency metrics for resources, and explicitly mentions the API endpoint. It distinguishes itself from sibling tools like render_get_http_requests by focusing on latency rather than request counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only states its function without explaining when it is appropriate or when other metrics tools might be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds behavioral context such as the filtering behavior and the specific API endpoint (GET /env-groups). This goes beyond annotations by clarifying the HTTP method and that results vary based on filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each contributing value: purpose, filter behavior, and API call. The first sentence is slightly redundant (repeats title) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the filtering logic and API method. It could mention the return format (array of env group objects) but is sufficient for a list operation with 9 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described in the input schema. The description does not add new semantic meaning beyond 'matching the provided filters'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'List' and the resource 'environment groups', and adds specificity about filters and default behavior (all if no filters). It clearly distinguishes from sibling tools like 'render_retrieve_env_group' by indicating it's a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (listing env groups with filters) but does not explicitly state when to use this tool vs alternatives. No when-not or alternative tool mentions, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by disclosing that suggestions are based on the most recent 5000 log lines and calls a specific API endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the action and including necessary context without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides adequate context for a simple list operation, but lacks details on the return format or pagination. Given no output schema, more completion would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description does not add additional parameter-level information beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List queryable paths' and explains that suggestions are based on recent log lines and a specific API endpoint. This distinguishes it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving path suggestions based on filters but does not explicitly state when to use this tool over alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds value by specifying the underlying API call (GET /registrycredentials) and the permission-based scoping (credentials you have permissions to view), which provides additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (the first two sentences essentially restate the same idea). While it is not overly long, the structure could be tightened to remove redundancy. The key information is present but could be presented more efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters (including pagination-related ones) and no output schema, the description adequately covers the filtering behavior but does not explain pagination limits or the structure of the response. For a listing tool, mentioning pagination or linking to the API docs would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning each parameter is already well documented in the schema. The description does not add further parameter-level guidance beyond stating that filters are available. The baseline score of 3 is appropriate as the description does not compensate for any missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: listing registry credentials with optional filters. It uses a specific verb ('list') and resource ('registry credentials'), and explicitly distinguishes from related siblings like render_create_registry_credential and render_retrieve_registry_credential by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to list credentials, with or without filters) and notes that unfiltered calls return all viewable credentials. However, it does not explicitly state when not to use it (e.g., for retrieving a single credential) or mention alternatives like render_retrieve_registry_credential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds context that overrides take precedence over the default log stream, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but the first sentence redundantly restates the title. It frontloads the key action and includes relevant context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters all documented in schema and rich annotations, the description explains the tool's function and relationship to default streams. No output schema, but the return type (list of overrides) is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description does not add additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists log stream overrides for a workspace, distinguishing them from the default log stream. It includes the API endpoint, which reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to list overrides with filters, but does not provide guidance on when to use this tool versus alternatives like render_get_resource_log_stream or render_update_resource_log_stream.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the deprecation status and the exact API call (GET /redis/{redisId}), which provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the deprecation warning. It efficiently conveys purpose, deprecation, and API call. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter input and no output schema, the description adequately covers purpose and usage. However, it lacks details about the response structure or any edge cases, which could help an agent fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, redisId, has no schema description (0% coverage). The description merely says 'by ID' without specifying format, source, or constraints. This adds minimal meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve a Redis instance by ID'. It also notes deprecation and provides the API endpoint. This distinguishes it from sibling retrieve tools by specifying the resource (Redis) and the method (by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is deprecated and suggests using the Key Value API as an alternative. This provides clear guidance on when not to use it. However, it does not elaborate on specific scenarios where this tool might still be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true. Description adds deprecation context but does not detail consequences beyond the API call. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loaded with deprecation warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given deprecation and low complexity, the description adequately covers purpose and alternative. Lacks return value info, but no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (redisId) with 0% schema coverage. Description only says 'by ID' without explaining how to obtain the ID or its format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it suspends a Redis instance and is deprecated. The action and resource are explicit, and the deprecation distinguishes it from active tools like render_create_redis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly marks the tool as deprecated and recommends using the Key Value API instead, providing clear guidance on when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: explains that omitted fields are unchanged, and gives a specific example for scope switching. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Mostly concise with four sentences, though the first two sentences are redundant. Focused on essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, and usage example. Does not emphasize the required parameter (dedicatedIpId) but is otherwise complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema coverage, the description partially compensates by stating optionality and giving an example for environmentIds, but lacks detailed semantics for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update dedicated IP set', specifying the verb and resource. It distinguishes itself from sibling tools like create_dedicated_ip and delete_dedicated_ip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on optional fields and a specific use case for switching scope, but lacks explicit when-to-use or when-not-to-use compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and readOnlyHint=false, so the description adds minimal behavioral info beyond the underlying PUT API call. No contradictions, but little added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Front-loaded with action and then scoping constraint + API reference. Every sentence adds unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, scope, and underlying API endpoint. Lacks detail on return value or behavior (e.g., whether update is merge or replace), but no output schema exists. Adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; every parameter is described. The description does not enrich parameter meanings (e.g., what format 'content' should be). Baseline score of 3 applies since no additional semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (add or update) and resource (secret file for a service). Distinguishes from siblings by specifying it applies only to files set directly on the service, not those in linked environment groups. Unique among sibling tools like render_delete_secret_file and render_update_secret_files_for_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (for secret files directly on a service) and when not (for files in linked environment groups). Does not explicitly list alternative tools but the scope limitation guides correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, so the destructive nature is known. The description adds the HTTP method (POST) and endpoint, which provides implementation context. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no unnecessary words. It is front-loaded with the title and then adds the API call detail. Could be slightly more compact but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain return values or behavior (e.g., whether it's async, prerequisites like job must be running). For a simple mutation with two required params, it is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action of canceling a running job for a specific service using the verb 'cancel' and resource 'job'. It specifies that it's for one-off jobs, distinguishing it from sibling tools like render_cancel_cron_job_run, render_cancel_deploy, and render_cancel_task_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates use for canceling a particular one-off job for a particular service. While not explicitly stating when not to use or mentioning alternatives, the clarity of the action and resource, combined with the sibling tool names, gives reasonable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses that the generated password is only visible in the creation response, which is critical for credential management. It also names the HTTP POST method, implying a non-idempotent create operation with side effects. This adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences ('Create Postgres instance. Create a new Postgres instance.') are redundant and could be condensed into one. The remaining sentences are information-dense and useful, covering the API endpoint, version usage, plan source, and password behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, nested objects, no output schema), the description highlights essential gotchas (version, plan source, password visibility) but does not explain return structure, asynchronous creation behavior, or external side effects. It is adequate as a minimum viable description but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 47%, so the description compensates for a few critical parameters: version format ('major version as a string e.g. "16"') and plan/disk size sourcing from render_list_postgres_sizes. However, most parameters (e.g., ipAllowList, readReplicas, environmentId) receive no additional explanation in the description, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create Postgres instance') and the underlying API call (`POST /postgres`). It is distinct from sibling create tools like render_create_redis or render_create_service. The redundancy in the first two sentences is a minor stylistic issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it specifies that `version` is a major version string, references render_list_postgres_sizes for plan/disk size selection, and advises using render_retrieve_postgres_connection_info for credentials afterward. It does not explicitly state when not to use the tool, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and not read-only. The description adds crucial behavioral details: all data on the disk will be lost and the service immediately loses access. This goes beyond the annotations by specifying the exact consequences of the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each delivering key information: purpose, critical warning, and API call. No unnecessary words. The structure is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema), the description sufficiently covers the tool's behavior. It explains the effect on disk and service, and references the API endpoint. While it does not specify the return format, for a delete operation this is acceptable as typical REST responses are well-known.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'diskId', including an example and pattern. The description does not add additional meaning beyond referencing the disk ID. Baseline 3 is appropriate as the schema provides sufficient information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete disk' with a specific verb and resource. It expands on the purpose by clarifying it is a persistent disk attached to a service, distinguishing it from other delete tools for different resources. The mention of the REST API endpoint further solidifies the tool's action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives (e.g., other delete tools or update disk). It does imply usage context by noting that the disk is attached to a service and that data will be lost, but does not provide prerequisites or scenarios where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, and the description aligns by noting it calls a DELETE endpoint. It adds the specific API call detail, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose, and the second provides the API endpoint. No unnecessary words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a delete tool with two parameters and no output schema. It covers purpose, resource, and the API call. Minor missing details like return status or prerequisite checks are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter having a description. The tool description adds no additional meaning beyond repeating the parameter names in the endpoint, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete header rule') and identifies the specific resource ('response header rule') and its association with a service. It also provides the exact API endpoint, differentiating it from other delete tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting a header rule but does not explicitly state when to use it versus alternatives like render_update_headers or render_add_headers. No exclusion criteria or comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint. The description adds value by specifying the post-deletion behavior (fallback to default workspace log stream) and calls out the exact API call. This goes beyond the annotations, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: action, effect, API call. Front-loaded with key information, no redundant words. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main effect and API endpoint. No output schema exists, and the description does not mention return type or error cases. However, with annotations (idempotent, destructive) and the simple nature of a delete, it is reasonably complete. Missing explicit idempotency note, but annotation covers it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes the resourceId parameter. The tool description's phrase 'for the specified resource' does not add significant meaning beyond the schema. The schema's parameter description says 'returned' which is slightly off for a delete, but that is a schema issue, not in the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete log stream override') and the resource ('log stream override for the specified resource'), with a specific consequence ('resource will use workspace's default'). This distinguishes it from siblings like render_delete_owner_log_stream and render_update_resource_log_stream. The inclusion of the API endpoint adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource and effect, but does not explicitly state when to use this tool versus alternatives (e.g., render_delete_owner_log_stream) or provide prerequisites. The context is clear but no direct guidance on decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral context beyond annotations: data is available from March 9, 2025 onwards, queries for earlier dates return a 400 error, and it returns hourly data points. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 5 sentences, with the main purpose stated upfront. Each sentence adds value, and it avoids redundancy with the schema. Minor improvement could combine the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key behavioral aspect (date availability) and mentions the API endpoint. However, with no output schema, it could describe the return structure (e.g., fields in hourly data points) or pagination behavior. It is minimally adequate for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal extra meaning beyond the schema. It mentions 'one or more resources' (relating to the `resource` parameter) and the date constraint affecting `startTime`/`endTime`, but does not elaborate on formats or provide significant enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: get bandwidth usage breakdown by traffic source. It specifies the traffic sources (HTTP, WebSocket, NAT, PrivateLink) and mentions hourly data points, distinguishing it from the sibling tool `render_get_bandwidth` which likely provides total bandwidth without breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it's for retrieving bandwidth usage broken down by traffic source for one or more resources. It mentions the date constraint and error for earlier queries, but does not explicitly compare with alternative tools like `render_get_bandwidth` or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds value by specifying the API endpoint (GET /blueprints) and the workspace filtering logic, but does not disclose rate limits or auth requirements. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences that cover the purpose, behavior, and API call. Every sentence contributes meaningful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with good annotations and well-documented parameters, the description is sufficient. It explains the workspace filtering logic and API endpoint. However, it could explicitly mention that results are paginated, though pagination parameters hint at this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all three parameters (limit, cursor, ownerId). The description does not add any additional parameter semantics beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists blueprints for specified workspaces, using the verb 'List' and resource 'Blueprints'. It distinguishes from sibling tools like render_retrieve_blueprint (singular) and render_list_blueprint_syncs (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior (returns all blueprints if no workspaces provided), giving context on when to filter. It implicitly differentiates from other list tools by focusing on blueprints, but does not explicitly mention when to use alternatives like render_retrieve_blueprint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, etc. The description adds the API endpoint and filtering behavior, but no additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main filtering behavior well, mentions API endpoint. Does not explain pagination beyond schema parameter descriptions, but for a read-only list tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage; description does not add meaning beyond filtering logic already implied by schema descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists custom domains and differentiates from sibling tools (create, delete, retrieve, refresh). It specifies the service association and optional filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: requires serviceId and optional filters; explains behavior when no filters are provided. Does not explicitly mention alternatives but siblings make it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds that it uses GET and returns all environments when no filters are provided, which is useful but not extensive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description covers the main purpose and default behavior. It could mention pagination or return format, but overall it is fairly complete for a list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The tool description does not add additional meaning beyond the schema; it only mentions 'matching the provided filters' generically. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists environments, specifies scope (a particular project's environments), and distinguishes from sibling list tools by focusing on environments. It includes the API call, which reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to list environments of a project with optional filters. It does not explicitly state when not to use or provide alternatives, but the context is clear and not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the API method (GET) and reinforces that it's a read operation, but does not provide additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (3 sentences), front-loaded with 'List jobs', and each sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and filtering but does not mention the return type (list of job objects) or pagination details. For a tool with no output schema, a brief note on return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully describes all parameters. The description adds that no filters returns all jobs, which is useful but minimal. It does not go into parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists jobs for a service with filters, and it distinguishes from siblings like render_retrieve_job (single job retrieval). The verb 'List' and resource 'jobs' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that all jobs are returned if no filters are provided, and mentions the API endpoint. However, it lacks explicit guidance on when not to use this tool or compare to similar tools like render_list_services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds deprecation note but no behavioral details beyond annotations (readOnly, idempotent, etc.). Consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with deprecation, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers filtering and deprecation. No output schema, but pagination is in schema. Missing return format info, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with parameter descriptions. Description does not add meaning beyond 'matching provided filters'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List Redis instances' with filtering and all/filtered behavior. Distinct from siblings like create, update, delete, retrieve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions deprecation in favor of Key Value API, advising when not to use. However, no direct alternative tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the endpoint and default behavior but no additional behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no extra fluff. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and default behavior, but lacks description of the return format (e.g., paginated list) and does not mention that the response contains task definitions. Minor gap given the tool has no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the input schema (100% coverage), so the description adds no extra parameter meaning beyond what's already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'workflow tasks', and the scope (with filters or all). It distinguishes from siblings like render_list_task_runs (for task runs) and render_list_workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that no filters return all task definitions, providing clear context. However, it does not explicitly mention when not to use this tool or suggest alternatives like render_get_task for a single task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds that the tool calls GET /workflows and returns all accessible workflows, which aligns with annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the first sentence 'List workflows' is redundant with the title. The remaining content is concise and informative, including the API call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 6 parameters, the description covers scope and filter behavior but omits pagination hints and response structure details. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds general behavior about no filters returning all, but does not elaborate on individual parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists workflows, specifies filtering behavior, and mentions the API endpoint. It distinguishes from single-resource retrieval (render_get_workflow) and other list tools by name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that without filters all workflows are returned, giving a clear usage context. However, it does not explicitly exclude using alternatives like render_get_workflow for single workflows, though the distinction is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds value by stating the unsupported cron job case and referencing the exact API endpoint. It could further detail the impact on running instances or downtime, but overall it transparently communicates the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences) and front-loaded with the core action. Every sentence adds value: purpose, restriction, and API call. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers the essential aspects: action, restriction, API endpoint. The destructive nature is clear from annotations. It could mention service type applicability, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description ('The ID of the service'). The description provides no additional semantic context beyond what the schema already offers, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restart') and the resource ('service'), and distinguishes itself by noting it is not supported for cron jobs. The verb-resource combination is specific and unambiguous among the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the API call and that it is not supported for cron jobs, providing some usage context. However, it lacks explicit guidance on when to restart a service compared to other related actions like suspend, scale, or update, and does not state prerequisites or consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc. The description confirms it makes a GET request, but adds no additional behavioral context beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Front-loaded with 'Retrieve job', then immediate detail. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description includes the API call and required IDs. It lacks mention of the return format, but given it's a standard retrieval with no output schema, it is mostly complete. Slight gap in not describing what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented. The description does not add new meaning beyond the schema; it merely references serviceId and jobId via the endpoint. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve the details of a particular one-off job for a particular service'), identifies the resource (job for a service), and includes the exact API endpoint. It distinguishes from sibling tools like render_create_job and render_list_jobs by specifying 'particular' and 'one-off job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a serviceId and jobId. It provides clear context but does not explicitly state when not to use it or mention alternatives like render_list_jobs for listing jobs. However, the endpoint reference makes the usage straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the API endpoint and confirms it is a retrieval, but does not discuss pagination, rate limits, or authorization beyond what is implicit. Acceptable given annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one states the action, the other provides the API call. No extraneous information, front-loaded with the key purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no output schema, the description adequately covers what the tool does and how (API call). Could mention the return type (array of users) but not required. Overall, complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, ownerId, fully documented in the schema with description 'The ID of the team'. The tool description does not add additional meaning beyond referencing 'the provided ID'. With 100% schema coverage, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Lists workspace members' and 'Retrieves the list of users', with a specific verb (list/retrieve) and resource (workspace members). This distinctively separates it from siblings like render_remove_workspace_member or render_list_owners.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading workspace members. While it doesn't explicitly state when not to use, the context is clear and the sibling list provides differentiation. No alternative tools are named, but the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the HTTP method GET and endpoint path but no additional behavioral context beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first somewhat redundant, second clarifies, third provides API call. Efficient overall with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and good annotations, the description adequately covers the operation's purpose, input requirement, and API call. No missing context needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear parameter description. The description reiterates the parameter's purpose but adds the important nuance that it is a service ID, not an override ID. This is useful but not a deep semantic addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a notification override for a service, emphasizing that the service ID is used rather than an override ID. This distinguishes it from listing tools like render_list_notification_overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the input is a service ID, not an override ID, which helps avoid misuse. However, it does not contrast with alternatives (e.g., when to list vs retrieve).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive. The description adds the HTTP method (PATCH) and deprecation status but does not disclose additional behavioral traits such as required permissions, side effects, or whether the update is partial. It is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences that front-load the critical deprecation notice. Every sentence adds value without redundancy, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, deprecated), the description covers the core purpose and deprecation but omits necessary context like required permissions, return values, or update behavior. It is sufficient for a deprecated tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information beyond what the schema provides. With schema coverage at 50%, the description does not compensate for the missing details, leaving some parameters with no explanation. The description only restates the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'Redis instance', and explicitly distinguishes this deprecated tool from alternatives like the Key Value API. It also specifies the underlying API call, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that the tool is deprecated in favor of the Key Value API, providing a clear alternative and context for when not to use it. This satisfies the usage guidelines perfectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is not read-only and not destructive. The description adds value by explaining the redeployment requirement, which is behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient with two sentences: the first states the purpose, the second adds a key side effect and references the API endpoint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 required parameters and no output schema, yet the description does not elaborate on parameter meanings or what the response contains. It covers the main action and an important side effect but lacks completeness for a mutation tool with low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (2 of 5 parameters described). The description does not add meaning beyond the schema for the undocumented parameters (name, username, authToken). Given the low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update registry credential' and specifies the resource. It distinguishes from sibling tools like create and delete registry credentials by focusing on update and mentioning the need to redeploy services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context about when to use this tool by noting that services using the credential must be redeployed. While it doesn't list exclusions or alternatives, this guidance helps the agent understand the implications of the update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states 'without creating or modifying any resources', but the annotations specify readOnlyHint: false, which contradicts this read-only behavior. This contradiction severely undermines transparency despite the other behavioral details provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but every sentence carries useful information, from purpose to usage notes to API details. It is front-loaded with the core purpose and remains structured without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return value ('returns a plan indicating the resources that would be created'), and also covers request format, size limit, API endpoint, and usage positioning relative to sibling tools, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds valuable clarification about passing the file contents as text rather than a path, reinforcing the file parameter semantics beyond what the schema states. The ownerId parameter is already well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Validate a render.yaml Blueprint file') on a specific resource, and explicitly notes it does not create or modify resources. It also distinguishes itself from render_update_blueprint and render_retrieve_blueprint by describing the validation and plan-returning behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to validate before render_update_blueprint, provides clear usage instructions ('Pass the render.yaml contents as text in file — a path is not read for you'), and specifies the multipart/form-data content type and 10MB size limit, giving clear context for when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds the specific DELETE endpoint, confirming destructive behavior. No contradictions, and the context is sufficient for a simple delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Front-loaded with the action and resource, then adds the API call detail. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema, the description covers what it does, how to use it, and the underlying API. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter described as 'The ID of the service'. The description does not add any additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes the autoscaling config for a service using the service ID. It specifies the verb 'delete' and the resource 'autoscaling config', distinguishing it from sibling delete tools like render_delete_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to remove autoscaling from a service, but does not provide explicit guidance on when to use this vs alternatives (e.g., updating instead). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations by specifying that all contained variables and secret files are deleted, though no mention of reversibility or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear front-loading of the main action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter and no output schema, the description provides enough information to understand purpose and effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'envGroupId' is mentioned but not detailed (e.g., format, how to obtain). Schema coverage 0% means description should compensate, but it adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes an environment group, including all env vars and secret files, distinguishing it from sibling tools that delete individual items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage through bullet-level action description but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the API endpoint (GET /disks) and the default behavior (returns all disks you have permissions to view), which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (3 sentences) and front-loaded. The first sentence is redundant with the title, but overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 10 parameters and no output schema, the description explains default behavior and the API call. It could mention the return format (list of disk objects), but completeness is adequate given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 10 parameters. The description does not add extra parameter-level details beyond what the schema already provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'persistent disks', distinguishing it from sibling tools like retrieve_disk (single disk) and delete_disk (destructive). It also mentions the API call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that filters are optional and that without filters, all disks the user has permissions to view are returned. This gives clear context, but it does not explicitly compare to alternatives like retrieve_disk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, and non-destructive, and the description aligns by stating it returns rules. It adds behavior about default return of all rules when no filters are provided. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. It front-loads the action and efficiently covers key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with pagination parameters (cursor, limit) and no output schema, the description could mention pagination behavior or result format. While the API endpoint is given, the agent may need to know how to handle paginated results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions are already present. The description adds minimal extra meaning, only contextualizing that filters are optional. This doesn't significantly improve parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists header rules for a service with optional filters. The verb 'list' and resource 'header rules' are specific, and it differentiates from sibling tools like render_add_headers, render_update_headers, and render_delete_header by being a read-only operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to list header rules) and the effect of filters, implying usage context. It does not explicitly state when not to use or provide alternative tools, but the name and context are clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds the HTTP method (GET) and the specific API endpoint, which clarifies the underlying behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, no redundancy, and front-loaded with the core action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a list tool without an output schema, the description lacks details about pagination mechanics (though parameters mention cursor/limit) and return structure. The filtering behavior is well-covered, but completeness could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds some context about default behavior when no filters are applied, but does not add new information about individual parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'notification overrides', and distinguishes itself by specifying the filtering behavior and default return set. Siblings include 'patch_service_notification_overrides' and 'retrieve_service_notification_overrides', which are distinct operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that if no filters are provided, all overrides for all workspaces are returned. It does not explicitly mention when to use alternatives like 'retrieve_service_notification_overrides', but the context is clear for a list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description confirms a GET call and adds the data source (pg_stat_activity), but does not disclose further behavioral traits like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the first sentence restates the title. Overall, it is well-front-loaded and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description is fairly complete. It explains the resource, action, and API call. It could mention output format, but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, postgresId, is explained indirectly by the phrase 'on a Postgres instance by ID'. Despite 0% schema description coverage, the description provides enough context for the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists live queries, specifically currently running queries from pg_stat_activity, and mentions the exact API endpoint. This is specific and distinguishes it from sibling tools like render_list_postgres_top_queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing currently running queries on a Postgres instance, but does not explicitly compare with alternatives or state when not to use it. The use case is clear enough for an AI agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, openWorldHint, and non-destructive nature. The description adds value by specifying the data source ('pg_stat_statements'), ordering (by total execution time), and result size (top 50), which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the first sentence ('List top queries') is redundant with the name. It could be removed without loss. Otherwise concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, is read-only, and has no output schema, the description adequately covers the essential: it lists top 50 queries, sorted by execution time, from a Postgres instance. It references the API endpoint for further context. The annotations complete the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that postgresId is the ID of the Postgres instance, adding meaning beyond the raw schema which only defines it as a string. This is sufficient for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists top queries by total execution time on a Postgres instance, specifying the top 50. It distinguishes from sibling tools like 'render_list_postgres' (which lists instances) and 'render_list_postgres_processes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying top queries on a specific Postgres instance via the required postgresId. However, it does not explicitly state when to use this tool versus alternatives like 'render_retrieve_postgres' or other list tools, leaving the context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict the annotations (readOnlyHint=false, destructiveHint=true). It adds behavioral context by stating the tool triggers a cache purge and calls a specific API endpoint. It does not detail consequences like cache invalidation effects, but the destructive nature is clear. The annotations already convey the core behavioral traits, so the description adds meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences, with the first largely repeating the title. The second sentence is valuable. While it is concise, the redundancy slightly detracts from efficiency. Overall, it is well-structured and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is sufficient. It explains the action (purge cache), precondition (caching enabled), and the underlying API call. For a simple, one-step operation, this provides adequate context for an AI agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters, and the description reiterates the API endpoint which implies the serviceId. However, the description does not add significant meaning beyond what the schema already provides (e.g., format or source of serviceId). With high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('trigger cache purge') and resource ('web service'), and the title reinforces it. It distinguishes from the many sibling tools by specifying a unique operation. The mention of the API endpoint further clarifies the exact function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the condition 'if caching is enabled', providing context for when this tool should be used. However, it does not explicitly state when not to use it or mention alternative tools for related operations. The absence of exclusions or alternatives keeps it from a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, not destructive), the description adds behavioral details: workspace IDs start with 'tea-', user IDs default to user's workspace, and the underlying API call is GET /owners/{ownerId}. This provides useful context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the first two slightly redundant. It is front-loaded with the core purpose and adds specific details efficiently. Very little waste, though it could combine the first two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, no output schema, and comprehensive annotations, the description covers ID formats and special behavior. It lacks details about the response structure, but that is partially mitigated by the lack of output schema. Overall, it provides adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes ownerId as 'The ID of the user or team' (100% coverage), so baseline is 3. The description adds value by specifying ID prefix rules ('tea-' for workspace, 'own-' for user) and the special behavior for user IDs, which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a workspace, specifies that workspace IDs start with 'tea-' and user IDs start with 'own-', and explains the behavior for user IDs. This clearly differentiates it from sibling tools that retrieve other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on ID formats and the API endpoint, but does not explicitly state when to use this tool over alternatives like render_retrieve_service or render_retrieve_postgres. Usage is implied for workspace retrieval without exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context: websocket connection, real-time streaming, resource constraints, and the API endpoint. It goes beyond annotations but doesn't cover the full connection lifecycle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the core action. Each sentence adds distinct value: websocket connection, real-time streaming, and constraint/endpoint info. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the streaming behavior and constraints, but with no output schema and a complex websocket subscription, it doesn't cover return format or connection lifecycle (e.g., how to close, how limit applies). Some gaps remain for a fully self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some context about multi-resource queries and regional/owner constraints, but doesn't elaborate on individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes to new logs via a websocket, with real-time streaming. It distinguishes from siblings like render_list_logs or render_recent_logs by emphasizing the streaming nature of the subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies real-time streaming as the use case, and notes constraints (same region, same owner). It does not explicitly name alternatives or when-not-to-use, but the real-time context provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds valuable behavioral context: the action is asynchronous, and it describes state transitions. It also provides the API endpoint. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four efficient sentences: purpose, async behavior, follow-up steps, and API endpoint. No unnecessary words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the main behavioral aspects and follow-up steps. It could mention the response structure, but the state change description and reference to the retrieve endpoint are sufficient for a simple one-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It does not describe the maintenenceRunID parameter beyond the schema's pattern and example. The name is self-explanatory, but the description fails to add meaning like where to obtain the ID or its role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Trigger' and the resource 'scheduled maintenance run', with the ID parameter. It distinguishes from siblings like render_retrieve_maintenance by emphasizing the triggering action versus retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for triggering a scheduled maintenance run and provides guidance on checking progress via the retrieve endpoint. However, it does not explicitly state when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by specifying the HTTP method (PUT) and the upsert behavior ('Add or update'), which aligns with idempotentHint=true. It does not disclose side effects like triggering service redeploys or required permissions, but annotations already cover the basic safety profile (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action. The first sentence is somewhat redundant with the title, but the second sentence meaningfully adds the endpoint. It is concise with no unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the schema fully documents parameters, and annotations indicate idempotency, the description is largely sufficient. It lacks mention of the return value (no output schema), but that is a minor gap for an upsert operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. The description references envGroupId and envVarKey in the endpoint path, which reinforces their roles, but it adds no meaning beyond the schema, particularly for the body variants (value vs generateValue).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds or updates a specific environment variable within a specific environment group, which distinguishes it from sibling tools like render_update_env_var (generic) or render_update_env_vars_for_service. The inclusion of the exact PUT endpoint reinforces this precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by clearly targeting 'a particular environment group', which is helpful context. However, it does not explicitly mention when NOT to use this tool or point to alternatives, such as using render_update_env_var for service-level variables or render_add_or_update_secret_file for secret files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotent, non-destructive), the description adds that it performs an update via PUT and affects log routing for the workspace. Does not disclose permissions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, efficient and front-loaded. First sentence is slightly redundant but overall good. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter update tool with no output schema, the description explains the core behavior and API call. Lacks details on prerequisites or error handling, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all parameters (100% coverage). Description does not add new semantics beyond stating 'log stream information' and the routing effect, which is baseline worth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it updates log stream information for a workspace and explains the effect on log routing, distinguishing it from sibling tools like get or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (updating workspace log stream) but does not explicitly mention when not to use or compare to alternatives. However, the context from sibling tools makes it sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a mutating (readOnlyHint=false) and non-destructive (destructiveHint=false) operation. The description adds concrete behavioral details: it calls POST /services/{serviceId}/jobs and reuses the service's image and environment. It does not mention async behavior or side effects, but given the annotation coverage, the added context is valuable and not redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by useful usage details, an API reference, and a clear distinction from cron jobs. Each sentence adds value, with no redundant filler, though it could arguably be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, usage context, and distinctions from sibling tools, and includes a documentation link for further details. It does not describe the return value or asynchronous behavior, but given the absence of an output schema and the tool's moderate complexity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only serviceId has a description). The description clarifies that serviceId refers to an existing service and implies startCommand is the command to run, but planId remains completely unexplained. It does not adequately compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a one-off job using the provided service' with a specific verb and resource, and further distinguishes itself from cron job creation by naming render_create_service and render_run_cron_job as alternatives. This makes the tool's purpose unambiguous and differentiates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Starts a one-off job on an existing service, reusing its image and environment.' It also explicitly states when not to use it ('This is not how you create a cron job') and points to the correct tools for cron jobs, offering clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds deprecation context and the exact API endpoint, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with deprecation warning front-loaded. Efficient but could include more structured information like parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers purpose, deprecation, and API endpoint. Annotations handle destructive behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter redisId has no description in the schema (0% coverage). The description only says 'by ID', which adds minimal meaning; it could provide format or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete Redis instance' and specifies the verb 'Delete' and resource 'Redis instance'. It also mentions the exact API call, distinguishing it from other delete tools like render_delete_postgres.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is deprecated and directs users to the Key Value API, providing clear guidance on when not to use this tool and suggesting an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety. It adds value by specifying the underlying API call (GET) and the precedence behavior. This context goes beyond what annotations provide, but does not disclose potential auth requirements or pagination details. Adequate for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an API endpoint reference. It front-loads the action and provides relevant context without any filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, no output schema), the description is complete enough. It explains what is returned and the precedence logic. However, it could mention that the return is the override configuration object (though no output schema exists). Still, with annotations covering safety, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described required parameter (resourceId). The description does not add new semantics beyond restating that it applies to a specific resource. It does not provide additional format or validation rules. Baseline of 3 is appropriate since the schema already covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves log stream override information for a specific resource. It distinguishes from sibling tools like render_list_resource_log_streams (which lists all) and render_get_owner_log_stream (which is for the owner level). The verb 'Retrieve' and the resource 'log stream override' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that a log stream override takes precedence over the workspace default, providing context for when to use this tool. However, it does not explicitly differentiate from alternatives like render_list_resource_log_streams or render_get_owner_log_stream, leaving some implicit guidance. Overall clear enough but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already indicate safe read operation. Description adds the return type (download URL) and references the API call, providing helpful context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. Front-loaded with primary action, includes a link to documentation and API endpoint. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description covers purpose, return value, and API call. Could mention that the instance must exist, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but there is only one required parameter (postgresId). The description mentions 'by ID' but provides no additional validation or format details. Baseline 3 is appropriate given low coverage and simple param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Postgres exports for a specific instance by ID, returns a download URL, and cites the API endpoint. It distinguishes from related tools like render_create_postgres_export and render_list_postgres.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: use to list exports for a Postgres instance. No explicit when-not or alternatives, but the purpose is straightforward and sibling tools (create vs list) provide differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not burdened with repeating safety. It adds value by specifying the default behavior (returns all rules if no filters) and the underlying API call. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: purpose, default behavior, and API reference. It is front-loaded with the verb and resource, and contains no redundant or filler content. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 6 parameters, no output schema, and solid annotations, the description is mostly complete. It covers core functionality and the API call. However, pagination behavior (limit/cursor) is only in the schema, not highlighted in the description, which could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description does not provide additional parameter details beyond 'match the provided filters'. With high schema coverage, baseline 3 is appropriate; the description adds no extra semantic value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'redirect/rewrite rules for a service'. It distinguishes from sibling tools like render_add_route (adds rules) and render_put_routes (replaces all rules) by focusing on read-only listing. The inclusion of the API endpoint further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to list a service's routes with optional filters, and that omitting filters returns all rules. However, it does not explicitly state when not to use it (e.g., for creating or modifying routes) or mention alternatives among siblings. The guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that the preview uses base service settings unless overridden and specifies the API endpoint. However, it doesn't detail side effects, permissions, or idempotency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a note, all concise and front-loaded with the primary action. No unnecessary words or repetition. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 4 parameters and no output schema, the description adequately covers usage, constraints (image-backed only), and parameter details. It lacks explicit mention of what the response contains (e.g., preview ID), but references the Dashboard for viewing and the API endpoint, which is acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are thorough. The description adds context for imagePath (relative vs full URL), plan (legacy variants and restriction on free with paid base), and name (auto-generation). This goes beyond the schema's basic explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a preview instance for image-backed services, and explicitly distinguishes it from Git-backed services by noting that previews cannot be created for those via the API. The verb 'create' and resource 'service preview (image-backed)' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use (for image-backed services) and when not (not for Git-backed services). It also mentions viewing previews in the Dashboard. Although it doesn't explicitly name alternative tools, the exclusion of Git-backed services is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar for additional disclosure is lower. The description adds that it calls a GET endpoint and applies only to direct secret files, providing context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an API endpoint reference, front-loading the action and scope. Every sentence adds value without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention the response format, but the operation is simple (retrieve a single secret file). It adequately covers scope and API endpoint. Missing output details are a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add parameter-specific details beyond what the schema already provides (envVarKey as file name, serviceId as service ID). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Retrieve') and resources ('secret file for a service'), clearly distinguishing from sibling tools like list_secret_files_for_service and delete_secret_file. It also narrows scope to secret files set directly on the service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool (for secret files set directly on the service, not linked environment groups), providing clear context. It implicitly distinguishes from `render_list_secret_files_for_service` but does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds positive behavioral context beyond annotations: it returns aggregated data (configuration, deploys, instances, logs) in a single call. Annotations already declare readOnly, idempotent, non-destructive. Could mention that it may be expensive or rate-limited, but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first lists what the tool returns, second provides usage guidance. No unnecessary words; every sentence earns its place. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's return content (config, deploys, instances, logs) and aligns with parameters. No output schema, so description compensates. Could mention pagination or format details, but sufficient for a diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds minimal extra semantic beyond the schema (e.g., it mentions 'latest deploys' and 'recent error-level logs' which map to deployCount and includeLogs). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'One-call triage for a service' and enumerates specific resources: configuration, latest deploys, running instances, error-level logs. It distinguishes itself from sibling tools like render_retrieve_service, render_list_deploys, etc., by explicitly noting it replaces chaining multiple calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'answer is X healthy? or why is X broken?' and advises using it 'instead of chaining retrieve/list/logs calls.' This provides strong guidance, though it does not explicitly list alternatives when only one aspect is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the critical behavioral trait that updates are asynchronous, which is not captured by annotations. The annotations include openWorldHint=true and destructiveHint=false, and the description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three sentences, with the most important information (purpose) first. Every sentence adds value: purpose, async nature, post-update suggestion, and API endpoint. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 2 parameters and no output schema, the description covers purpose, async behavior, API endpoint, and a follow-up action. It could mention that only scheduledAt is updatable, but the schema implicitly indicates this. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the scheduledAt parameter with format and constraints, and maintenanceRunID with example and pattern. The description does not add any additional semantic meaning beyond the schema, so it meets the baseline for moderate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an update on a maintenance run using a specific verb and resource. It also includes the API endpoint, making the purpose unambiguous and distinguishing it from siblings like render_trigger_maintenance or render_retrieve_maintenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that updates are asynchronous and directs the user to the retrieve endpoint to check status. This provides clear context on usage, though it does not explicitly list when not to use this tool or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the asynchronous provisioning behavior, the immediate response with 'status: CREATING' and empty 'ips', and the eventual transition to 'RUNNING' with assigned IPs. It also explains the scope behavior of environmentIds. These details go beyond annotations (which only provide hints) and add significant value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and provides necessary details without fluff. The minor repetition ('Create dedicated IP set.') does not significantly detract but could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool without an output schema, the description adequately covers the return format and behavior. It explains the asynchronous nature and scope. Missing mention of prerequisites (e.g., valid ownerId) but these are implied by schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the environmentIds parameter, explaining the behavior when omitted versus provided. This enhances understanding beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create dedicated IP set' with a specific verb and resource. It distinguishes from sibling tools like list, retrieve, update, and delete dedicated IP sets, which are all present in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. It implies usage by describing the tool's functionality but lacks direct comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds deprecation info and the API call, but does not disclose side effects (e.g., state after resuming). This adds moderate context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first notes deprecation, the second states the action and API call. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple resume operation with one parameter and no output schema, the description is complete. It covers purpose, parameter meaning, deprecation, and API endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains that the required parameter is an ID ('Resume a Redis instance by ID'), adding essential meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Resume Redis instance.' It uses a specific verb and resource, distinguishes it from siblings like render_suspend_redis and render_create_redis, and notes deprecation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions deprecation in favor of the Key Value API, providing clear guidance to prefer an alternative. It implies usage for resuming a suspended Redis instance but does not explicitly state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds the specific GET endpoint, confirming it's a read operation. No additional behavioral details beyond annotations, but no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: a title-like first sentence and a descriptive second sentence with the API call. Both are relevant and concise, no wasted words. Could be slightly more efficient by merging, but still good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but for a simple retrieve operation, the description and annotations (readOnlyHint, openWorldHint) suffice. The agent can infer the return type. It does not explain return format, but given low complexity, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description reinforces the parameter roles via the API path template but does not add new semantic details. It is clear and aligns with schema, but no extra value beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies a particular secret file in a particular environment group, clearly distinguishing it from similar tools like render_retrieve_secret_file (no env group) and render_retrieve_env_group_env_var (env var vs secret file). The verb 'retrieve' plus resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States exactly what the tool retrieves and includes the API call, which helps the agent understand context. However, it does not explicitly mention when to use this tool over alternatives or when not to use it, lacking exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and destructive hint (destructiveHint=true). The description adds meaningful context: it turns off autoscaling and that the value is ignored while autoscaling is active. It also mentions the underlying API call. No contradiction with annotations; the description extends the behavioral profile with useful side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, a link, an API call reference, and usage guidance. The first sentence is slightly redundant with the title, but the rest is focused and every sentence adds value. It is concise enough while providing necessary caveats and alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description covers the main purpose, a key caveat, the alternative tool, and the API endpoint. It does not describe return values or error conditions, but for a scaling operation this is acceptable. The sibling alternative is named, which helps contextual decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only serviceId has a description). The description adds meaning for numInstances by calling it 'a fixed number of instances' and clarifies the effect of the operation. However, it does not provide validation details or edge-case guidance (e.g., allowed ranges for numInstances), so it only partially compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Scale the service with the provided ID to a fixed number of instances.' It uses a specific verb ('scale') and resource ('service'), and distinguishes it from the sibling render_autoscale_service by explicitly mentioning the alternative. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Usage: Sets a fixed instance count and turns off autoscaling. To scale on load instead, use render_autoscale_service.' It also includes an important caveat that Render ignores the value when autoscaling is enabled, telling the agent when not to rely on this tool. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, idempotent, non-destructive operation. The description adds the key scoping detail that linked environment group variables are not affected, and it discloses the underlying API call (PUT /services/{serviceId}/env-vars/{envVarKey}). This goes beyond the annotations without contradicting them, though it doesn't detail side effects or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three sentences, with the first repeating the title and the second adding clarity. The third sentence is highly informative, providing scope and the API endpoint. There is slight redundancy between the first two sentences, but overall it remains concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with three parameters and no output schema, the description covers the core purpose, scope, and API endpoint. It doesn't describe the return value or the generateValue option, but these are partially addressed by the schema. The description is adequate for an agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter having a description ('The name of the environment variable', 'The ID of the service', and 'Request body.'). The tool description adds no additional parameter-level meaning, so the baseline of 3 applies since the schema already handles semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add or update environment variable' for 'a particular service'. It distinguishes from related tools by explicitly excluding 'environment variables in a linked environment group' and naming the exact API call. This makes the tool's purpose unambiguous and differentiates it from siblings like render_update_env_group_env_var.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-not-to-use condition: 'This only applies to environment variables set directly on the service, not to environment variables in a linked environment group.' This guides the agent to alternative tools for env group variables, satisfying the 'when-not' criterion. It also implies single-variable scope, contrasting with batch tools like render_update_env_vars_for_service.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so deletion is expected. Description adds the critical scope constraint (service-level only) and the exact API endpoint, giving context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each meaningful: the action, the scope, and the API call. Front-loaded with the main purpose. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with only required inputs and no output schema, the description is complete. It covers scope, API method, and parameters. Could mention if it returns a status message, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description does not add further meaning beyond the schema; it only reiterates the parameters by mentioning the API endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it deletes an environment variable from a service, and explicitly distinguishes from environment group variables by stating 'not to environment variables in a linked environment group.' This differentiates it from sibling tool render_delete_env_group_env_var.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (deleting a service-level env var) and when-not-to-use (env group vars). No alternatives needed; the exclusion is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds that it returns id plus close alternatives, which is valuable context. However, it does not discuss auth requirements or rate limits beyond annotation hints. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only purpose, good annotations, and no output schema, the description covers the essential behavior and workflow. It could mention the format of alternatives or that multiple matches might be returned, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add new information about parameters beyond what the schema provides (query is fuzzy/partial). The description's mention of 'partial or approximate' aligns with schema text but doesn't enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it resolves a service name (including partial/approximate) to a single service, returning its id and alternatives. It specifies the resource (service) and action (find by name/id), distinguishing it from siblings like render_list_services and render_retrieve_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this first whenever the user names a service instead of giving an id' and explains that other tools need the id, providing clear when-to-use guidance and indicating the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that Render increments other rules' priorities as needed and calls a specific API endpoint. Annotations already indicate non-read-only and non-destructive behavior, and the description adds valuable behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the action, and contains no unnecessary words. Every sentence adds value: it states the action, explains priority behavior, and mentions the API call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers the essential aspects: the operation, priority mechanics, and API endpoint. It could mention return values or prerequisites, but overall it is fairly complete for an AI agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds meaning by explaining how the priority parameter works (starting from 0, adjusting others), which provides context beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update redirect/rewrite rule priority' and specifies it applies to a particular rule, differentiating it from sibling tools like render_add_route, render_delete_route, and render_put_routes. The verb 'update' and resource 'redirect/rewrite rule priority' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the priority ordering and that it adjusts other rules, providing context on when to use this tool. However, it does not explicitly state when not to use it or name alternatives, leaving some gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint and readOnlyHint. The description adds critical behavioral details: irreversibility, data overwrite, possible service deploy, and key expiration. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences, each adding valuable information. Could be slightly condensed, but effective. Front-loads purpose and key warnings. The API endpoint reference is useful but somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain what the API returns (likely a success indication or restored snapshot). Missing return value information. InstanceId parameter context could be expanded for scaled services. Otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 of 3 params described). The description adds meaningful context for snapshotKey (expiration and refresh), which is missing from schema. For diskId and instanceId, no additional details beyond schema. The added info compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Restore snapshot. Restore a persistent disk to an available snapshot.' It specifies the resource (persistent disk) and action (restore), and mentions the API endpoint. No confusion with siblings as none perform restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides key usage guidelines: it is irreversible, overwrites current disk data, may trigger a service deploy, and snapshot keys expire after 24 hours with instructions to refresh. It doesn't explicitly state when not to use, but the warnings serve as implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations: it returns immediately after queuing, not after the deploy completes, and it explains the meaning of clearCache=clear. It doesn't mention error conditions or auth requirements, but the structured annotations (readOnlyHint=false, openWorldHint=true) already set the mutation context. The description adds meaningful operational nuance without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, but it starts with a redundant 'Trigger deploy.' that repeats the title. The rest of the sentences each add unique value: endpoint, usage rules, clearCache guidance, and follow-up recommendation. Slight redundancy prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains the return timing ('as soon as the deploy is queued') and directs the agent to the appropriate follow-up tool. It covers all parameters and usage patterns. It doesn't specify the exact response payload (e.g., deploy ID), but the guidance is sufficient for correct invocation and next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all parameters with 100% coverage, so the baseline is 3. The description enhances this by explaining the effect of omitting commitId/imageUrl (deploys branch tip or current image) and adding a practical use case for clearCache=clear ('first thing to try when a build fails for no visible reason'). This is valuable semantic context beyond the property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Trigger a deploy for the service with the provided ID.' It also names the API endpoint (POST /services/{serviceId}/deploys), which distinguishes it from retrieval, cancellation, or wait tools. The purpose is unmistakable and differentiated from siblings like render_retrieve_deploy and render_cancel_deploy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: omit commitId/imageUrl to deploy the branch tip or current image, use clearCache=clear when builds fail for no visible reason, and follow up with render_wait_for_deploy rather than polling render_retrieve_deploy. This goes beyond what the schema offers and provides actionable decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true. The description adds critical context: deletion fails with 409 if the environment is not empty, and offers alternatives. This supplements the annotations well, though the core destructiveness is already indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: four sentences covering action, condition, alternatives, and API call. No redundant information; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description fully covers: action, precondition (empty), error case (409), alternatives, and API endpoint. No missing information needed for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'environmentId' is a simple string. With 0% schema coverage, the description does not elaborate on its format or meaning beyond 'the provided ID'. However, the purpose is obvious from the tool name and description, so this is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes an environment by ID, using the verb 'Delete environment'. It distinguishes this from sibling tools like render_create_environment and render_retrieve_environment by specifying the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (to delete an empty environment) and when not to use (if non-empty), providing alternatives such as moving/deleting resources or using the Dashboard. This clearly guides the agent on correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description confirms the delete behavior and adds important context about the scope (service-level only), clarifying what is not affected (linked env group secret files).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core function. Every sentence adds value: action, scope clarification, and API reference. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 2 parameters and no output schema, the description fully covers the operation, scope, and constraints. No missing information for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 (secret file from a service). It distinguishes this tool from siblings like render_delete_env_group_secret_file by specifying it applies only to secret files set directly on the service, not linked environment groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (secret files directly on the service) and when not to use (linked environment group secret files). Also provides the API endpoint for reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds that it calls 'GET /users' and retrieves the user tied to the API key, which is essential behavioral context beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the core purpose, then add the endpoint. No wasted words, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is clear about what it does but lacks any detail about the return value (no output schema). For a simple read operation, this is a minor gap; the agent knows it gets a user but not what fields are included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description notes that the user is identified via the API key (implicitly, not as a parameter), which is adequate context. No further parameter details needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'get the authenticated user' and specifies the API endpoint. The purpose is unambiguous and distinctly identifies the resource (authenticated user) among many sibling list/get operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the user associated with the current API key. There are no alternative tools for this purpose, so the context is clear. However, no explicit when-not or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation and non-idempotency, but the description adds the key behavioral side effect of canceling active runs, which is not obvious from annotations alone. It also clarifies that the schedule itself is unchanged, providing useful context beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place. It front-loads the action and side effect, then adds the API endpoint, usage context, parameter clarification, and alternative tool reference without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential context: what the tool does, the side effect of canceling active runs, how to obtain the parameter, and a clear distinction from schedule-changing operations. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes cronJobId as 'The ID of the cron job.' The description adds crucial meaning: it identifies the ID as the cron job service's own id (srv-… or crn-… on older workspaces) and directs users to resolve it with render_find_service, significantly enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Trigger a run for a cron job and cancel any active runs' with a specific verb and resource. It includes the exact API endpoint, and the mention of canceling active runs distinguishes it from the sibling render_cancel_cron_job_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Triggers an immediate, out-of-schedule run' tells when to use it, and 'This does not change the schedule; use render_update_service for that' points to an alternative. Also advises resolving cronJobId with render_find_service, providing clear prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable context beyond what annotations provide by specifying that the service loses access to environment variables and secret files, and by naming the API endpoint. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences with no unnecessary words. The first sentence front-loads the core action 'Unlink service', followed by clear elaboration. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema, annotations present), the description is complete. It explains the purpose, the effect, and the API call. An agent has enough information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It implicitly identifies the parameters via the phrase 'Unlink a particular service from a particular environment group', but does not explicitly describe each parameter (serviceId and envGroupId) or their formats. The parameter names are self-explanatory, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Unlink' and the specific resource 'service from environment group', and explains the consequence (loss of access to env vars and secret files). It distinguishes from the sibling tool 'render_link_service_to_env_group' which performs the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to unlink a service from an env group. However, it does not explicitly state when not to use it or mention alternative tools, though the sibling list includes related deletion tools. Still, the purpose is evident enough for basic decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly discloses destructive behavior: 'This deletes all existing header rules for the service that aren't included in the request.' This goes beyond the annotation's destructiveHint by specifying exactly what gets deleted. It also mentions the HTTP method, adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, behavior, and endpoint. Every sentence contributes essential information with no fluff, and critical warning is highlighted prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a replacement operation with clear destructive semantics, the description is complete. It explains the action, the destructive consequence, and the target endpoint. No output schema exists, so return details are not required, and annotations cover idempotency and destructive nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains each parameter (body and serviceId). The description adds no additional parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Replace header rules' and specifies 'Replace all header rules for a particular service with the provided list', which distinguishes it from siblings like add or delete. The mention of the exact API endpoint reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is for replacing the entire set of header rules, and the warning about deletion clarifies behavior. However, it does not explicitly name alternatives or exclusions, such as using add_headers for incremental changes, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=false, and the description adds meaningful side-effect context by stating 'Creating a service starts a first deploy; follow with render_wait_for_deploy.' It also discloses the non-obvious placement of `registryCredentialId` and the cron schedule requirement, going beyond what the flags convey. It doesn't discuss auth, rate limits, or errors, but the annotation coverage lowers the bar.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each section adds unique value; the three examples concretely illustrate branch selection and source combinations. It could be improved with bullet points or shorter examples, but the density is justified by the complex conditional schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and an extremely complex conditional schema, the description covers the key decision branches (type→serviceDetails, runtime→envSpecificDetails), the mutual-exclusion rule, cron schedule format, registry credential placement, and post-creation follow-up. It omits error handling and return shape, but with no output schema that burden is lower and the description is sufficient for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 46% schema description coverage, the description compensates by explaining the conditional meaning of `serviceDetails`, `envSpecificDetails`, and `image` vs `repo`, plus the schedule format for cron jobs. The examples concretely map type/runtime branches. However, parameters like `rootDir`, `buildFilter`, and `secretFiles` remain undocumented in both the schema and description, so it doesn't fully cover the 13-parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Creates a new Render service in the specified workspace with the specified configuration' names the verb (create), the resource (Render service), and scope (workspace). It also names the API endpoint `POST /services`, which clearly distinguishes this from sibling create tools like render_create_registry_credential or render_create_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: pick the `serviceDetails` branch matching `type`, use either `repo`+`branch` or `image` but 'never both', and follow with render_wait_for_deploy. It even names the prerequisite sibling tool render_create_registry_credential for private registry access, making when-to-use and next steps clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: filters are ANDed, name matches as substring, and the underlying API endpoint is GET /services. It does not mention pagination or response format, but the safety profile is fully covered by annotations, so this is a strong score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core purpose. Each sentence serves a distinct role: purpose, filter behavior, API call, and usage differentiation. No wasted words or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and strong annotations, the description covers the essential context: filter semantics, permission scoping, and when to prefer an alternative tool. It does not explicitly mention pagination behavior (though schema includes limit/cursor with links), and the phrase 'returns all services' could be misread given pagination, but overall it is sufficiently complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description enriches parameter understanding by stating that filters are ANDed and that name matches as a substring rather than exactly, which is not evident from individual parameter descriptions. This adds semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists services, with explicit scope: 'List services matching the provided filters' and 'If no filters are provided, returns all services you have permissions to view.' It distinguishes from sibling render_find_service by noting that tool resolves a single service with approximate names, while this tool is for enumeration/filtering in bulk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use vs alternative: 'When the user named one service, render_find_service resolves it in a single call and handles approximate names; reach for this tool to enumerate or filter in bulk.' Also clarifies default behavior with no filters and the permission scope of results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by detailing the destructive behavior (existing secret files not included are deleted) and the scope limitation (not for linked environment group secret files). Since destructiveHint=true is already in annotations, the description enriches this with specific consequences and exclusions, providing full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly longer but every sentence contributes essential information: the replacement semantics, the deletion warning, the scope exception, the API endpoint, and a usage recommendation. The bolded deletion warning and 'Usage:' section improve skimmability, though the core idea is restated somewhat redundantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive update tool with no output schema, the description fully covers what is replaced, what is deleted, scope boundaries, and recommended pre-reading. It includes the API endpoint and clear usage guidance, making it comprehensive for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both body and serviceId. The description adds minimal extra insight beyond calling body 'the provided list of secret files', but does not elaborate on the structure of the array or the meaning of name/content. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: replacing all secret files for a service with a provided list. It distinguishes from sibling tools like render_add_or_update_secret_file and render_delete_secret_file by emphasizing full replacement, and it identifies the specific API endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong usage guidance: explicitly states that omitted files will be deleted, advises reading the current set with render_list_secret_files_for_service first, and clarifies that it only applies to direct secret files, not environment group secrets. This effectively tells the agent when and how to use this tool safely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and non-destructive behavior, but the description adds important behavioral details: pagination via start/end timestamps, the hasMore flag, and the need to pass nextStartTime/nextEndTime for subsequent pages. It also discloses the cross-region/owner restriction and the underlying GET /logs API call, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, but opens with a slight redundancy ('List logs. List logs matching the provided filters.'). The rest of the sentences each add meaningful detail without bulk, making the description appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters, a non-trivial pagination model, and a sibling alternative, the description covers the essential usage, cross-resource constraints, and pagination mechanics. It lacks a full return-value specification, but there is no output schema and the description already mentions hasMore and the pagination fields, so the completeness is strong but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 17 parameters with descriptions (100% coverage), so the baseline is 3. The description adds extra meaning by identifying ownerId and resource as required, explaining the pagination parameters (nextStartTime/nextEndTime mapping to startTime/endTime), and noting the filters as a group. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List logs matching the provided filters.' It distinguishes from sibling tools by referencing render_recent_logs for the common case and by detailing the paginated listing behavior. It clearly identifies the tool's scope as a general log listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names render_recent_logs as the preferred alternative for recent logs of a single service, and states the required inputs (ownerId and resource array). It also specifies the constraint that all queried resources must be in the same region and belong to the same owner, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral context beyond what annotations already provide: 'This deletes all existing redirect/rewrite rules for the service that aren't included in the request.' It also discloses rule priority based on list order. These details are not present in the annotations (destructiveHint only indicates destructiveness, not the extent), making the description highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the operation, warning about deletion, and explaining priority ordering. It is front-loaded with the core action, then critical warnings, and ends with the API endpoint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for this tool's complexity: it clarifies the full-replacement semantics, destructive implications, ordering behavior, and the underlying API call. There is no output schema, and return values are not critical for an agent to invoke the tool correctly. Combined with rich schema and annotations, the description covers all essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing full parameter definitions. The description adds value by explaining that list order determines rule priority, which is not apparent from the schema alone. It also explains the body is the list of rules to use as the replacement, tying the parameters to the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a full replacement operation for redirect/rewrite rules on a service, using the specific verb 'Replace all'. It distinguishes itself from sibling tools like render_add_route, render_patch_route, and render_delete_route by emphasizing the wholesale replacement semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool replaces all existing rules with the provided list, implying it should be used when a full overwrite is desired. However, it does not explicitly name alternative tools (e.g., add_route for single additions) or provide 'when not to use' guidance, though the destructive warning effectively communicates the risk and usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, so the description's disclosure of name/workspace resolution is additive. No behavioral contradictions. The description could mention default time windows but schema covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then guidance. Every sentence is informative with no redundancy or extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and comprehensive annotations, the description is complete. It covers the tool's purpose, usage, and key differentiators. No missing critical information for a simple log-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the resolution behavior for `serviceId` and `ownerId`, and suggests filtering with `text`/`level`, which goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches recent log lines for a service' with a specific verb and resource. It distinguishes from sibling `render_list_logs` by noting it resolves service name and workspace id, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends preferring this over `render_list_logs` due to simpler invocation. Gives actionable filtering advice ('Filter with text/level to find errors quickly'), providing strong when-to-use and practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: toolsets are fixed at startup, this tool only reports the state and cannot change it. It also explains the default state (all enabled), which helps the agent understand the meaning of the output without misleading expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core action, the second provides context, and the third clarifies the fixed nature. Every sentence adds value without redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless listing tool with strong annotations and no output schema, the description is complete. It specifies what is returned (tool count, enabled status), why it is useful, and the key constraint (fixed at startup). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is 100% and there is nothing for the description to add. The baseline for 0-parameter tools is 4, and the description correctly omits any parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's action precisely: 'Lists every Render toolset with its tool count and whether it is currently enabled.' It clearly identifies the resource (Render toolsets) and the specific details returned, distinguishing it from sibling tools that list other resource types (e.g., services, deploys).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool is useful: 'discovering which Render capabilities exist, and for finding out what the operator has to change when a needed toolset is disabled.' It provides clear use cases, though it does not explicitly mention alternatives or when not to use it, which is acceptable given there are no direct sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains polling until terminal state or timeout, defaults to most recent deploy. Annotations indicate readOnlyHint, idempotentHint, destructiveHint: false, and the description adds behavioral details without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Each sentence provides essential information: first describes polling behavior and terminal states, second gives usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description mentions terminal states and timeout, implying return of deploy state. Minor gap: does not explicitly state that the current deploy object is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the default for deployId ('Defaults to the service's most recent deploy') and the intended usage pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'polls a deploy' and the resource 'deploy'. It lists terminal states and distinguishes from sibling tool render_retrieve_deploy by recommending its use instead of manual polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use after render_create_deploy instead of polling render_retrieve_deploy in a loop.' This gives clear context for when to use and what alternative to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds critical behavioral context: 'Triggering a rollback with this endpoint does not disable autodeploys' and 'an autodeploy might restore changes you had intentionally rolled back.' It also discloses the required deployId condition, which is not apparent from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences), front-loaded with the core purpose, and includes only high-value details: endpoint path, autodeploy caveat, and candidate selection guidance. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive rollback tool with no output schema, the description provides complete operational context: what it does, how to use it correctly, what it doesn't do (disable autodeploys), and how to manage the side effect. It sufficiently covers parameters, behavior, and alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions, but the description enriches the semantics significantly: deployId must be a previously successful deploy of the same service and can be listed via render_list_deploys with status 'live'. This goes well beyond the schema's simple 'The ID of the deploy to roll back to'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Roll back deploy' and 'Trigger a rollback to a previous deploy of the specified service.' It distinguishes this from sibling tools like render_create_deploy and render_cancel_deploy by specifying the rollback action and the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'deployId must be a previously successful deploy of this same service' and directs the user to render_list_deploys to find candidates with status 'live'. It also warns about autodeploys and names an alternative (Update service endpoint or Dashboard) for toggling autodeploys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint and idempotentHint, but the description adds critical behavioral context: anything absent from `body` is deleted, and applying changes restarts the service. This goes beyond the structured annotation information, making the side effects concrete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: the first states the core function, the second explains the replace-all semantics and API endpoint, the third provides usage instructions, and the fourth notes the service restart side effect. The structure is logical and front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex destructive update tool with no output schema, this description covers everything an agent needs: what it does, how it differs from alternatives, the full replacement behavior, and the restart consequence. It is fully self-contained and addresses potential usability pitfalls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches the `body` parameter meaning by explaining that the entire environment variable set is replaced and anything absent is deleted. This is valuable semantic information not present in the JSON schema, clearly enhancing the agent's understanding of what `body` represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates and replaces all environment variables for a service via `PUT /services/{serviceId}/env-vars`. It distinguishes itself from siblings like render_update_env_var by explicitly noting it replaces the entire set, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: to change one variable, use render_get_env_vars_for_service to read the current set and send it back, or use render_update_env_var for a single key. This directly tells the agent when to choose alternatives, fulfilling the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses important behavioral traits beyond annotations: PATCH semantics (omitted fields keep current values), inability to change service type, and that schedule/build changes do not auto-deploy. This enriches the sparse annotation set with critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph that flows from action to API, then to usage rules, deploy caveat, and example. Every sentence adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema and absence of an output schema, the description covers the operation, key constraints, and follow-up actions thoroughly. It gives an agent enough to invoke the tool correctly without needing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 11%, the description compensates by explaining the `serviceDetails` branch structure, the type-matching constraint, and providing a concrete JSON example. It clarifies the most complex parameter in a way the raw schema cannot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update service' and explicitly identifies the API call `PATCH /services/{serviceId}`, specifying the exact resource and operation. It distinguishes itself from sibling tools like render_restart_service or render_scale_service by describing the general update endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions: match the `serviceDetails` branch to the existing service type, read the service first if unsure, send only changed fields, and call `render_create_deploy` when a rebuild is needed. This gives clear when-to-use and when-not-to-use guidance, including a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![render-useful-mcp MCP server](https://glama.ai/mcp/servers/LuSrodri/render-useful-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LuSrodri/render-useful-mcp)

Score Badge

Copy to your README.md:

[![render-useful-mcp MCP server](https://glama.ai/mcp/servers/LuSrodri/render-useful-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LuSrodri/render-useful-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LuSrodri/render-useful-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server