termix_credentials_create_new_credentialCreate a new SSH credential for an authenticated user. Provide username, password, or key details to store and manage access credentials.
Create a new credential. Creates a new SSH credential for the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| name | No | ||
| tags | No | ||
| folder | No | ||
| keyType | No | ||
| authType | No | ||
| password | No | ||
| username | No | ||
| description | No | ||
| keyPassword | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is mutating (readOnlyHint=false) and non-idempotent (idempotentHint=false). The description adds the useful scoping detail that the credential is created for the authenticated user, but it does not disclose validation, persistence, or response behavior. There is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and readable, but the first sentence ('Create a new credential') simply repeats the title and name, while the second sentence carries the real content. It is not bloated, but one sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and zero parameter descriptions, this definition is too thin to guide correct invocation. It does not explain required field combinations or return behavior. Annotations reduce the need for safety disclosure but not for invocation detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with 0% description coverage and no required fields. The description mentions none of them, leaving the agent to infer the relationship between authType, key, keyPassword, and password, and which fields are needed for password vs key auth. This fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb ('Create') and names the resource ('new SSH credential') plus the owner scope ('for the authenticated user'). It is clearly a creation operation, but it never explicitly references sibling tools like update_credential or duplicate_credential, so differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It does not say to prefer this over update_credential for existing credentials, nor does it mention prerequisites or alternatives. The only context is that the credential belongs to the authenticated user, which does not help select among the many sibling credential tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.