What can you do with this server?

The Terrakube MCP Server provides comprehensive management functionalities within the Terrakube ecosystem: * Organization Management: Create, update, delete, fetch, and list organizations * Workspace Management: Create, update, delete, fetch, and list workspaces with optional VCS integration * Module Operations: Create, update, delete, fetch, and list modules with provider and registry details * Variable Handling: Create, update, delete, fetch, and list variables with support for sensitive and HCL flags The server features a robust API, TypeScript implementation for type safety and modularity, comprehensive error handling, and flexible configuration options.

Which integrations are available for this server?

Uses .ENV for flexible configuration through environment variables, allowing users to set Terrakube API URL, personal access token, and organization name. Packaged as an npm module (@terrakube/mcp-server-terrakube) that can be installed and executed with npx. Built with TypeScript for enhanced type safety and developer experience when interfacing with Terrakube's API.

How do I use Terrakube MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Terrakube MCP Server list all workspaces in the production organization" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

Terrakube MCP Server

by terrakube-io

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Terrakube MCP Server

A Model Context Protocol (MCP) server for Terrakube operations, enabling workspace management, variable handling, module operations, and organization management.

Features

Comprehensive API Integration: Full integration with Terrakube's API for seamless operations
Type Safety: Built with TypeScript for enhanced type safety and developer experience
Error Handling: Robust error handling with clear error messages
Environment Configuration: Flexible configuration through environment variables
Modular Design: Organized code structure for easy maintenance and extension

Related MCP server: Coolify MCP Server

Tools

Workspaces

`createWorkspace`

Create a new workspace in Terrakube.

Inputs:
- name (string): Name of the workspace
- organization (string): Organization name
- description (optional string): Workspace description
- vcsProviderId (optional string): VCS provider ID
- vcsRepository (optional string): VCS repository name
- vcsBranch (optional string): VCS branch name
Returns: Created workspace details

`updateWorkspace`

Update an existing workspace.

Inputs:
- name (string): Name of the workspace
- organization (string): Organization name
- description (optional string): New workspace description
- vcsProviderId (optional string): New VCS provider ID
- vcsRepository (optional string): New VCS repository name
- vcsBranch (optional string): New VCS branch name
Returns: Updated workspace details

`deleteWorkspace`

Delete a workspace.

Inputs:
- name (string): Name of the workspace
- organization (string): Organization name
Returns: Success status

`getWorkspace`

Get details of a specific workspace.

Inputs:
- name (string): Name of the workspace
- organization (string): Organization name
Returns: Workspace details

`listWorkspaces`

List all workspaces in an organization.

Inputs:
- organization (string): Organization name
Returns: Array of workspace details

Variables

`createVariable`

Create a new variable in a workspace.

Inputs:
- name (string): Name of the variable
- organization (string): Organization name
- workspace (string): Workspace name
- value (string): Variable value
- description (optional string): Variable description
- category (optional string): Variable category
- hcl (optional boolean): Whether the variable is HCL
- sensitive (optional boolean): Whether the variable is sensitive
Returns: Created variable details

`updateVariable`

Update an existing variable.

Inputs:
- name (string): Name of the variable
- organization (string): Organization name
- workspace (string): Workspace name
- value (string): New variable value
- description (optional string): New variable description
- category (optional string): New variable category
- hcl (optional boolean): Whether the variable is HCL
- sensitive (optional boolean): Whether the variable is sensitive
Returns: Updated variable details

`deleteVariable`

Delete a variable.

Inputs:
- name (string): Name of the variable
- organization (string): Organization name
- workspace (string): Workspace name
Returns: Success status

`getVariable`

Get details of a specific variable.

Inputs:
- name (string): Name of the variable
- organization (string): Organization name
- workspace (string): Workspace name
Returns: Variable details

`listVariables`

List all variables in a workspace.

Inputs:
- organization (string): Organization name
- workspace (string): Workspace name
Returns: Array of variable details

Modules

`createModule`

Create a new module.

Inputs:
- name (string): Name of the module
- organization (string): Organization name
- provider (string): Module provider
- description (optional string): Module description
Returns: Created module details

`updateModule`

Update an existing module.

