Octopus Deploy MCP Server

Official

by OctopusDeploy

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v2.3.1
Disambiguation4/5
Most tools have clearly distinct purposes targeting different Octopus entities (releases, deployments, accounts, certificates, etc.). However, the generic 'execute' and 'read_resource' tools overlap with the specific tools' functionality, potentially causing confusion for an agent deciding which tool to use.
Naming Consistency4/5
Tool names consistently follow a verb_noun pattern (e.g., create_release, find_accounts, list_projects). Minor deviations include 'execute' (verb only) and 'read_resource' (generic noun), but the overall pattern is predictable and readable.
Tool Count3/5
30 tools is on the heavy side for an MCP server. While Octopus Deploy is a complex product with many operations, the number feels slightly excessive. Many tools are find/list variations that could potentially be consolidated without losing clarity.
Completeness2/5
The tool surface heavily favors read operations (find_, list_, get_) while lacking specific write tools for most entities like accounts, certificates, and environments. The generic 'execute' tool can fill some gaps but requires deep API knowledge, leading to agent failures for common write tasks.
Average 4.2/5 across 30 of 30 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Mozilla Public License 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states the tool creates a release but does not disclose behavioral traits beyond that. With annotations providing no safety or idempotency hints (all false), the description should elaborate on side effects, error behavior, or post-conditions. It does not, leaving an agent with insufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core purpose. It avoids unnecessary fluff but could be slightly more structured if grouped logically.
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 14 parameters, no output schema, and sparse annotations, the description fails to provide complete context. Missing information about return values, error handling, or expected workflow prevents an agent from understanding the full tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by grouping required vs optional and noting Octopus defaults, but this is largely redundant with the schema. No additional semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'release', and identifies the Octopus Deploy context. However, it does not differentiate from sibling tools like deploy_release or find_releases, which could lead to confusion about when to use each.
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 only minimal guidance on parameter usage (required vs optional with defaults) but lacks explicit when-to-use or when-not-to-use instructions relative to alternatives. No mention of prerequisites, success conditions, or error scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety. The description adds context about project-released process links but does not disclose additional behavioral traits like authorization requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with a clear statement of purpose. It contains no extraneous information, making it efficient. However, it could integrate parameter hints without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with annotations, the description covers the core functionality but lacks details on output format, error handling, or usage tips. Given the absence of an output schema, the description could do more to specify return values.
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?
Although schema coverage is high at 80%, the description adds no information about parameters. The required 'spaceName' parameter lacks a schema description and the description does not compensate, leaving a gap in understanding for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a deployment process by ID and provides context about project vs frozen processes. It distinguishes from other tools implicitly as a read-only lookup, but does not explicitly differentiate from siblings like 'get_deployment_from_url'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or comparisons to sibling tools, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds business context (spaces keep projects/infrastructure/tenants separate) and usage hints but no additional behavioral traits beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are front-loaded with purpose, then context, then usage hint. Each sentence adds value, though some redundancy could be trimmed. Overall efficient for the information conveyed.
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 tool and the lack of output schema, the description should explain parameters and the structure of results. It fails to do so, making it incomplete for an agent to use correctly. Annotations cover safety but not functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description bears full responsibility for parameter meaning. However, the description does not mention any of the three parameters (partialName, skip, take), leaving agents without guidance on how to filter or paginate results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all spaces in the Octopus Deploy instance' with a specific verb and resource. It also explains what spaces are and distinguishes them from tenants, helping differentiate from sibling tools like find_tenants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Always use this tool first to check that the requested space exists.' Also clarifies that spaces represent team/project boundaries, not customer boundaries (use tenants for those), giving context on when to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description's claim of 'retrieves' is consistent and adds no contradictory behavior. However, it does not disclose any additional behavioral traits beyond what annotations provide, such as rate limits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the key information front-loaded. It could be slightly more efficient by combining sentences, but it avoids unnecessary fluff and is 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?
Given the tool retrieves data and lacks an output schema, the description should clarify what 'live status' includes (e.g., format, fields, pagination). It does not, leaving the agent uncertain about the return value. This is a significant gap for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it mentions 'Optionally include a tenant ID' but the schema already describes that parameter. No additional meanings or constraints are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Kubernetes live status for a project and environment'. It distinguishes itself from sibling tools, none of which mention Kubernetes, making its purpose specific and unique.
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 (to retrieve live status) but provides no explicit guidance on when to use it vs alternatives or when not to use it. There are no other similar sibling tools, so the lack of alternatives is acceptable, but explicit context would improve scoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no additional behavioral context beyond stating it retrieves missing variables. It does not explain what 'missing' means 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 concise with two sentences: one for purpose and one for filtering. It is front-loaded and uses minimal words. However, it could be slightly more structured (e.g., bullet points for filters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain the return format or what constitutes a 'missing variable.' It is adequate for a simple read tool but lacks completeness for more detailed understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 5 parameters. The description mentions optional filtering by tenant, project, or environment, but this is already evident from the parameter descriptions. No additional semantic value is provided.
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 tool name and description clearly state it retrieves missing tenant variables. It differentiates from sibling tools like 'get_tenant_variables' which likely returns all variables, by specifying 'missing values'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_tenant_variables'. The usage is implied by the tool's purpose, but the description does not provide when-to-use/when-not-to-use or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds context about filtering by partialName but does not mention pagination or other behavioral traits. With annotations covering the core safety profile, a 3 is appropriate for the added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficient and front-loaded with the main action. It could be slightly more structured but is concise and readable.
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 output schema and 4 parameters, the description is incomplete. It covers the required parameter and one optional, but ignores pagination (skip, take), leaving gaps for an agent to understand full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains spaceName (required) and partialName (optional filter) but omits skip and take entirely, leaving two parameters undocumented. This is insufficient for a 4-parameter 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 clearly states the tool lists all environments in a space, with a specific verb ('list') and resource ('environments'). It also notes the required spaceName, making the purpose unambiguous and distinct from sibling tools like list_deployments or list_projects.
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 advises using this tool early to understand configured environments, providing clear context. However, it lacks guidance on when not to use it or alternatives, which is acceptable given there are no direct siblings for listing environments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds that it lists all projects but does not disclose pagination behavior despite the presence of skip/take parameters in the schema. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main purpose, and concise. It could be slightly more structured but is generally effective with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema. The description explains what projects are but does not mention return format or pagination details. For a list tool, this is a notable omission, making it moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It explains spaceName and partialName well, but does not describe skip and take (pagination parameters). Thus, it adds partial value but leaves 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 verb 'lists' and resource 'projects in a given space', with additional context that projects manage software deployments. It distinguishes from sibling tools like 'create_release' or 'deploy_release' by focusing on listing rather than creating or deploying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the required parameter 'spaceName' and provides guidance to ask the user if not found. It also mentions optional partial name filter. However, it does not explicitly state when not to use or alternative tools, but the context is clear enough for an AI 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to reiterate safety. It adds useful context about filters and state consideration but does not describe behavior like pagination or sorting, which is relevant for a list 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 concise with two short paragraphs, front-loading the purpose and then listing filters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description covers most filters but misses skip/pagination details and does not describe the return format (e.g., array of deployments). Annotations compensate for safety but not for completeness of output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It describes the required spaceName and most optional filters (projects, environments, tenants, channels, taskState, take) with clear purpose. However, it omits the skip parameter, which is present in the schema but not addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists deployments in an Octopus Deploy space, specifying the required space name and optional filters. It distinguishes itself from sibling tools like deploy_release or get_deployment_from_url by focusing on listing deployments.
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 advises considering deployment state for latest deployments, but it does not explicitly state when to use this tool over alternatives like get_deployment_from_url for specific deployments, nor does it mention scenarios to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, so description's main addition is the dual-mode behavior. Does not disclose pagination limits, error handling, or response format; acceptable given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence summary followed by bullet list. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers core functionality for a simple read tool with 7 params and no output schema. Missing details like return format or error handling, but not critical for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 86% of parameters, including conditional usage ('only used when listing'). Description rephrases but adds no new semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes verb and resource clearly, with explicit dual-mode behavior (get by ID or list all). Distinguishes from sibling 'find_*' tools by specifying accounts.
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?
Clearly states when to use each mode (accountId provided vs omitted) and optional filters for listing. Lacks explicit alternatives or when-not-to-use guidance, but conditional usage is well explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds behavioral context by disclosing optional filtering and pagination parameters, though it does not explain error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with no extraneous content. However, the first sentence repeats the title slightly, but overall it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description covers the basic purpose and optional filters but does not describe the return format or potential errors, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema properties have no descriptions (0% coverage). The description names the parameters and their roles (required vs optional for filtering/pagination) but lacks precise semantics like the format of searchByName or the exact meaning of skip/take.
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 Git branches for a specific project, with a specific verb and resource. It distinguishes itself from sibling tools as the only branch-related operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains required parameters (spaceName, projectId) and optional filtering/pagination. It implies usage when listing branches for a known project, but does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds no extra behavioral context beyond stating it retrieves information. No contradiction, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with purpose. No redundancy or unnecessary text.
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 read-only tool, the description is adequate. It explains the tool's purpose but could optionally list the types of information returned (e.g., email, username) for extra clarity.
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?
No parameters exist, so baseline is 4. Description adds no parameter information, but none is needed since the schema covers all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('Get') and resource ('current authenticated user information'). No sibling tools perform a similar function, so no need for differentiation. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool or when not to. While the use case is obvious, the description lacks any context about alternatives or prerequisites, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read. The description adds no additional behavioral traits beyond the schema's parameter details. It does not disclose what happens on missing tenants or other 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 two sentences and a bullet list. It front-loads the purpose and efficiently conveys the variable types. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has no output schema, the description covers the core functionality and parameter choices well. It could mention the return format (list of variables) but is mostly complete for a read-only retrieval tool with strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description clarifies the variableType enum values but merely repeats schema information. It adds no new semantic meaning for other parameters like spaceName or tenantId.
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 tenant variables by type. It specifies the verb 'get' and the resource 'tenant variables', and the distinction from siblings like 'get_variables' and 'get_missing_tenant_variables' is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to retrieve specific types of tenant variables) and provides explicit guidance on the variableType parameter. However, it does not mention alternative tools for non-tenant scoped variables, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true. The description adds context about variable types but does not disclose additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and front-loads the main purpose. It includes explanatory context and an alternative, which is slightly wordy but not excessive.
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 retrieval tool with no output schema, the description sufficiently explains what is returned (project and library variables). It does not mention pagination or format, but given the simplicity, it is near-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add parameter-specific meaning beyond the schema descriptions. The description provides context about the tool's output but not about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets all project and library variable set variables for a given project. It distinguishes from the sibling tool get_tenant_variables, which retrieves tenant variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use get_tenant_variables if they need tenant variables, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds the dual-mode behavior and filtering options, which provides useful context beyond annotations. It does not discuss potential error responses or rate limits, but the safety profile is well-covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short, well-structured paragraphs. The key information is front-loaded, and every sentence adds value without redundancy. It efficiently conveys the tool's functionality.
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 complexity of 18 parameters and no output schema, the description covers the essential behaviors (two modes, filtering) and infers return type. It lacks explicit details on errors or response format, but for a read-only find tool with strong annotations, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 94%, extensively documenting each parameter. The description reinforces the conditional nature of targetId vs listing parameters but adds minimal new meaning beyond what the schema already says. This meets the baseline for high-coverage schemas.
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 'Find deployment targets (machines) in a space' and distinguishes between retrieving a single target by ID and listing all targets. This differentiates it from sibling tools like find_accounts or find_certificates by specifying the resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use each mode (targetId provided vs omitted) and lists available filters for listing. However, it does not explicitly compare against sibling tools or provide 'when not to use' guidance, which would be beneficial given the many similar find_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and idempotent. Description adds context about returning summaries with a resourceUri for full body, and explains mode selection logic. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main purpose, uses bullet points for modes. No wasted words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers modes, summary vs full body, and pagination parameters are in schema. Minor gaps: no mention of ordering or empty results, but sufficient for a read tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. Description provides overall context for modes but does not add significant new semantic detail beyond the schema descriptions (e.g., mutual exclusivity is already in schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds releases in an Octopus Deploy space. Explains three modes (by releaseId, projectId, or neither) which distinguishes it from sibling tools like create_release and deploy_release.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use each mode: specific release, project releases, or all releases. Implicitly discourages use for full release body by mentioning resourceUri for that purpose. Could explicitly mention read_resource as an alternative for full details, but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true; description confirms destructive action. Goes beyond annotations by explaining the tenanted/untenanted logic, which is a key behavioral trait.
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?
Concise, uses bullet points for clarity, front-loaded with main action. Every sentence adds value 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?
Covers core logic and decision points for 19 parameters. No output schema, but description focuses on usage rules. Lacks some detail on parameter effects, but schema covers those.
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?
100% schema coverage provides baseline of 3. Description adds value by explaining how parameters interact (tenants/environmentNames for mode determination), which is not in individual param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Deploy') and resource ('release to one or more environments'). It differentiates from sibling tools like create_release (creates releases) and run_runbook (runbooks vs releases).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use tenanted vs untenanted deployments with clear rules about tenants and environment count. Does not mention alternatives or when not to use this tool, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only, idempotent, non-destructive behavior. The description adds value by detailing the dual retrieval modes and filtering capabilities, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded with the main purpose. Each sentence adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively explains the dual modes and filter options. However, without an output schema, a brief note on return format would enhance completeness. Still, it covers the essential usage context adequately.
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 91%, so the schema already documents most parameters. The description only reiterates filtering options without adding new meaning, justifying a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool finds certificates in an Octopus Deploy space, with two modes: retrieve a single certificate by ID or list all certificates. It is specific to certificates and distinguishes itself from sibling 'find' tools for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (provide certificateId or omit) and mentions optional filters for listing. It does not explicitly compare with alternatives, but the context is clear for a find tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe read operation. The description adds behavioral context by noting that when retrieving a specific tenant, the response includes associated projects and environments, and that listing supports optional filtering and pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three well-structured paragraphs. The first sentence immediately states the core function. Each paragraph serves a purpose: core function, mode explanation, background. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's two modes, the concept of tenants, and mentions that single retrieval includes projects/environments. With comprehensive schema descriptions and annotations indicating a safe read operation, the description provides sufficient context for correct tool invocation. It could detail the output format but is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented. The description reinforces the dual mode (tenantId vs listing) and explains that filtering/pagination apply only when listing. It also adds context about what a tenant represents. This goes slightly beyond the schema, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find tenants in a space - can retrieve a single tenant by ID or list all tenants'. It uses specific verbs (find/retrieve/list) and resources (tenants), and distinguishes the two operational modes. This differentiates it from sibling tools like find_accounts or find_certificates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each mode: provide tenantId for a single tenant, omit to list all. It also states when filtering and pagination parameters apply (only when listing). However, it does not explicitly contrast with sibling tools or provide 'when not to use' guidance, though the resource-specific naming makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, destructive-false, idempotent. The description adds substantial behavior: mode behavior, mutual exclusivity of eventId with list filters, filter semantics, and performance impact of ChangeDetails. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections, bold headings, and bullet points. It is front-loaded with purpose and every sentence adds value for a complex tool with 21 parameters. Could be slightly more concise but appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 21 parameters and no output schema, the description covers modes, filter semantics, performance tips, permissions, and mutual exclusions. It lacks explicit return structure details but provides enough for an agent to use 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining filter semantics (AND/OR), performance implications, and mutual exclusivity, which go beyond the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Octopus Deploy audit log, listing specific action types (deployments, releases, etc.). It distinguishes itself from sibling tools like find_releases and list_projects by focusing on the events log.
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 detailed usage guidance: when to use search vs metadata modes, performance tips (excludeDifference), filter semantics (AND/OR), and permissions. It does not explicitly compare to alternatives but gives enough context to decide when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context about the summary fields (multiTenancyMode, environmentScope) and how they support pre-execution validation, which annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections (overview, project kinds, modes, summary). It is slightly lengthy but each sentence adds value. The structure aids quick comprehension.
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 complexity (8 parameters, multiple modes, no output schema), the description covers all necessary aspects: mode selection, parameter relationships, and summary output details. It enables correct invocation 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?
Input schema provides 100% coverage with descriptions for all 8 parameters. The description enriches this by explaining the logical groupings and mutual exclusions (e.g., runbookId vs gitRef/runbookSlug), and clarifies how parameters interact in different modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds runbooks in Octopus Deploy projects, distinguishes between DB-backed and CaC runbook modes, and differentiates from sibling tools like run_runbook. Each mode is explicitly named and scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use each mode (runbookId, runbookSlug+gitRef, gitRef alone, neither), including mutual exclusivity and required conditions. Also references get_branches for branch listing and run_runbook for execution, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description notes that runbooks execute operational processes (potentially destructive, aligning with destructiveHint:true). It discloses key behavioral details: snapshot vs gitRef for project types, and the confirm parameter requirement when client lacks elicitation support. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two paragraphs, front-loaded with the main action. Every sentence adds value. Could be slightly more structured (e.g., bullet points for project types), but overall 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?
Given 17 parameters and no output schema, the description covers main variations: tenanted runs, project types, scheduling (runAt, noRunAfter), and references related tools (find_runbooks, get_branches). Might lack details about return values or error handling, but for a runbook execution tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value beyond schema by explaining the mutual exclusivity of runbookSnapshotId and gitRef, and the context for using gitRef with Config-as-Code projects. This cross-parameter guidance improves semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a runbook against one or more environments, with examples of operational processes. It distinguishes two project kinds (DB-backed vs Config-as-Code) and implies differentiation from siblings like find_runbooks, deploy_release, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on tenanted runs (tenants/tenantTags) and project-specific parameters (runbookSnapshotId vs gitRef). Does not explicitly list alternatives or when not to use this tool, but context from sibling names makes it clear this is for executing existing runbooks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations (destructiveHint=true, etc.) by explaining the full gating logic: three-tier method policy, path validation (shape, denylist, allowlist), and elicitation requirements. It also warns that the agent cannot bypass by lying about flags. This provides complete behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and detailed, with multiple paragraphs and nested bullet points. While well-structured, it is somewhat repetitive (e.g., method gating explained in two places). It could be more concise without losing clarity.
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 complexity (6 parameters, nested objects, no output schema) and the fact it interacts with a broad REST API, the description covers all necessary contextual information: method gates, path validation, denylist, toolset allowlist, elicitation, and discovery via grep_llms_txt. This is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, but the description adds critical semantic context: method description explains read/write/delete classification, path describes validation rules (must be /api or start with /api/), and confirms parameter covers elicitation fallback. This enriches the schema significantly.
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 tool's name 'execute' is generic, but the title and description clearly state it is for executing Octopus REST requests not covered by curated tools. It specifies the scope (REST endpoints under /api) and distinguishes from sibling tools that cover specific endpoints.
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 tells agents to use this only after grep_llms_txt has shown the method and path. It also details when different HTTP methods are allowed (GET always, POST/PUT/PATCH with restrictions, DELETE with stricter gates). However, it does not explicitly list when to prefer a sibling tool over execute, though the context implies execute is a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by detailing response structure (summary vs. resource body), indicating that heavy fields are in the resource body, and explaining how to dereference the resourceUri for full 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?
Description is fairly detailed and well-structured, but slightly verbose. It uses clear sentences and separates purpose, response details, and guidance. Could be slightly more concise, but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value structure (per-environment state in summary, heavy fields in body, resourceUri for full details). Also clarifies limitations and alternative tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage. The description does not add new meaning beyond what the schema already provides for parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'customer feature toggles in an Octopus Deploy project'. It distinguishes from siblings by specifying what the tool does not do (creation, deletion, etc.) and references update_feature_toggle for modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (listing toggles with per-environment state) and when not to use (for creation, deletion, renaming, rollout-group management). Mentions update_feature_toggle as the alternative for flipping toggles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavioral traits beyond the readOnlyHint annotation: it explains how assignedToMe resolves /users/me (cached per session), the post-filtering mechanism for assignedToMe with a safety cap, and the content of the response (slim summary vs. full body via resourceUri). This context helps the agent understand performance implications and response handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and bullet points. It is somewhat lengthy but every sentence adds necessary detail. The structure aids readability, and the key points are front-loaded. Minor conciseness improvements could be made, but overall it earns a 4.
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 complexity of the tool (7 parameters, multiple modes, no output schema), the description is thorough. It explains the response format (slim summary vs. full body), how to retrieve detailed information (dereference resourceUri), and covers edge cases like the 'pending only' default. This completeness ensures the agent can use the tool effectively without missing critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The main description adds value by explaining the interactions between parameters (e.g., mutual exclusivity, when pendingOnly is ignored, the caching behavior for assignedToMe). This goes beyond the schema definitions, making the semantics richer for the agent.
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 finds interruptions (manual interventions, guided failures, deployment approvals) in Octopus Deploy. The verb 'find' combined with the specific resource 'interruptions' makes the purpose unambiguous. It distinguishes itself from sibling tools by focusing on interruptions, which are a distinct entity.
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 guidance on different usage modes based on which arguments are supplied (interruptionId, assignedToMe, regarding, none). It explains when each mode is appropriate and notes mutual exclusivity. While it doesn't explicitly compare with alternatives, the sibling tools cover different resources, so no direct alternative exists. The guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, destructive=false, idempotent=true. Description adds context: returns byte-identical bodies, how to interpret response (mimeType/text), and that it's a backstop for clients without resources/read. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and headings. Each sentence adds value, but slightly verbose; could be more concise. Still, very effective.
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?
Comprehensive: explains purpose, usage, response interpretation (mimeType/text), limitations (no task log resource), and even mentions alternative (grep_task_log). All gaps covered despite no 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 coverage 100% with one parameter. Description adds value by specifying 'pass the URI string verbatim', providing concrete examples, and explaining the origin of URIs (from other tools).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Universal fetch for any octopus:// URI' returned by other tools, specifies the exact use case, and distinguishes itself from siblings by noting that clients with native resources/read support can skip this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instructions: pass URI verbatim, examples provided, when to use (whenever you see resourceUri fields), when not to use (task log, directing to grep_task_log instead), and lists sibling tools that return URIs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true. The description adds behavioral context: it fetches the current toggle, applies patches in memory, PUTs the merged body, preserving unmentioned fields. It also explains rejection of unknown environment references. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It starts with the primary purpose, then details the scope, explicitly lists exclusions, and explains error conditions. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, destructive action, no output schema), the description covers essential behavioral aspects, error handling, and usage boundaries. It lacks mention of return values, but that is acceptable without an output schema. Overall comprehensive.
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?
Input schema covers all 7 parameters with descriptions (100% coverage). The description adds supplementary context, such as explaining that unmentioned environments are preserved, duplicates are rejected, and the confirm parameter's conditional requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Adjust an existing customer feature toggle in an Octopus Deploy project.' It specifies the narrow surface (flip environments, change rollout, update description/default state) and explicitly lists what is not exposed, distinguishing it from other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it states what is deliberately not exposed and directs users to the Octopus UI for those cases. It also explains that patches referencing unknown environments are rejected with a specific reason, and that slugs are obtained via find_feature_toggles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds value by explaining automatic space-to-name resolution and the specific return fields like taskIdForLogs and grepTaskLogHint.
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?
Well-structured with bullet points for returns and workflow. Slightly long but every sentence adds value. Could be slightly more concise, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description fully covers return values (including grep hint). Also explains handling of space IDs. Excellent for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (url) with 100% schema coverage. Description adds example URL formats and explains the required structure, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('get') and resource ('deployment details from URL'). Distinguishes from siblings like get_task_from_url and grep_task_log by stating it returns deployment context and a taskId for logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (investigating deployment issues) and a recommended multi-step workflow using sibling tools (grep_task_log, read_resource). No when-not-to but alternatives are implied via workflow steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent. The description adds beyond these: returns full task details including execution logs, automatically resolves space IDs, validates task ID format, and notes that the response is the same as a specific resource. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, but somewhat lengthy. The first sentence is clear and front-loaded. Could be slightly more concise, but overall effective.
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?
Tool is simple with one parameter and clear annotations. The description explains what is returned (full details including logs and state) and how it integrates with other tools. No output schema needed as the response is described. Complete for its 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?
Schema description coverage is 100%, and the description provides additional context such as example URLs and explains that the URL contains a task ID. This enhances meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves task details from an Octopus Deploy URL, acting as a URL-to-ID resolver. It distinguishes itself by specifying that it returns the same body as a specific resource, versus a lighter weight option for metadata only. This is a specific verb+resource combination that differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool versus the smaller resource for lightweight metadata. Provides a workflow for deployment URLs, directing to use get_deployment_from_url first and then grep_task_log. This gives clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior. The description adds significant detail: catalog size, response structure (totalMatches, totalLines, context lines), and the structured fall-through URI. 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?
Well-structured with clear sections (overview, structure, useful patterns, parameter conventions, response). Each sentence serves a purpose without redundancy.
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 7 parameters and no output schema, the description is exceptionally thorough: explains response format, provides catalog structure details, and includes practical examples. Fully equips the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds valuable context: convention mirroring GNU grep, explanation of fixedString vs regex, and practical use cases for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the Octopus API catalog using grep-style semantics, specifying both the resource (llms.txt) and the action. It distinguishes itself from siblings like read_resource and grep_task_log by focusing on the API catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool instead of reading the resource body directly due to size, and provides useful search patterns. While it doesn't explicitly list when not to use it, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds valuable context: returns only matching lines with context, response structure (totalMatches, totalLines, line numbers, context arrays, taskDetailsResourceUri), and parameter behavior. 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 concise yet thorough: two paragraphs cover purpose, usage guidelines, and parameter conventions. Every sentence adds necessary information without redundancy, demonstrating excellent structure.
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 complexity (10 parameters, no output schema), the description is fully complete. It explains the response structure, parameter semantics, and usage context, leaving no gaps for an AI agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters with detailed descriptions. The description adds further value by drawing parallels to GNU grep flags, explaining regex behavior, and clarifying nuanced options like stripPrefixes, going beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: searching a server task's activity log with grep-style semantics. It explicitly distinguishes from related tools like get_task_from_url and the details resource, ensuring no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('Use this when you know what to look for') and an alternative ('For structured access... use the details resource'). Also explains why a full-log resource is absent, reinforcing correct usage.
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 MCP server](https://glama.ai/mcp/servers/OctopusDeploy/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/OctopusDeploy/mcp-server)

Score Badge

Copy to your README.md:

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

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

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