Skip to main content
Glama
doitintl

DoiT MCP Server

Official
by doitintl

create_asset

Destructive

Create a new cloud asset by specifying its type and mode, along with account details like root email and account name.

Instructions

Manage cloud resources or services in your cloud environment. Creates a new asset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
typeNo
rootEmailNo
accountNameNo
customerContextNoScope the request to a specific customer by ID. Required for DoiT employees (whose token isn't tied to a single customer); omit for direct customer users.
Behavior2/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, which align with creating an asset. However, the description adds no behavioral details beyond what annotations already convey, such as idempotency, side effects, or required permissions.

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

Conciseness3/5

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

The description is short (two sentences) but the first sentence is generic and could be removed. It front-loads the action but does not earn its place with specific details. Conciseness is adequate but not optimal.

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

Completeness2/5

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

Given the tool has 5 parameters with zero required fields, no output schema, and many siblings, the description fails to provide sufficient context. It does not explain what an asset is, how parameters like mode or type affect the creation, or what the outcome looks like.

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

Parameters2/5

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

Schema description coverage is only 20% (one parameter described), but the description does not provide any parameter guidance. The parameter names (mode, type, rootEmail, accountName) are left unexplained, relying solely on their names which may be ambiguous.

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

Purpose3/5

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

The description states 'Creates a new asset' which gives a general purpose, but it is vague and does not differentiate from many other create_* siblings (e.g., create_account_role, create_budget). The first sentence 'Manage cloud resources or services' is overly broad and does not specify what constitutes an asset.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives like create_account_role or create_budget. There is no mention of prerequisites, required parameters, or scenarios where this tool is appropriate.

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

Install Server

Other Tools

Latest Blog Posts

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

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