Inputs:
- name (string): Name of the module
- organization (string): Organization name
- provider (string): Module provider
- description (optional string): New module description
Returns: Updated module details

`deleteModule`

Delete a module.

Inputs:
- name (string): Name of the module
- organization (string): Organization name
- provider (string): Module provider
Returns: Success status

`getModule`

Get details of a specific module.

Inputs:
- name (string): Name of the module
- organization (string): Organization name
- provider (string): Module provider
Returns: Module details

`listModules`

List all modules in an organization.

Inputs:
- organization (string): Organization name
Returns: Array of module details

Organizations

`createOrganization`

Create a new organization.

Inputs:
- name (string): Name of the organization
- description (optional string): Organization description
Returns: Created organization details

`updateOrganization`

Update an existing organization.

Inputs:
- name (string): Name of the organization
- description (optional string): New organization description
Returns: Updated organization details

`deleteOrganization`

Delete an organization.

Inputs:
- name (string): Name of the organization
Returns: Success status

`getOrganization`

Get details of a specific organization.

Inputs:
- name (string): Name of the organization
Returns: Organization details

`listOrganizations`

List all organizations.

Returns: Array of organization details

Setup

Environment Variables

Create a .env file in the root directory with the following variables:

TERRAKUBE_API_URL=<your-terrakube-api-url>
TERRAKUBE_PAT_TOKEN=<your-personal-access-token>

Installing via Smithery

To install Terrakube MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @AzBuilder/mcp-server-terrakube --client claude

Development

Clone the repository:

git clone https://github.com/azbuilder/terrakube-mcp-server.git
cd terrakube-mcp-server

Install dependencies:
```
npm install
```
Build the project:
```
npm run build
```

Usage with Claude Desktop

To use this with Claude Desktop, add the following to your claude_desktop_config.json:

{
  "mcpServers": {
    "terrakube": {
      "command": "npx",
      "args": [
        "-y",
        "@terrakube/mcp-server"
      ],
      "env": {
        "TERRAKUBE_API_URL": "<YOUR_API_URL>",
        "TERRAKUBE_PAT_TOKEN": "<YOUR_PAT_TOKEN>"
      }
    }
  }
}

Available Tools

16 tools

create-moduleC

Creates a new module in the specified organization

ParametersJSON Schema

Name	Required	Description
`description`	No	Module description
`name`	Yes	Module name
`organizationId`	Yes	Organization ID
`provider`	Yes	Provider name
`registry`	Yes	Registry URL

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states it 'creates' a new module, implying a write/mutation operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on duplicate names, or the response format. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like what the tool returns, error conditions, or behavioral details (e.g., side effects). Given the complexity of creating a module with 5 parameters, more guidance is needed to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 5 parameters (name, description, organizationId, provider, registry). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('creates') and resource ('new module'), and specifies the context ('in the specified organization'). It distinguishes from siblings like 'create-organization' or 'create-variable' by focusing on modules, but doesn't explicitly differentiate from 'edit-module' beyond the create/edit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing organization), when not to use it, or direct alternatives like 'edit-module' for updates. The context is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-organizationC

Creates a new organization with the specified name and optional description

ParametersJSON Schema

Name	Required	Description	Default
`description`	No	Organization description
`name`	Yes	Organization name

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Creates' implies a mutation, it lacks critical details: required permissions, whether the operation is idempotent, what happens on duplicate names, or the response format. For a creation tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague phrasing. It's appropriately sized for a simple creation tool with two parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a creation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects (e.g., permissions, idempotency), output details, or error conditions. The schema covers parameters well, but the overall context for safe and effective use is lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters ('name' and 'description') documented in the schema. The description adds minimal value by noting that 'description' is optional, but this is already implied by the schema's required fields. It doesn't provide additional context like naming constraints or description formatting beyond what the schema specifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Creates') and resource ('a new organization'), specifying what the tool does. It distinguishes from siblings like 'edit-organization' by focusing on creation rather than modification. However, it doesn't explicitly differentiate from other 'create-' tools (e.g., create-module, create-workspace) beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., permissions), when not to use it, or how it relates to siblings like 'edit-organization' or 'list-organizations'. The agent must infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-variableC

Creates a new variable in the specified workspace

ParametersJSON Schema

