aptible-mcp

Official

by aptible

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct by resource and action, such as createApp, deleteDatabase, and listStacks. The only minor overlap is between listVhosts and listServiceVhosts, and getAccountsByStack vs listAccounts, but descriptions clarify the intended scope.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list, get, create, delete, configure, scale) with no mixed conventions or vague verbs. Examples like getAppProvisionExample still fit the pattern as get + resource + Example.
Tool Count2/5
With 38 tools, the surface is quite large and exceeds the 25+ threshold. While the domain is broad (accounts, apps, databases, vhosts, services, operations, examples), the sheer number feels heavy and could overwhelm agents, especially with 10 example template tools.
Completeness3/5
Core resources have CRUD coverage, but there are notable gaps: no update/delete for accounts, no database backup or restore operations, and no app logs. The example tools provide templates but don't fill operational dead ends, so agents may need to work around missing lifecycle features.
Average 3.4/5 across 38 of 38 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is fully responsible for disclosing behavioral traits, but it only repeats the tool's name. There is no mention of side effects, required permissions, asynchronous behavior, or what happens upon creation, leaving agents to guess at the tool's consequences.
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 is very short but this is under-specification rather than effective conciseness. It restates the tool name without adding value, so the sentence does not earn its place.
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?
The tool has three required parameters and no additional context from schema or annotations. The description is wholly inadequate to understand the tool's purpose beyond trivial creation, leaving major gaps about input requirements, return values, and operational effects.
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 for its three required parameters, and the description does not mention any of them. It fails to compensate for the lack of schema documentation, providing no insight into what app_handle, account_handle, or docker_image mean or how they should be supplied.
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 a clear verb and resource: 'Create a new app.' This distinguishes it from other app-related operations like getApp, configureApp, and deleteApp, though it doesn't explicitly differentiate from sibling creation tools like createAccount. The intent 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 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, nor any prerequisites such as needing an existing account or stack. The single sentence offers no context for usage decisions.
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?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. However, it only says 'Delete an app.' with no mention of permanence, irreversibility, side effects on associated resources, or any operational nuances. This adds zero information beyond the tool name itself.
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 is extremely short, which avoids verbosity, but it is under-specified to the point of being unhelpful. It lacks essential details such as parameter roles, consequences, or usage guidance. This is not appropriately sized for the complexity of the operation.
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 that this is a destructive delete operation with two parameters and no annotations, the description is critically incomplete. It does not describe side effects, required parameters, return behavior (though an output schema exists), or any operational warnings. The description needs substantial expansion to be minimally viable.
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%, and the description does not mention or explain either parameter (app_handle, account_handle). The optional account_handle's purpose (likely scoping to a specific account) is completely unaddressed. The description fails to compensate for the complete 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 the action ('Delete') and the resource ('an app'). It is specific enough to distinguish from other resource-specific tools like deleteDatabase and deleteVhost, though it does not explicitly differentiate itself from any alternative delete tool or clarify the exact scope of deletion.
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, what prerequisites exist (e.g., required permissions), or how it compares to alternative operations. It simply restates the tool's name without adding context about appropriate usage scenarios.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it reveals nothing beyond the action. It does not mention return format, error behavior, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified for a tool with no annotations or parameter details. It is not overly verbose, but it omits necessary context, so it is not appropriately sized.
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?
Although an output schema exists, the description does not explain the stack_name semantics or any edge cases like missing stack handling. For a tool with zero annotations and minimal parameter info, this is incomplete.
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 merely repeats 'by name' which aligns with the stack_name parameter but adds no additional meaning. Schema description coverage is 0%, so the description should compensate with details about format or constraints, which it fails to do.
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 'Get stack by name' clearly states the action (get), resource (stack), and scope (by name). It implicitly distinguishes from listStacks by focusing on a single stack retrieval, though it does not explicitly contrast with 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?
No guidance is provided on when to use this tool versus alternatives like listStacks or getAccountsByStack. The description only states the basic function without any 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose that deletion is permanent/irreversible, any permission requirements, or what happens to associated data. The phrase 'Delete a database' only restates the tool name without 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 description is a single, front-loaded sentence with no waste. It is concise and easy to read, though it lacks essential details that would make it more useful.
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?
For a destructive tool with no annotations and no parameter descriptions, the description is completely inadequate. It omits prerequisites, side effects, and return value details, and the presence of an output schema does not reduce the need for behavioral context.
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%, and the description does not compensate. It does not mention account_handle or database_handle or explain their roles, making it impossible to infer parameter 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 'Delete a database' clearly states the action (delete) and the resource (database). It distinguishes from sibling tools like createDatabase and listDatabases by the verb '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?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It does not mention that database_handle is required or when account_handle should be supplied.
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?
With no annotations, the description carries the full burden, but it only states the basic action. It does not disclose side effects, permissions, idempotency, return values, or any operational behaviors beyond creating an account.
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 a single concise sentence with no wasted words. However, it is too spartan to be fully effective, though it does not suffer from bloat.
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 simplicity of the operation and the two required parameters, the description is severely under-specified. It lacks parameter semantics, usage context, and behavioral details, making it insufficient for an agent to invoke the tool with confidence.
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%, and the description does not mention the parameters at all. The parameter titles 'Stack Name' and 'Account Name' provide minimal meaning, and the description fails to compensate for the lack of schema docs, leaving the agent without clarity on what constitutes an account or stack.
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 uses the verb 'create' with the resource 'account/environment', making the primary action clear. It distinguishes from sibling tools like createApp and createDatabase by naming a different resource, though it does not explicitly delineate the scope of 'account/environment'.
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, nor any prerequisites or conditions. The description is a bare statement of creation without context about account creation workflows or stacks.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'recent operations' but does not explain what 'recent' means, whether there are pagination limits, ordering, or permission requirements. The tool appears to be a read-only getter, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, clear sentence with no fluff. It is appropriately sized for a simple getter tool, though it could include a bit more detail without becoming verbose. The structure 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (so return values are documented), the description lacks essential context: it does not explain the optional account_handle parameter, provide usage guidance relative to sibling tools, or disclose any behavioral constraints. This makes the description incomplete for confident tool selection and 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?
Schema description coverage is 0%, and the description does not compensate. It implies 'app_handle' identifies the app, but the optional 'account_handle' parameter is completely unexplained. The description adds little meaning beyond what the parameter names suggest.
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+resource: 'Get recent operations for a specific app.' It specifies the scope ('for a specific app') which distinguishes it from siblings like getOperationsForDatabase and getOperationsForVhost, but it does not explicitly differentiate from getOperationLogs, which could overlap. Still, the core purpose is clear.
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 getOperationLogs or getOperationsForDatabase. The description only states what it does, not the context or exclusions. No when-to-use or when-not-to-use information is present.
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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'Configure app environment variables,' which implies mutation but gives no details about side effects, idempotency, whether existing variables are overwritten, permission requirements, or error 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 a single, direct sentence that front-loads the verb and object without any wasted words. However, it is quite terse, missing opportunities to add valuable context while remaining 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?
Given the tool is a mutation with three required parameters, no annotations, and an output schema, the one-line description is insufficient to guide correct usage. It lacks usage context, parameter semantics, and behavioral disclaimers, making it incomplete for an agent to confidently invoke.
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 three parameters (app_handle, account_handle, env) but zero schema-level descriptions. The description adds minimal meaning by mapping 'environment variables' to the env parameter, but does not explain the handles or their required relationship, leaving the schema mostly self-documenting.
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 with a specific verb ('Configure') and resource ('app environment variables'), distinguishing it from sibling tools which are primarily create/list/delete/get operations. No other sibling tool modifies environment variables, so the purpose 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 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 getAppConfigureExample for examples or other configuration-related operations. It also fails to mention prerequisites like the need for an existing app or account.
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?
With no annotations provided, the description must disclose behavioral traits. It only states 'List all vhosts/endpoints', adding minimal context beyond the tool name (that it lists all). It does not disclose pagination behavior, permission requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it contains a stray closing parenthesis and the phrasing is slightly awkward. Still, it is appropriately sized for a simple listing tool.
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 existence of a similar sibling tool 'listServiceVhosts', the description lacks necessary context to distinguish the global scope of this tool. It also does not mention any filtering or ordering behavior. The presence of an output schema covers return values, but overall contextual information is sparse.
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 accepts zero parameters, so the schema already describes all inputs. The description adds no parameter-specific information, which is unnecessary here. Baseline 4 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 uses a specific verb 'List' and resource 'vhosts/endpoints', clearly indicating the tool's function. However, it does not differentiate from the sibling tool 'listServiceVhosts', which may also list vhosts but scoped to a 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?
The description provides no guidance on when to use this tool versus alternatives like 'listServiceVhosts'. It lacks any contextual information about use cases 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'get' (read-only) but does not mention return format, pagination, the meaning of 'recent', or any filtering/scoping behavior. This is minimal transparency for a tool that likely returns a list of operations.
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 sentence with no filler words. It is front-loaded with the action and resource, making it maximally concise at the cost of depth.
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 an output schema (which covers return values), the description lacks essential context: it does not explain the role of account_handle, what 'recent' means, or how results are scoped. For a tool with 2 parameters and no annotations, the description is under-specified.
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%: the description does not explain either parameter. The required database_handle is hinted by 'specific database', but the optional account_handle is completely unexplained, and no parameter semantics or syntax details are provided to 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 'Get recent operations for a specific database' uses a specific verb ('get'), a specific resource ('operations for database'), and the 'ForDatabase' naming clearly distinguishes it from sibling tools like getOperationsForApp and getOperationsForVhost.
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 operations for a database) but does not explicitly state when to use it over alternatives or any exclusions. There is no mention of using other tools for app or vhost operations, so guidance is only implied.
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 is extremely terse. While 'Delete' implies destructive action, it does not disclose any behavioral traits such as irreversibility, required permissions, or impact on related resources. With no annotations, the description carries the full burden, which it fails to satisfy.
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, compact sentence that conveys the essential action. It is efficiently front-loaded and contains no wasted words, meeting the conciseness standard despite being minimal.
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 destructive operation with no annotations, this description is insufficiently complete. It fails to mention consequences, approval requirements, or any side effects, and the output schema does not alleviate the need for such 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?
The schema documents a single parameter `vhost_id` (integer), and the description adds no additional meaning. Since the parameter is self-explanatory from its name and type, the lack of description is not a significant gap, but the tool still provides no extra semantic support.
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 ('vhost/endpoint'), distinguishing it from sibling tools like createVhost, getVhost, and listVhosts. It is specific, unambiguous, and uses a strong 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, nor any prerequisites or exclusions. The tool name and sibling list imply its use case, but the description does not explicitly clarify when it should be invoked.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read-only operation, but does not mention error handling, authentication requirements, or what happens if the service is not found. It fails to provide meaningful behavioral context beyond the basic 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 a single, well-structured sentence that is front-loaded with the action and resource. It is free of unnecessary words and gets straight 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?
Given the tool has three parameters (one optional), no annotations, and an output schema (not shown), the description is too minimal. It does not explain the optional parameter, how this tool interacts with other service-related tools, or any edge cases. The description is not complete enough for an agent to know when and how to use it correctly beyond the most basic reading.
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 description adds meaning for two parameters (app_handle and service_handle) by indicating they are used to identify the service within an app. However, it does not explain the optional account_handle parameter, and schema coverage is 0%, so the description only partially compensates for the lack of 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 the tool's function: to get a service by handle within a specific app. It uses a specific verb ('Get'), identifies the resource ('service'), and specifies the scope ('within a specific app'), which distinguishes it from siblings like listServices or scaleService.
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 explicit guidance on when to use this tool versus alternatives such as listServices or scaleService. There is no mention of prerequisites or exclusions. The only implied usage is that you need a specific service handle, but this is not articulated as 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?
No annotations are provided, so the description must convey whether the operation is safe. The verb 'List' implies a read-only operation, but the description does not explicitly state safety, permissions, or any side effects. For a list operation, this is adequate but not rich; it adds no extra context beyond the verb.
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 sentence with no filler words. It conveys the essential scope in a compact way. Every word is meaningful and there is no redundancy, so it earns full marks 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?
The tool has 3 parameters and no annotations, and while an output schema exists, the description is minimal. It does not explain how this tool relates to sibling listVhosts, nor does it mention the optional account_handle or the expected hierarchy of app/service/vhost. For an agent to use this correctly, crucial context about parameter dependencies and scope is missing.
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 enumerate or explain the parameters. It only says 'for a specific service', which maps to service_handle, but does not clarify the roles of app_handle or the optional account_handle. The parameter names are somewhat self-explanatory but the description contributes almost no additional meaning, so it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 resource (vhosts), and adds a scoping phrase 'for a specific service' that distinguishes it from the sibling tool listVhosts, which likely lists vhosts across services. However, it does not explicitly name or contrast with listVhosts, so it misses the highest bar for 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need vhosts for a given service. It does not provide explicit when-to-use/when-not-to-use guidance, nor does it mention alternatives like listVhosts or getVhost. This is only implied usage, not explicit, so it gets a mid-range score.
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?
With no annotations, the description carries full burden. It discloses the primary effect (changing count or size) but omits side effects, whether scaling is online, whether both optional parameters can be set together, or what happens to unspecified fields. This is a minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It is front-loaded and concise, effectively communicating the core purpose without any wasted words.
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, no annotations, and only an output schema, the description is too sparse to fully guide an agent. It does not mention which parameters are required, the relationship between container_count and container_memory_limit_mb, or any constraints. The agent would need to infer too much from the schema alone.
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 0% description coverage, so the description must compensate. It adds some meaning by linking 'container count' and 'size' to the scaling action, but it does not explain the identifier parameters (app_handle, service_handle) or account_handle, and it doesn't clarify that container_count and container_memory_limit_mb are optional nullable values.
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: 'Scale a service' and specifies the scope ('by changing container count or size'). This distinguishes it from sibling tools like listServices or getService, making the purpose unmistakable.
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 when-to-use or alternative guidance is given. Usage is implied by the service management context, but the description does not state when to choose this over other service tools or mention any 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?
With no annotations to lean on, the description carries the full burden of behavioral disclosure. It only restates that the tool gets an account/environment by handle, offering no insight into side effects, error behavior, authentication requirements, or what 'account/environment' encompasses.
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, front-loaded sentence with no redundant words. It efficiently communicates the core action.
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?
While the output schema provides return structure, the description lacks sufficient context for an agent to understand preconditions, alternative usage scenarios, or parameter semantics. For a simple read tool, it is minimally adequate but has clear 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?
Schema description coverage is 0%, so the description must add meaning to the single parameter. The phrase 'by handle' merely repeats the account_handle parameter name without explaining what a handle is, its format, 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 states a specific verb ('Get') and resource ('account/environment') with a clear retrieval mechanism ('by handle'). This distinguishes it from sibling tools like listAccounts (listing) and getAccountsByStack (filtering by stack).
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 listAccounts or getAccountsByStack. The usage is implied by the handle parameter, but no exclusions or alternative 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?
With no annotations provided, the description carries the transparency burden, but 'Get' implicitly signals a read-only operation. However, it does not mention any specific behavioral details (e.g., pagination, log format, or error conditions), though this is a simple getter.
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 concise sentence with no waste, front-loading the purpose clearly. 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?
For a one-parameter tool with an output schema, the bare description is minimally viable, but it lacks contextual guidance such as the relationship to getOperationsFor* tools or how to obtain an operation_id, leaving some 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?
Schema description coverage is 0%, and the description only says 'for a specific operation' which weakly ties to operation_id but adds little beyond the parameter name and title. It does not explain how to find valid operation IDs or any constraints.
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 'Get logs for a specific operation' clearly states the verb (get), resource (logs), and scope (specific operation), distinguishing it from sibling tools like getOperationsForApp which list operations rather than 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 no guidance on when to use this tool versus alternatives, such as how to obtain the operation_id or when logs would be needed. It only states the basic action without any 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?
No annotations are provided, so the description must carry the burden. It states the tool gets 'recent operations' but does not disclose what 'recent' means, potential side effects, required permissions, or pagination behavior. This is a minimal read operation, but the lack of behavioral context leaves significant gaps.
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, focused sentence with no redundant words. It achieves the goal of conveying the core purpose without any filler, making it highly 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 one-parameter tool with an output schema, the description is minimally adequate but not thorough. It does not clarify what 'recent operations' entails, how results are ordered, or the relationship to similar getOperationsFor* sibling tools. The presence of an output schema covers return structure, but behavioral context is sparse.
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 does not explain the vhost_id parameter beyond the phrase 'specific vhost/endpoint'. Since the schema provides only the name and type, the description adds minimal semantic value and does not compensate for the lack of 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 the action ('Get recent operations') and the specific resource ('for a specific vhost/endpoint'). This distinguishes it from sibling tools like getOperationsForApp and getOperationsForDatabase by explicitly scoping to vhost.
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 used when you need operations for a particular vhost, but it does not explicitly contrast with alternatives or mention when not to use it. There is no exclusionary guidance, but the scope is clear enough to infer typical usage.
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?
No annotations are provided, so the description must disclose behavioral traits. It merely restates the action without explaining read-only nature, error handling (e.g., behavior when ID not found), or return value structure. This is insufficient given the lack of annotation 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 concise sentence with no extraneous words. It is front-loaded and wastes no space, which is ideal for a simple get-by-ID operation.
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 simplicity of one parameter and the presence of an output schema, the description is minimally adequate. However, it lacks guidance on when to use this vs. listVhosts, and it omits any mention of possible outcomes (e.g., 404 handling), making it only moderately complete for an agent to invoke correctly in all situations.
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 minimal semantic value by saying 'by ID', which mirrors the schema's 'vhost_id' parameter. With 0% schema description coverage and no annotations, it fails to compensate by explaining the parameter's format, validation, or meaning beyond its 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 action ('Get') and the resource ('vhost'), and specifies it is by ID. This distinguishes it from siblings such as listVhosts (which lists) and createVhost/deleteVhost (which create/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 implies a usage context: fetch a single vhost when you have its ID. However, it does not explicitly state when to use this tool over alternatives like listVhosts, nor does it 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'List all stacks.', without stating whether the operation is read-only, if any permissions are required, whether results are paginated, or any other behavioral details.
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 a single, direct sentence with no fluff. It is appropriately concise for a parameterless list operation, though slightly under-specified could be argued; still, it 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 tool is simple (no parameters, has output schema), but the description omits any scope details (e.g., which stacks are included, whether it's globally scoped) and lacks usage context. It is adequate but with clear gaps.
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 has zero properties, so the description need not explain parameter semantics. With 0 params, baseline 4 applies, and the description adds nothing beyond the schema, which is acceptable.
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 ('List') and resource ('stacks'), with the qualifier 'all' clarifying it returns every stack. This clearly distinguishes it from the sibling tool 'getStack', which presumably fetches a single stack.
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 vs alternatives such as getStack or other list tools. There is no mention of when to choose this tool, what it is not for, or any alternatives.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a database is created, and provides no information about side effects, permissions, synchronous/asynchronous behavior, or what is returned. This is insufficient for a mutating 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 short sentences deliver the essential purpose and one key usage detail without any wasted words. The structure is appropriate for the tool's simplicity.
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 is far from complete for a create operation with 3 required parameters. It lacks guidance on the other two params, prerequisites, and consequences. The output schema presumably documents return values, but the description alone leaves too many 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?
Schema coverage is 0%, leaving the description responsible for explaining parameters. It explains image_id (pointing to listAvailableDatabaseTypes), but gives no meaning for account_handle or database_handle, which are required and otherwise undocumented.
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 a new database') with the exact resource, and it distinguishes itself from sibling tools like deleteDatabase and listDatabases. The additional hint about image_id adds context that 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains how to obtain the image_id (via listAvailableDatabaseTypes), which is essential usage context. It does not explicitly state when to use this tool over alternatives, but the 'create' verb and resource make that implicit.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states the operation without disclosing error handling, permissions, or read-only guarantees. The word 'Get' hints at a read operation but does not make it explicit.
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, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's purpose and key parameters.
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?
An output schema exists, so return values are documented. However, the description lacks explicit usage alternatives and behavioral context, making it adequate but not comprehensive for a simple getter 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 input schema has no descriptions (0% coverage), and the description adds meaning by clarifying that database_handle is the lookup key and account_handle is optional. However, it does not provide additional format, constraints, or relationship details beyond what the schema already conveys.
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 'Get' with the resource 'database' and identifier 'handle', clearly distinguishing it from listDatabases and other getters in the sibling list. It states exactly what the tool does: retrieves a database by its handle.
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 database handle and want a single database, but it does not explicitly mention alternatives like listDatabases for listing all databases, nor does it specify when not to use this tool. No prerequisites or exclusions 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?
With no annotations, the description carries the burden of revealing behavior. It discloses that service_handle is auto-assigned (not user-set) and that only default on-aptible.com domains are supported, which is useful. However, it omits details about side effects (e.g., provisioning time, whether it triggers a deploy), required permissions, or how conflicts (e.g., existing vhost) are handled, so transparency is partial.
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 has a clear lead sentence but includes extraneous content such as a TODO note ('Add support for database endpoints and custom endpoints') and a conversational aside ('Since this is being used by AI, that shouldn't matter, though.'). These could be removed or condensed to improve focus, though the description remains moderately 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?
The description covers key limits (services only, default domains) and mentions the service_handle peculiarity, but it does not state prerequisites (e.g., app/service must exist) or expected behavior after creation. While an output schema exists (which may describe return values), the description still lacks important context for a create operation, leaving moderate 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 schema provides zero parameter descriptions, so the description must compensate. It explains the service_handle quirk (auto-assigned by Aptible, mapped via process_type) but does not explain account_handle at all, and it only indirectly references app_handle. With 3 parameters and 0% coverage, this is insufficient for an agent to understand all inputs.
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 opens with 'Create a new vhost/endpoint for a Service,' which clearly states the verb ('create'), the resource ('vhost/endpoint'), and the scope ('for a Service'). This distinguishes it from sibling tools like listVhosts, deleteVhost, and createDatabase, making 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when this tool is appropriate: it only supports default on-aptible.com domains for Services, explicitly noting that database endpoints and custom endpoints are not yet supported. While it doesn't name alternative tools, these constraints clearly signal when not to use it and guide the agent toward appropriate use cases.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'List all databases' implies a read-only operation, but it does not mention authentication, rate limits, pagination, or result details. This is minimal and insufficient for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and appropriate for the tool's simplicity.
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 parameterless list operation with an output schema, the description is minimally adequate. However, it does not clarify the scope of 'all databases' (e.g., across accounts or stacks), which could be ambiguous given the sibling tools.
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, and the input schema is empty. The description does not need to explain parameters, and the baseline score of 4 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 tool's action with the verb 'List' and the resource 'all databases,' which distinguishes it from sibling tools like listAccounts and listApps. It is direct 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 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 getDatabase or createDatabase. It lacks any context on typical use cases 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?
With no annotations, the description carries full burden. It reveals the operation is a read-only list, but it does not disclose any edge cases, required permissions, or response structure. Minimal but not misleading.
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?
One sentence that is front-loaded and contains no filler. It is appropriately concise 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 adequate for a simple list tool, and an output schema exists to cover return values. However, the optional account_handle is unexplained, and with no annotations, the description is not fully complete for all parameter scenarios.
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 indirectly references app_handle via 'specific app' but completely omits account_handle, leaving the optional parameter's purpose and usage unexplained.
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 ('services'), and the scope ('for a specific app'). It distinguishes from sibling tools like getService (singular) and listServiceVhosts (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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool when you need all services for an app. However, it does not explicitly mention alternatives (e.g., getService for a single service) or provide exclusions, so guidance is not explicit.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get all'), which is useful, but it does not disclose error behavior, pagination, or any side effects. Basic transparency is present but lacks depth.
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 concise sentence that front-loads the core action and purpose. Every word earns its place, with no unnecessary detail or repetition.
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 tool is simple (one parameter, no nested objects) and an output schema exists, so return values are presumably covered. The description is adequate for a basic lookup, though it lacks explicit usage guidance and potential edge-case behavior (e.g., empty results). Overall, it is reasonably 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the parameter, and the description only says 'by stack name', which adds minimal semantic value beyond the parameter's title 'Stack Name'. No format, examples, or additional context are given, leaving the single parameter under-explained.
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 'Get' with a clear resource 'accounts/environments' and scoping 'in a stack by stack name'. This clearly distinguishes it from sibling tools like listAccounts (which presumably returns all accounts) and getAccount (which returns a single account).
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 phrase 'by stack name' implies the use case of filtering accounts by stack, but it does not explicitly state when to use this tool over listAccounts or getAccount, nor does it mention any exclusions. Usage context is implied rather than 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?
With no annotations, the description carries the burden. It discloses a key behavioral nuance: app handles are not globally unique, which is important for correct invocation. However, it doesn't mention error behavior (e.g., ambiguous handle, not found) or confirm read-only semantics beyond the verb 'Get.'
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 and every word earns its place. It front-loads the core action and follows with a concise reason for the optional parameter, with no 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?
The tool is a simple getter with only two params and an output schema. The description covers the core purpose and the key scoping nuance, which is sufficient for this complexity. It could add error-handling details, but those aren't critical given the output 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 description coverage is 0%, so the description compensates by explaining the purpose of both parameters. 'App handle' is identified as the lookup key, and 'account handle' is explained as an optional disambiguator due to naming scope. This adds real semantic value beyond the bare 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 states a clear verb+resource: 'Get app by handle.' It specifies the retrieval method (by handle) and adds relevant context about uniqueness within an account/environment. It doesn't explicitly contrast with sibling tools like listApps, but it's sufficiently distinct.
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 when to optionally provide the account handle (when app names are ambiguous across accounts), but it doesn't discuss when to use this tool instead of listApps or other alternatives. The guidance is implied rather than explicit.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Gets an example' without clarifying whether this is a read-only operation, what the response format is, or any side effects. The verb 'Gets' implies non-destructive behavior, but the description does not explicitly confirm it or detail what the example includes.
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, clear sentence that front-loads the primary purpose. It contains no filler, redundant information, or restatement of the tool name. Every word contributes to understanding what the tool does.
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 (no params, simple getter), the description is minimally sufficient. An output schema exists to document the return value, so the description need not explain it. However, it lacks any contextual detail about when this example would be useful or what 'GitHub Action' entails, leaving it adequate but not 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 tool has zero parameters, and the input schema is empty, so there is nothing to document. The description does not need to add parameter meaning, and the baseline of 4 is appropriate because the schema already fully covers the parameter space (none exist).
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: 'Gets an example of a GitHub Action for building, publishing, and deploying an app.' The verb 'Gets' with a specific resource (an example of a GitHub Action) distinguishes it from sibling tools like getProcfileExample or getAptibleYamlExample, which target different example types.
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 context by specifying the purpose ('building, publishing, and deploying an app'), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No explicit 'when to use' or 'use instead' guidance is present, making it adequate but not fully explicit.
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?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It describes the tool as a getter, implying a safe read operation, but does not explicitly state absence of side effects, auth requirements, or return format. Since it's an example fetcher, the minimal transparency is acceptable but not detailed.
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 entire description is a single sentence that directly states the tool's purpose without superfluous words or repetition.
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 tool is extremely simple: no parameters, an output schema exists, and the description conveys the purpose clearly. It doesn't describe the output format, but the output schema covers that. The only minor gap is not explicitly mentioning that the example is a YAML workflow file, but that is inferable.
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 has zero parameters, so there is nothing to explain. Per the rubric, a tool with zero parameters receives a baseline of 4. The description does not need to provide parameter details as none exist.
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 'gets' and identifies a clear resource: 'an example of a GitHub Action for configuring an app.' This clearly differentiates it from sibling example tools like getProcfileExample, which target different content, and from operations like configureApp.
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 choose this tool over alternatives, such as other example getters or the actual configureApp operation. There is no mention of use cases, prerequisites, or how this example relates to a configuration workflow.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it 'gets an example,' without mentioning side effects (though likely none), return format details, or any operational implications. This is a minimal disclosure for a getter tool.
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 sentence, front-loaded with the core action and resource. Every word earns its place, and the sentence is both concise and informative.
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, parameterless tool with an output schema, the description is adequately complete. It states exactly what is returned (a GitHub Action example for provisioning an app) and needs no further elaboration given the low complexity and presence of an output 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?
The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter semantics, and it correctly avoids inventing unnecessary 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 uses a specific verb ('Gets') and resource ('example of a GitHub Action for provisioning an app'), making the tool's purpose immediately clear. It also distinguishes itself from sibling example tools by explicitly naming the app provisioning domain, unlike getDatabaseProvisionExample or getAppDeprovisionExample.
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 implied usage is straightforward: use this tool when you need an example of a GitHub Action for provisioning an app. However, it does not explicitly state when not to use it or mention alternatives like configure or deprovision examples, leaving the distinction to the reader.
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?
No annotations are provided, so the description must itself convey safety and behavior. 'Gets an example' implies a read-only operation with no side effects, but it does not explicitly confirm non-destructiveness or describe the output format. The description adds some transparency but could be more explicit about what the example looks like.
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 sentence that front-loads the action ('Gets an example') and specifies the exact type of example ('GitHub Action for deprovisioning a database'). It contains no filler and is appropriately sized for the tool's simplicity.
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 no parameters and an output schema exists, the description is largely sufficient. It states what the tool returns, but the output schema not being shown in the input schema means the description alone doesn't fully describe the return value. Despite this, the simplicity of the tool means the description covers most essential 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 tool has zero parameters, so the baseline is 4. The description correctly avoids discussing parameters, as there are none. No additional semantic meaning is needed beyond the schema's empty property list.
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 'Gets' and identifies the resource as 'an example of a GitHub Action for deprovisioning a database'. This clearly differentiates it from sibling tools like getDatabaseProvisionExample and getDatabaseRestoreExample, making the tool's 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 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. It does not mention troubleshooting, use cases, or refer to other example tools, so an agent receives no 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says 'Gets an example,' which essentially restates the tool's name and does not disclose whether the operation is read-only, what format the example takes, or any side effects. The minimal disclosure is insufficient for a tool with no annotation coverage.
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, concise sentence that front-loads the action and resource. Every word is relevant, and there is no redundant or extraneous 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?
Given the tool's simplicity (zero parameters, existence of an output schema), the description is largely complete. It states the core purpose, and the output schema is available to explain return values, so the description does not need to elaborate further. However, a bit more context about what an endpoint is in this system or the nature of the example would improve completeness.
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 has zero parameters, so there is nothing for the description to explain about parameters. Per the calibration, a baseline of 4 applies for zero-parameter tools, and the description does not need to compensate since schema coverage is trivially complete.
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 an example of a GitHub Action for provisioning an endpoint. The verb 'gets' combined with the specific resource ('example of a GitHub Action for provisioning an endpoint') distinguishes it from sibling tools like getAppProvisionExample and getDatabaseProvisionExample, which target 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 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, but its purpose implies it should be used when an endpoint provisioning example is needed. There is no mention of alternatives or exclusions, leaving usage to be inferred from the resource type.
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?
No annotations are provided, and the description only restates the core function without disclosing behavioral traits such as pagination, ordering, or response structure. While 'all' hints at no built-in filtering, there is no mention of limits, error conditions, 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 a single sentence that immediately states the action and resource with no filler. It is appropriately minimal for a zero-parameter tool.
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 tool is simple with no parameters and an output schema that likely defines the return structure. The description clarifies scope ('all') and includes the synonym 'environments', which is sufficient given the context signals, though it could explicitly state that accounts and environments are equivalent.
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 has zero parameters with 100% coverage, so the baseline is 4. The description correctly avoids inventing parameter details, and no further elaboration is 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 uses the specific verb 'List' and identifies the resource as 'accounts/environments', with 'all' indicating full scope. This clearly distinguishes it from sibling tools like getAccountsByStack (filtered by stack) and getAccount (single account).
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 retrieving all accounts/environments, so its usage is somewhat implicit. However, it does not explicitly state when to prefer it over alternatives or mention exclusions, leaving some inference to the agent.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that the example is for deploy hooks and where the finalized file should reside, adding useful context. However, it does not explicitly confirm read-only behavior or describe any caveats, though the read-only nature is apparent from the verb 'gets'.
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 filler. It front-loads the primary purpose and then adds the key deployment context, earning a top score for efficiency.
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 no-parameter example-fetching tool, the description is sufficiently complete. It states the purpose, the target context (deploy hooks), and the expected file location, while the presence of an output schema covers return value expectations. Minor gap: no mention of when not to use it, but that overlaps with usage guidelines.
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 the schema fully covers all input semantics. The description correctly avoids repeating non-existent parameter details. Baseline 4 is appropriate since there are no parameter ambiguities to clarify.
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 an example aptible.yml configuration file specifically for deploy hooks. This distinguishes it from sibling examples like getProcfileExample or getEndpointProvisionExample, and includes the exact final file location.
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 context by mentioning deploy hooks, but does not explicitly say when to choose this tool over other example-getting siblings. No alternatives or exclusions are stated, leaving the usage guidance implicit rather than explicit.
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?
With no annotations, the description carries full burden, but it only states 'List all apps.' It does not disclose behavioral traits such as pagination, ordering, access scope, or response format. This is a minimal statement with no additional context, similar to the update_drive example.
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, front-loaded sentence of four words. Every word earns its place, and there is no redundancy or unnecessary detail. It is perfectly concise for the tool's simplicity.
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 tool is simple (no params, output schema exists), so the description is mostly complete. It does not explain return values (handled by output schema) and covers the primary purpose. Minor gaps like pagination or authorization scope are not mentioned, but given the low complexity, it's 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?
There are zero parameters, so the baseline is 4. The description adds no parameter info (as there are none), and the literal 'all' scope is the only semantic contribution. This is appropriate for a parameterless tool.
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 'List all apps.' uses a specific verb ('List') and a clear resource ('apps'), with 'all' indicating scope. It is distinct from sibling tools like getApp (which retrieves a single app) and listAccounts (which lists a different 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?
The description clearly implies the tool is used to list all apps, providing clear context for when to invoke it. However, it does not explicitly mention alternatives or exclusions (e.g., 'use getApp for a single app'), so it misses the top tier of 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?
No annotations are provided, so the description carries the full burden. It states 'Gets' which implies a read-only operation, but it does not explicitly declare side-effect-free behavior or disclose any other behavioral traits. For a trivial example-retrieval tool this is minimally acceptable, though it adds little beyond what the name suggests.
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, front-loaded sentence with 11 words. It contains no filler, repetition, or unnecessary details, making it perfectly concise and easily scannable.
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 (0 params, output schema present, no annotations), the one-sentence description is sufficient. It clearly states what the tool returns and is complete for the agent to select and invoke it correctly without additional 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 tool has zero parameters, so schema coverage is 100% by default. The baseline for 0 params is 4, and since no parameters exist, the description need not add any parameter details. It correctly avoids irrelevant 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 'Gets an example of a GitHub Action for provisioning a database' uses a specific verb ('Gets') and resource ('example of a GitHub Action for provisioning a database'), clearly distinguishing it from sibling tools like getAppProvisionExample or getDatabaseRestoreExample. The 'provisioning' modifier differentiates it from other database example 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 when to use the tool (when you need a provisioning example) but does not explicitly state alternatives or 'when not to use'. There is no mention of sibling tools or exclusions, so usage context is only implied by the tool's name and description.
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 uses the verb 'Gets' indicating a read-only retrieval, which implies no side effects. However, it does not disclose return format, whether it is a static snippet, or any other behavioral specifics. With no annotations, the description carries the burden but adds only modest behavioral context beyond the tool name.
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, front-loaded sentence that conveys the essential purpose without any filler. Every word contributes to understanding the tool's function, making it highly concise and well-structured.
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 no-parameter getter with an output schema available, the description sufficiently specifies what the tool returns (a GitHub Action example for deprovisioning an app). The output schema handles return details, and no additional context is needed for an agent to select and use this 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?
The tool has zero parameters, so the input schema is empty. The baseline for 0 params is 4, and the description appropriately avoids nonexistent parameter details. It does not need to compensate for any schema gaps.
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 gets an example of a GitHub Action for deprovisioning an app. The verb 'gets' specifies the action, and the resource is precisely differentiated from sibling tools like getAppProvisionExample and getDatabaseDeprovisionExample.
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 the tool is appropriate: when an agent needs an example GitHub Action for app deprovisioning. It does not explicitly rule out alternatives, but the purpose is specific enough that usage is evident. No explicit exclusions or alternate 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral transparency. It clearly states that the tool returns an 'example', which implies a safe read operation with no side effects. It does not elaborate on return format, but the presence of an output schema covers that. 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 a single clear sentence with no filler. It immediately states what the tool does and is well-structured and front-loaded. Every word earns its place.
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?
This is a simple, zero-parameter tool with an output schema. The description fully explains its purpose and the context of sibling tools reinforces its role. No additional details are needed for an agent to select and invoke it 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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific meaning because there are no parameters to document. Schema coverage is trivially 100% with an empty properties object.
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 the specific verb 'Gets' and clearly identifies the resource as 'an example of a GitHub Action for restoring a database from backup'. This distinguishes it from sibling example-related tools like getProcfileExample or getDatabaseProvisionExample.
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 used when you need an example of a GitHub Action for database restore. It does not explicitly mention alternatives or when not to use it, but the context of sibling tools makes the usage fairly clear. No active 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?
With no annotations, the description carries the burden of behavioral disclosure. It provides a useful placement detail ('The finalized Procfile file should be located in /.aptible/Procfile in the build Docker image') but does not explicitly state that the tool is read-only or describe the return format. The existence of an output schema mitigates this gap, but more detail on what the example contains would improve 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?
The description is concise and well-structured: three sentences, front-loaded with the core purpose, and each sentence provides relevant guidance. There is no filler or repetition of schema 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 tool with no parameters and an output schema, the description is complete. It explains what the tool returns, provides usage context (what belongs in a Procfile), and states placement requirements. No additional context is necessary for an agent to select and invoke this 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?
The tool has zero parameters, so the baseline is 4. The description adds nothing about parameters, but there are none to describe, making the baseline 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 states a specific verb+resource: 'Gets an example Procfile for defining app processes.' This clearly distinguishes it from sibling tools like getAptibleYamlExample and getEndpointProvisionExample, which serve different purposes.
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 guidance on what does not belong in a Procfile: '1-off tasks like running migrations are better suited for processes run via .aptible.yml, and do not belong in the Procfile.' This implicitly points to an alternative, but does not name a specific sibling tool, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation, and the additional context about the image id being needed for database creation adds useful behavioral information about the output's role. It does not describe side effects or permissions, but for a non-destructive listing tool with no parameters, this is adequate and beyond a mere tautology.
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 the primary action stated first and the usage context in the second sentence. Every word earns its place; there is no fluff or redundancy. It is highly concise and well-structured.
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 (0 parameters, no nested objects) and the existence of an output schema, the description is complete for its context. It explains what the tool does and why it is needed, and the sibling tools (especially createDatabase) make the relationship clear. No significant gaps remain.
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 trivially 100%. The baseline for 0 parameters is 4. The description does not need to explain parameters and does not attempt to; it focuses on the tool's purpose and usage, which 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 'available database types'. It distinguishes from sibling tools like listDatabases by specifying that this tool lists types, not existing databases, and explicitly ties it to the database creation workflow by noting the image id is needed for that.
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 usage context: 'When creating a database, the image id provided via this method is needed.' This tells the agent when to use this tool (before creating a database) and why it is necessary. It does not mention alternatives or exclusions, but the usage context is clear enough.
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:

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

Score Badge

Copy to your README.md:

[![aptible-mcp MCP server](https://glama.ai/mcp/servers/aptible/aptible-mcp/badges/score.svg)](https://glama.ai/mcp/servers/aptible/aptible-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/aptible/aptible-mcp'

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