Koyeb MCP Server

Server Quality Checklist

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

Latest release: v1.0.7
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in the Koyeb platform. For example, create-app vs. create-service target different entities, and get-* tools are clearly scoped to individual resource types. No tools appear to overlap in functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with hyphen separation (e.g., create-app, list-apps, get-service). The pattern is applied uniformly across all 16 tools, making them predictable and easy to understand.
Tool Count4/5
16 tools is slightly on the higher side but reasonable for a comprehensive cloud deployment platform. It covers core operations for apps, services, deployments, instances, and logs without feeling excessively bloated. The count aligns well with the platform's scope.
Completeness4/5
The toolset provides strong coverage for the Koyeb domain, including CRUD operations for key resources (apps, services, deployments, instances) and essential utilities like logs and token management. Minor gaps might include operations like deleting resources or scaling services, but core workflows are well-supported.
Average 2.5/5 across 16 of 16 tools scored. Lowest: 1.3/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 failing
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List apps' reveals nothing about the operation's behavior - no indication of whether it's paginated, what permissions are required, whether it's read-only or has side effects, what format the output takes, or any rate limits. This is completely inadequate for a tool with parameters and 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective conciseness. The description doesn't contain enough information to be useful, so its brevity is a liability. There's no structure or front-loading of critical information - it's just the bare minimum.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter with nested properties), complete lack of annotations, 0% schema description coverage, and no output schema, the description 'List apps' is completely inadequate. It fails to provide any of the necessary context for an agent to understand what this tool does, when to use it, how it behaves, or what its parameters mean.
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%, meaning none of the parameters have descriptions in the schema. The tool description 'List apps' provides zero information about the query parameter or its nested properties (limit, name, offset). The description fails completely to compensate for the schema's lack of documentation, leaving all parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List apps' is a tautology that merely restates the tool name without adding any meaningful clarification. It doesn't specify what type of apps, from what system, or what scope. While it does include the verb 'list', it fails to distinguish this tool from its many sibling list tools (list-deployments, list-instances, list-services, list-one-click-apps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling list tools available (list-deployments, list-instances, list-services, list-one-click-apps), there's no indication of what distinguishes 'list-apps' from these other listing operations. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. The description only states 'Get the list of instances', which doesn't reveal any behavioral traits such as whether this is a read-only operation, if it requires authentication, how results are paginated (implied by 'limit' and 'offset' in schema but not described), or what happens on errors. For a tool with complex filtering parameters, this lack of transparency is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence: 'Get the list of instances'. It is front-loaded and wastes no words, though this brevity comes at the cost of completeness. For conciseness alone, it scores perfectly as it uses minimal text to convey the core idea.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with 12 nested properties, no annotations, no output schema), the description is incomplete. It doesn't explain what 'instances' are in this context, how filtering works, what the output looks like, or any behavioral aspects. For a tool that likely returns a list of instances with multiple filter options, this minimal description is insufficient for an agent to use it effectively.
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 description coverage is 0% (based on context signals), meaning parameter descriptions in the schema are absent or minimal. The tool description adds no information about parameters beyond the basic action. With 1 required parameter ('query') that contains 12 nested properties for filtering and pagination, the description fails to compensate for the schema's lack of documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of instances' is a tautology that essentially restates the tool name 'list-instances'. It provides the basic verb ('Get') and resource ('instances'), but doesn't specify what kind of instances (e.g., application instances, service instances) or differentiate it from sibling tools like 'get-instance' or 'list-apps'. The purpose is minimally stated but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There are multiple sibling tools for listing resources (e.g., 'list-apps', 'list-services', 'list-deployments'), but the description doesn't explain why an agent would choose 'list-instances' over these or how it relates to 'get-instance'. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Create an app' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions required, whether this is a destructive operation, what happens on success/failure, rate limits, or what the expected output might be. This is inadequate for a creation 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 extremely concise at just two words. While this represents severe under-specification, from a pure conciseness perspective, it's maximally efficient with zero wasted words. Every word earns its place, though there are far too few words to be helpful.
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 this is a creation tool with no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what an 'app' is in this system, what happens after creation, what permissions are needed, or how this differs from related tools. The description fails to provide the minimal context needed for effective tool use.
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. The description mentions no parameters at all, even though there's a required 'body' parameter with a nested 'name' property. The description doesn't explain what 'app' means in this context or what naming constraints might exist. It adds no value beyond what the bare schema structure provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an app' is a tautology that essentially restates the tool name. While it does specify the verb ('create') and resource ('app'), it provides no additional context about what kind of app, in what system, or with what characteristics. It doesn't distinguish this tool from sibling tools like 'create-service' or 'deploy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple sibling tools that could be related (create-service, deploy, list-apps, update-service), but the description offers no context about prerequisites, appropriate scenarios, or when other tools might be better choices.
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 full burden. It states 'Get the list' which implies a read-only operation, but doesn't disclose behavioral traits like pagination behavior (implied by limit/offset in schema but not described), authentication needs, rate limits, or what happens if no deployments exist. It's minimal and lacks 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 very concise with a single sentence 'Get the list of deployments', which is front-loaded and wastes no words. However, it's arguably too brief given the tool's complexity, but within the conciseness dimension, it scores well for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 nested parameter with 5 sub-properties, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter usage, or return values, leaving significant gaps for an AI agent to understand how to invoke it correctly in context with sibling tools.
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%, so the description must compensate for undocumented parameters. The description provides no information about parameters, not even mentioning that filtering or pagination is possible. With 1 parameter (a nested object with 5 sub-properties) and no param info in the description, it fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of deployments' states a clear verb ('Get') and resource ('deployments'), but it's vague about scope and doesn't distinguish from sibling tools like 'get-deployment' or 'list-apps'. It lacks specificity about what kind of deployments or what context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention when to use 'list-deployments' instead of 'get-deployment' (which likely retrieves a single deployment) or other list tools like 'list-apps' or 'list-services'. No context or exclusions are provided.
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 provided, the description carries full burden for behavioral disclosure but provides none. It doesn't mention that this is a write operation (creating resources), doesn't discuss permissions required, doesn't indicate potential costs or resource implications, and doesn't describe what happens after creation (e.g., deployment process, status changes). This is inadequate for a complex creation 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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool name that already indicates the action ('create-service'), though the brevity comes at the cost of missing important contextual information.
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 complex creation tool with no annotations, no output schema, and a highly nested parameter structure (definition object with 15+ properties), the description is completely inadequate. It doesn't explain what a 'service' is in this system, doesn't mention the extensive configuration options available, and provides no information about the creation process or result.
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?
With 0% schema description coverage and 2 parameters (one required), the description provides no information about parameters. It doesn't mention the 'app_id' requirement, the complex 'definition' object with numerous nested properties, or the optional 'dry_run' query parameter. The description fails to compensate for the complete lack of schema 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 ('Create') and resource ('a new service inside an existing app'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create-app' by specifying creation within an existing app rather than creating the app itself. However, it doesn't specify what a 'service' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing app), doesn't differentiate from similar tools like 'update-service' or 'deploy', and offers no context about appropriate use cases or limitations.
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 full burden but offers minimal behavioral insight. 'Get' implies a read operation, but it doesn't disclose pagination behavior (though the schema hints at 'limit'), rate limits, authentication requirements, whether logs are real-time or historical, or what format/logs are returned. The description adds almost no value beyond the basic 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 extremely concise at just 5 words, with no wasted words. It's front-loaded with the core purpose. While under-specified, it's structurally efficient with every word contributing to the basic intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 nested parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain the complex filtering capabilities, return format, pagination, or behavioral constraints. The agent must rely entirely on the schema's property names without contextual guidance about how to effectively use this logging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero parameter information despite the schema having 0% description coverage and 13 nested properties under 'query'. It doesn't mention any filtering options, time ranges, or output limits. With low schema coverage and no compensation in the description, parameter understanding relies entirely on the schema's property names without contextual guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the build or runtime logs' states a clear verb ('Get') and resource ('logs'), but it's vague about scope and doesn't differentiate from potential siblings. It doesn't specify whether this retrieves all logs, filtered logs, or real-time streams, leaving ambiguity about what 'Get' entails.
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. The description doesn't mention prerequisites, constraints, or how it relates to sibling tools like 'get-deployment' or 'get-instance' that might provide log-related information. Usage context is entirely implied from the tool name.
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 full burden but only states it 'gets' a list without disclosing behavioral traits like pagination (implied by limit/offset in schema), authentication needs, rate limits, or what format the list returns. It mentions nothing about whether this is a read-only operation or has 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loaded with the core action. There's zero wasted language, though this brevity contributes to gaps in other dimensions.
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 a tool with 5 parameters (nested under 'query'), 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter usage, return format, or behavioral context, leaving significant gaps for an AI agent to understand how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. The schema shows 5 nested parameters (app_id, limit, offset, name, types) under 'query', but the description doesn't explain any of them, their purposes, or how they affect the list retrieval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the list of services' states a clear verb ('Get') and resource ('services'), but it's vague about scope and doesn't distinguish from sibling tools like 'get-service' or 'list-apps'. It specifies what the tool does at a basic level without providing differentiation from alternatives.
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 'get-service' (for single service details) or 'list-apps' (for listing apps instead of services). There's no mention of prerequisites, context, or exclusions for 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?
With no annotations provided, the description carries full burden of behavioral disclosure. While it indicates this is a mutation operation ('update'), it doesn't describe critical behaviors: whether this triggers downtime, what permissions are required, whether changes are reversible, how deployments progress, or what happens to existing configurations. For a complex deployment tool with zero annotation coverage, this is a significant gap.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool description and front-loads the essential information about what the tool does.
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?
This is a complex deployment/mutation tool with 3 parameters (including a highly nested definition object), no annotations, no output schema, and 0% schema description coverage. The description fails to provide necessary context about how the tool works, what it returns, what side effects it has, or how to use its parameters. For such a complex tool, this description is completely inadequate.
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%, meaning none of the 3 parameters have descriptions in the schema. The tool description provides absolutely no information about parameters - it doesn't mention the service ID requirement, the complex definition object, or any of the configuration options. This leaves all parameters completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('service's configuration'), and specifies the mechanism ('by creating a new deployment'). It distinguishes from simple configuration updates by mentioning deployment creation. However, it doesn't explicitly differentiate from sibling tools like 'deploy' or 'create-service'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'deploy' or 'create-service'. The description mentions deployment creation but doesn't clarify if this is for existing services only or when this approach is preferred over other deployment methods. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions deployment but lacks details on effects (e.g., whether it creates/modifies resources, requires authentication, has side effects like downtime, or involves rate limits). This is inadequate for a complex deployment 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, efficient sentence that directly states the tool's action without unnecessary words. It is front-loaded and appropriately sized, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters with nested objects, no annotations, no output schema), the description is insufficient. It lacks details on deployment behavior, outcomes, error handling, or integration with sibling tools, leaving significant gaps for an AI agent to understand and use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying 'path' is for deployment, but it doesn't clarify parameter relationships or usage context, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('deploy') and target ('a directory to Koyeb'), which is clear but vague. It doesn't specify what deployment entails (e.g., creating/updating a service, triggering a build) or distinguish it from sibling tools like 'create-app' or 'update-service', leaving the exact purpose ambiguous.
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 'create-app' or 'update-service'. The description implies deployment but doesn't specify prerequisites (e.g., existing app/service) or context, offering no help in tool 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?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It states the action but doesn't disclose permissions needed, whether it's destructive (e.g., can modify or delete data), rate limits, or output format. This is inadequate for a command execution tool with zero 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place in conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing commands in deployments, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on safety, results, error handling, and parameter usage, making it insufficient for informed 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%, so the description must compensate but adds no parameter details. It doesn't explain what 'instanceId' refers to, the purpose of 'shell' array, or how 'command' is interpreted. This fails to provide meaning beyond the bare schema, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a command') and target ('in a running deployment'), providing specific verb+resource. However, it doesn't differentiate from sibling tools like 'query-logs' or 'get-instance' that might also interact with deployments, so it doesn't fully distinguish from alternatives.
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. The description doesn't mention prerequisites (e.g., needing a running deployment), exclusions, or comparisons to siblings like 'query-logs' for log-related commands, leaving usage context implied but unspecified.
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 states the action ('Get') but doesn't describe what 'Get' entails—whether it's a read-only operation, requires authentication, returns full app details or a subset, handles errors, or has rate limits. For a tool with zero annotation coverage, this leaves significant behavioral 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 extremely concise with a single sentence that directly states the tool's function. It is front-loaded with the core action and resource, with no unnecessary words or redundancy. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with nested structure, no annotations, no output schema), the description is incomplete. It lacks details on behavior, parameter usage, output format, and error handling. For a retrieval tool in a context with multiple similar siblings, more context is needed to guide effective use.
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 1 parameter with 0% description coverage, as the schema provides no descriptions for parameters. The description mentions 'by its id', which adds minimal context about the parameter's purpose but doesn't explain the nested 'path' structure, the expected format of the ID, or any validation rules. It partially compensates for the low schema coverage but insufficiently.
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 ('Get') and resource ('an app'), making the purpose understandable. It distinguishes from siblings like 'list-apps' by specifying retrieval of a single app by ID rather than listing multiple apps. However, it doesn't explicitly contrast with 'get-instance' or 'get-service', which might have similar retrieval patterns for different resource types.
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 doesn't mention prerequisites (e.g., needing an app ID), when not to use it (e.g., for listing apps), or direct comparisons to siblings like 'list-apps' for browsing or 'get-instance' for different resource types. Usage is implied but not explicitly stated.
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 implies a read operation ('Get'), but doesn't mention permissions, rate limits, error handling, or what 'instance' refers to in this context. This is a significant gap 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it appropriately sized for a simple retrieval 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 complexity (1 parameter with nested structure, no annotations, no output schema), the description is insufficient. It doesn't explain what an 'instance' is, how to obtain IDs, what data is returned, or error cases, making it incomplete for effective tool use.
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 description coverage is 0%, so the description must compensate for the undocumented parameter. It mentions 'by its id', which adds meaning to the 'id' parameter in the schema, but doesn't explain the nested 'path' object structure or provide format examples, leaving the parameter semantics incomplete.
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 ('Get') and resource ('a specific instance'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get-app' or 'get-service', which follow a similar pattern, so it lacks sibling distinction.
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 'list-instances' or other 'get-' tools. It mentions retrieving by ID, but doesn't specify prerequisites, exclusions, or contextual usage, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it retrieves a service by ID but doesn't disclose whether this is a read-only operation, what happens if the ID is invalid, authentication requirements, or rate limits. This leaves significant gaps for a tool that likely interacts with a backend system.
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, efficient sentence with no wasted words. It front-loads the core action ('Get a specific service') and specifies the key input ('by its id'), making it easy to scan and understand quickly.
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 no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It doesn't explain what a 'service' is in this context, what data is returned, error handling, or how it differs from similar tools like 'get-app'. For a retrieval tool in a system with multiple sibling tools, more context is needed.
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 mentions the parameter ('by its id'), which aligns with the single 'id' parameter in the schema. However, schema description coverage is 0%, so the description adds basic meaning but doesn't compensate fully—it doesn't explain the 'path' nesting or provide format examples. With one parameter, the baseline is slightly above minimal.
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 ('Get') and resource ('a specific service'), making the purpose understandable. It distinguishes from siblings like 'list-services' by specifying retrieval of a single item by ID. However, it doesn't explicitly mention what 'service' refers to in this context, leaving some ambiguity.
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. The description doesn't mention prerequisites (e.g., needing a service ID), compare it to 'list-services' for browsing, or specify error conditions. Usage is implied but not explicitly stated.
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 states the tool lists apps but does not describe any behavioral traits such as pagination, rate limits, authentication requirements, or what the output format might be. This is a significant gap for a tool with zero 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, efficient sentence that directly states the tool's purpose without any redundant or verbose language. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not provide enough context about the tool's behavior, such as what the output contains or any operational constraints, which is necessary for an agent to use it effectively in a complex environment with multiple 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 schema description coverage is 100%, so there are no parameters to document. The description appropriately does not discuss parameters, earning a baseline score of 4 for not introducing unnecessary information.
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 ('one-click apps') with the clarifying parenthetical 'example applications' and specifies the platform 'on Koyeb'. However, it does not explicitly differentiate from sibling tools like 'list-apps' or 'list-services', which would be needed for a perfect score.
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 any prerequisites, context for usage, or comparisons to sibling tools such as 'list-apps' or 'list-services', leaving the agent to infer appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a read operation ('Get'), but doesn't disclose behavioral traits such as authentication requirements, error handling (e.g., what happens if the ID doesn't exist), rate limits, or the format of the returned data. This is a significant gap 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, efficient sentence that front-loads the core purpose ('Get a specific deployment') and adds necessary detail ('by its id') without any waste. It's appropriately sized for a simple retrieval 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 tool's complexity (simple retrieval), lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain what data is returned, error conditions, or usage context beyond basic identification, making it inadequate for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, with one parameter ('id') undocumented in the schema. The description adds minimal semantics by indicating the parameter is used to identify 'a specific deployment', but doesn't specify the ID format, constraints, or examples. This partially compensates for the low coverage but leaves key details unclear.
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 ('Get') and resource ('a specific deployment'), distinguishing it from sibling tools like 'list-deployments' (which retrieves multiple deployments) and 'get-app'/'get-service' (which retrieve different resource types). However, it doesn't specify what information is retrieved beyond 'by its id', making it slightly less specific than a perfect score.
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 a single deployment identified by its ID, as opposed to listing all deployments. However, it doesn't explicitly state when to use this versus alternatives like 'list-deployments' or other 'get-' tools, nor does it mention prerequisites or exclusions, leaving some contextual gaps.
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 full burden for behavioral disclosure. 'Get' implies a read operation, but the description doesn't specify whether this retrieves a stored token, generates a new one, or requires specific permissions. It lacks details about rate limits, error conditions, or what format the token is returned in.
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, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a zero-parameter tool and front-loads the essential information immediately.
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 zero-parameter tool with no output schema, the description provides the basic purpose but lacks important context. It doesn't explain what type of token is returned, authentication requirements, or typical integration patterns. While minimal for a simple tool, more behavioral context would be helpful given the absence of annotations.
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 with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents this. No additional parameter semantics are needed or provided.
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 ('Get') and resource ('Koyeb API token'), making the purpose immediately understandable. It doesn't differentiate from siblings, but since this is the only token-related tool among the listed siblings, that differentiation isn't necessary. The description is specific enough to understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 doesn't mention prerequisites (like authentication requirements), typical use cases, or relationships to other tools. The agent must infer usage from the tool name alone.
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:

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

Score Badge

Copy to your README.md:

[![mcp-server-koyeb MCP server](https://glama.ai/mcp/servers/samihalawa/mcp-server-koyeb/badges/score.svg)](https://glama.ai/mcp/servers/samihalawa/mcp-server-koyeb)

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/samihalawa/mcp-server-koyeb'

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