Name	Required	Description
`category`	No	Variable category (e.g., terraform, environment)
`description`	No	Variable description
`key`	Yes	Variable key
`organizationId`	Yes	Organization ID
`sensitive`	No	Whether the variable is sensitive
`value`	Yes	Variable value
`workspaceId`	Yes	Workspace ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'creates' implies a write operation, it doesn't specify permissions required, whether the operation is idempotent, what happens on duplicate keys, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a tool with good schema documentation and gets straight to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, error conditions, or how this tool relates to sibling tools. The agent would need to infer too much from the minimal description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, providing complete parameter documentation. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline expectation but doesn't enhance understanding of parameter meanings or relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('creates') and resource ('new variable in the specified workspace'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'edit-variable' or explain how creation differs from editing, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'edit-variable' or 'get-variable'. It also doesn't mention prerequisites, such as needing an existing workspace or organization, or when variable creation is appropriate versus other operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create-workspaceC

Creates a new workspace in the specified organization

ParametersJSON Schema

Name	Required	Description
`description`	No	Workspace description
`name`	Yes	Workspace name
`organizationId`	Yes	Organization ID
`terraformVersion`	Yes	Terraform version
`vcsProvider`	No	VCS provider (e.g., github, gitlab)
`vcsRepo`	No	VCS repository URL

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states this is a creation operation, implying it's a write/mutation, but doesn't disclose behavioral traits like required permissions, whether the workspace is immediately active, error conditions, or what happens on duplicate names. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by specifying the tool's purpose concisely.

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 this is a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., side effects, permissions), doesn't explain the return value, and provides minimal guidance. The high schema coverage helps, but the description doesn't compensate for the missing structural information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 6 parameters with descriptions. The description adds no additional meaning beyond implying 'organizationId' is required for context, but doesn't explain parameter relationships or usage nuances. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('creates') and resource ('new workspace'), and specifies the context ('in the specified organization'). It distinguishes from obvious non-siblings like 'edit-workspace' or 'get-workspace', but doesn't explicitly differentiate from other creation tools like 'create-organization' or 'create-module' beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing organization), exclusions, or compare with sibling tools like 'edit-workspace' for updates or 'list-workspaces' for viewing. Usage is implied by the verb 'creates' but lacks explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit-moduleC

Updates an existing module's details

ParametersJSON Schema

Name	Required	Description
`description`	No	New module description
`moduleId`	Yes	Module ID
`name`	No	New module name
`organizationId`	Yes	Organization ID
`provider`	No	New provider name
`registry`	No	New registry URL

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Updates' implies a mutation operation, but the description doesn't disclose permission requirements, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. This leaves significant behavioral gaps for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a straightforward update operation and is front-loaded with the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'details' encompasses, what the response looks like, error handling, or how this tool relates to other module operations. The agent would struggle to use this tool effectively without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage, so all 6 parameters are documented in the schema itself. The description adds no additional parameter semantics beyond the generic 'details' reference. This meets the baseline expectation when schema coverage is complete, but provides no extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Updates') and resource ('an existing module's details'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'edit-organization', 'edit-variable', or 'edit-workspace' tools, which all follow the same 'Updates an existing X's details' pattern.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'create-module' or 'get-module'. It doesn't mention prerequisites (e.g., needing an existing module), exclusions, or contextual factors that would help an agent choose appropriately among the 15 sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit-organizationC

Updates an existing organization's details

ParametersJSON Schema

Name	Required	Description
`description`	No	New organization description
`id`	Yes	Organization ID
`name`	No	New organization name

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Updates' which implies mutation, but lacks critical details: permission requirements, whether changes are reversible, error handling, or response format. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'details' encompass beyond the schema, behavioral traits like side effects, or return values. Given the complexity of updating an organization, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional meaning beyond implying 'details' might include name and description, which the schema already specifies. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Updates') and resource ('an existing organization's details'), making the purpose understandable. It distinguishes from siblings like 'create-organization' by specifying 'existing', but doesn't differentiate from other edit tools like 'edit-module' beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an organization ID), exclusions, or comparisons with similar tools like 'edit-workspace' or 'create-organization'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit-variableC

Updates an existing variable's details

