Skip to main content
Glama
Sign In
solidtime-mcp

solidtime-mcp

by si-essence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

solidtime_organization_delete

DestructiveIdempotent

Permanently delete a Solidtime organization, requiring the account password; omit confirm to preview the irreversible action as a dry run.

Instructions

Delete an organization. DELETE /api/v1/organizations/{organization}. Irreversible. Omit confirm for a dry-run.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "solidtime_organization_delete"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNoSet to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.
passwordNoAccount password. Required by Solidtime to delete an organization.
organization_idNoOrganization UUID. Falls back to SOLIDTIME_ORGANIZATION_ID, then a single membership from GET /v1/users/me/memberships.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is largely covered. The description adds the irreversibility emphasis and the dry-run default, but omits what actually gets destroyed (members, projects, time entries) and the password re-authentication requirement beyond what the schema states.

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?

Four short clauses, front-loaded with the verb and resource, then the endpoint, then the risk, then the safe path. Nothing is wasted; the terse fragments ('Irreversible') carry real 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?

For a destructive, zero-required-parameter tool with no output schema, the description covers the essential risk and the dry-run mechanism. The main gap is blast radius — an agent cannot tell from the description what related data is removed with the organization.

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 confirm/omit-dry-run semantics, the password requirement, and the organization_id fallback chain are already fully documented. The description's dry-run mention merely restates the confirm parameter rather than adding new meaning.

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 names a specific verb and resource ('Delete an organization') and pins the exact API route, so an agent can immediately separate it from solidtime_organization_get, _create, _update, and from entity-specific siblings like solidtime_project_delete.

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?

'Omit confirm for a dry-run' gives an explicit operational path for previewing before committing, and 'Irreversible' flags the risk. It stops short of stating when to prefer this over solidtime_organization_update or what preconditions (ownership, last-org restrictions) must hold.

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

Deploy Server

Other Tools