ParametersJSON Schema

Name	Required	Description
`category`	No	New variable category
`description`	No	New variable description
`key`	No	New variable key
`organizationId`	Yes	Organization ID
`sensitive`	No	New sensitive flag
`value`	No	New variable value
`variableId`	Yes	Variable ID
`workspaceId`	Yes	Workspace ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states it's an update operation. It lacks critical behavioral details: whether it requires specific permissions, if changes are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain behavioral traits, error conditions, or return values, leaving significant gaps in understanding how to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'details' correspond to the schema fields, meeting the baseline for high coverage without extra value.

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 'Updates an existing variable's details' clearly states the action (updates) and resource (variable), distinguishing it from sibling tools like create-variable or get-variable. However, it doesn't specify what 'details' encompass beyond the general concept, leaving some ambiguity compared to more precise alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., variable must exist), exclusions, or comparisons to siblings like edit-workspace, leaving the agent to infer usage from the name and schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

edit-workspaceC

Updates an existing workspace's details

ParametersJSON Schema

Name	Required	Description
`description`	No	New workspace description
`name`	No	New workspace name
`organizationId`	Yes	Organization ID
`terraformVersion`	No	New Terraform version
`vcsProvider`	No	New VCS provider
`vcsRepo`	No	New VCS repository URL
`workspaceId`	Yes	Workspace ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. 'Updates' implies a mutation, but it doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (mutation tool with 7 parameters, no annotations, no output schema), the description is incomplete. It doesn't cover behavioral aspects, usage context, or output expectations, leaving significant gaps for an AI agent to understand how to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters. The description adds no meaning beyond what the schema provides—it doesn't explain parameter relationships, constraints, or usage context. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Updates') and resource ('an existing workspace's details'), making the purpose understandable. It distinguishes from 'create-workspace' by specifying 'existing', but doesn't differentiate from other edit tools like 'edit-module' or 'edit-organization' beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing organizationId and workspaceId), when not to use it, or how it differs from other edit tools in the sibling list beyond the resource name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-moduleC

Retrieves detailed information about a specific module

ParametersJSON Schema

Name	Required	Description	Default
`moduleId`	Yes	Module ID
`organizationId`	Yes	Organization ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'retrieves' information, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what 'detailed information' includes. For a tool with zero annotation coverage, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('Retrieves') and resource ('module'), making it easy to parse. Every word earns its place by conveying essential purpose without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (2 required parameters, no output schema, no annotations), the description is incomplete. It lacks details on return values, error cases, or behavioral constraints, leaving the agent with insufficient context to use it effectively beyond basic invocation. A read operation should at least hint at the data structure returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with clear parameter names and types. The description adds no additional semantic context beyond implying 'moduleId' identifies the module and 'organizationId' might scope it, but this is already inferred from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 ('Retrieves') and resource ('detailed information about a specific module'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list-modules' or 'get-organization', which would require mentioning it fetches a single module by ID rather than listing multiple.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like needing a module ID, contrast with 'list-modules' for browsing, or specify use cases like viewing module details after listing. This leaves the agent to infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-organizationB

Retrieves detailed information about a specific organization by its ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Organization ID

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation but doesn't mention whether it's read-only, what permissions are required, what happens if the ID doesn't exist, or any rate limits. The description is minimal and doesn't provide sufficient behavioral context for a tool that accesses organizational data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a data retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, what format the response will be in, or any error conditions. Given the complexity of organizational data and the lack of structured output documentation, the description should provide more complete context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the single parameter 'id' clearly documented as 'Organization ID' in the schema. The description adds no additional parameter information beyond what the schema provides, so the baseline score of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('retrieves detailed information') and the target resource ('about a specific organization by its ID'), which is a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from its sibling 'list-organizations' which presumably retrieves multiple organizations rather than a single one by ID.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through 'by its ID' - suggesting this tool is for retrieving a specific known organization rather than listing all organizations. However, it doesn't explicitly state when to use this versus 'list-organizations' or mention any prerequisites like authentication requirements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-variableC

Retrieves detailed information about a specific variable

ParametersJSON Schema

Name	Required	Description
`organizationId`	Yes	Organization ID
`variableId`	Yes	Variable ID
`workspaceId`	Yes	Workspace ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'retrieves' information, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'detailed information' includes. This leaves significant gaps for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' entails in the return value, nor does it address behavioral aspects like permissions or errors. For a read operation with three required parameters, more context is needed to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all parameters documented in the schema (organizationId, workspaceId, variableId). The description adds no additional meaning beyond implying these IDs are needed to specify the variable, which is already clear from the schema. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 ('retrieves') and resource ('specific variable') with a qualifier ('detailed information'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get-module' or 'get-workspace', which follow a similar pattern, so it misses full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention using 'list-variables' to find variable IDs first or clarify if this is for single-variable lookups versus bulk operations. The description lacks any context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get-workspaceC

Retrieves detailed information about a specific workspace

ParametersJSON Schema

Name	Required	Description	Default
`organizationId`	Yes	Organization ID
`workspaceId`	Yes	Workspace ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'retrieves detailed information,' implying a read-only operation, but doesn't specify aspects like authentication needs, rate limits, error handling, or what 'detailed information' entails. This is a significant gap for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a read operation with 2 required parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral traits, return values, or usage guidelines, leaving gaps that could hinder an agent's ability to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with clear descriptions for 'organizationId' and 'workspaceId' in the input schema. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage context, so it meets the baseline for high schema coverage.

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 ('retrieves') and resource ('detailed information about a specific workspace'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get-organization' or 'get-variable', which follow a similar pattern, so it doesn't reach the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'list-workspaces' or other 'get-' tools. It lacks context about prerequisites, such as needing organization and workspace IDs, or exclusions, leaving the agent to infer usage from the schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-modulesB

Lists all modules in the specified organization

ParametersJSON Schema

Name	Required	Description	Default
`organizationId`	Yes	Organization ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Lists' implies a read-only operation, it doesn't specify whether this requires authentication, returns paginated results, includes metadata, or has rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place by conveying essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral details and usage guidelines that would help an agent use it effectively. Without annotations or output schema, more context about what 'lists' entails would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the single parameter 'organizationId' clearly documented in the schema. The description adds no additional parameter information beyond what's in the schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Lists') and resource ('all modules in the specified organization'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-module' (which likely retrieves a single module) or 'list-organizations' (which lists organizations rather than modules), missing full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list-modules' over 'get-module' for retrieving module information, or how it relates to other list tools like 'list-variables' or 'list-workspaces'. There's no context about prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-organizationsB

Lists all organizations accessible to the current user

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a read operation ('Lists'), but doesn't mention pagination behavior, rate limits, sorting/filtering capabilities, authentication requirements, or what 'accessible' means in practice. For a list tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core functionality and appropriately sized for a simple list operation. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has clear gaps. It covers the basic purpose but lacks behavioral details needed for full contextual understanding, especially around pagination, filtering, and what 'accessible' entails. Without annotations or output schema, more behavioral context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of parameters. The description appropriately doesn't add parameter information beyond what's in the schema, maintaining a baseline of 4 for zero-parameter tools.

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 ('Lists') and resource ('organizations'), specifying scope as 'all organizations accessible to the current user'. It distinguishes from siblings like 'get-organization' (singular) and 'create-organization' (write operation), but doesn't explicitly differentiate from other list tools like 'list-modules' or 'list-workspaces' beyond resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, when to choose this over 'get-organization' for single orgs, or how it relates to other list tools. It simply states what it does without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-variablesB

Lists all variables in the specified workspace

ParametersJSON Schema

Name	Required	Description	Default
`organizationId`	Yes	Organization ID
`workspaceId`	Yes	Workspace ID

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool lists variables but doesn't describe return format (e.g., array structure, pagination), permissions required, rate limits, or whether it's read-only (implied but not confirmed). For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that immediately conveys the core functionality without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information. Every word earns its place with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with 100% schema coverage but no annotations and no output schema, the description provides basic completeness. It states what the tool does but lacks details about return values, behavioral constraints, and usage context. The description is minimally adequate but leaves the agent to infer important operational aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides (it mentions 'specified workspace' but doesn't elaborate on parameter usage or relationships). Baseline 3 is appropriate when the schema does all the parameter documentation work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Lists') and resource ('all variables in the specified workspace'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'get-variable' (singular retrieval) and 'list-modules' (different resource type), though it doesn't explicitly contrast with other list operations. The description avoids tautology by specifying scope beyond just the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid organization/workspace IDs), compare with 'get-variable' for single variable retrieval, or explain when listing variables is appropriate versus other list operations like 'list-modules'. Usage context is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list-workspacesC

Lists all workspaces in the specified organization

ParametersJSON Schema

Name	Required	Description	Default
`organizationId`	Yes	Organization ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, if it requires specific permissions, what the output format is, or any rate limits. This leaves significant gaps for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, 100% schema coverage) but lack of annotations and output schema, the description is incomplete. It doesn't explain return values, pagination, error handling, or behavioral context, which are crucial for an AI agent to use it correctly without structured guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter 'organizationId'. The description adds minimal value by implying the parameter's role ('specified organization') but doesn't provide additional syntax, format details, or constraints beyond what the schema offers.

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 ('Lists') and resource ('all workspaces'), specifying the scope ('in the specified organization'). It distinguishes from siblings like 'list-organizations' by focusing on workspaces, though it doesn't explicitly contrast with 'get-workspace' or 'create-workspace'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get-workspace' for a single workspace or 'create-workspace' for adding new ones. It lacks explicit when/when-not instructions or prerequisites, relying solely on the implied context of listing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

16 tool updatesv1.0.0Mar 25, 2025
- First observedcreate-module
- First observedcreate-organization
- First observedcreate-variable
- First observedcreate-workspace
- First observededit-module
- First observededit-organization
- First observededit-variable
- First observededit-workspace
- First observedget-module
- First observedget-organization
- First observedget-variable
- First observedget-workspace
- First observedlist-modules
- First observedlist-organizations
- First observedlist-variables
- First observedlist-workspaces

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-04-18 10:55 across 16 tools

Disambiguation5/5

Every tool has a clearly distinct purpose with no ambiguity, as each combines a specific action (create, edit, get, list) with a specific resource type (module, organization, variable, workspace). The descriptions reinforce this clarity, making misselection unlikely.

Naming Consistency5/5

Tool names follow a perfectly consistent verb-noun pattern throughout, using hyphen-separated lowercase (e.g., create-module, edit-organization). All tools adhere to this convention without any deviations or mixed styles.

Tool Count5/5

With 16 tools, the count is well-scoped for managing Terraform-like resources (modules, organizations, variables, workspaces). Each tool earns its place by covering CRUD operations across four resource types, avoiding bloat or thinness.

Completeness5/5

The tool set provides complete CRUD/lifecycle coverage for the inferred domain of infrastructure management, with create, edit, get, and list operations for all four resource types. There are no obvious gaps or dead ends in the surface.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
Telnyx A
com.telnyx.api
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Communication Cloud Platforms Cloud Storage
62

Related MCP Servers

terraform-cloud-mcp
Agent Orchestration Cloud Platforms
severity1
A
license
A
quality
C
maintenance
A Model Context Protocol (MCP) server that integrates Claude with the Terraform Cloud API, allowing Claude to manage your Terraform infrastructure through natural conversation.
Updated 10 months ago (2025-11-02 07:43 UTC)
62
23
MIT
Coolify MCP Server
Cloud Platforms Developer Tools Shell Access
StuMason
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enables AI assistants to interact with Coolify instances through natural language, allowing management of servers, applications, databases, and deployments.
Updated 2 days ago (2026-09-10 11:35 UTC)
3,056
589
MIT
AWS Terraform MCP Server
stv-io
F
license
A
quality
D
maintenance
A containerized Model Context Protocol server that enables using natural language to develop AWS infrastructure with Terraform, offering best practices guidance, security scanning with Checkov, and access to AWS provider documentation.
Updated a year ago (2025-07-18 07:37 UTC)
7
-
Dataverse MCP Server
CRM Databases
Ajscheuer
A
license
Not graded
quality
C
maintenance
A Model Context Protocol server that enables CRUD operations and querying on Microsoft Dataverse through natural language.
Updated a year ago (2025-05-29 13:14 UTC)
11
MIT

Appeared in Searches

A service for using or learning about Supabase