Skip to main content
Glama

Groundbase

companies_delete

Soft-delete a company. Contacts and deals previously linked to this company become unlinked but are NOT deleted themselves. DESTRUCTIVE — confirm with the user first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations present, the description fully carries the behavioral disclosure burden. It clearly reveals the soft-delete behavior, states that linked contacts and deals are only unlinked and not deleted, and flags the operation as destructive requiring confirmation. This is unusually transparent for a delete 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?

Three concise sentences with the core action front-loaded and behavioral/safety details placed directly after it. Every sentence adds meaningful information: what the operation does, what happens to related records, and how to handle it safely.

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 single-parameter destructive delete, the description covers the action, side effects, and confirmation requirement well. It does not describe the return value or how to verify successful deletion, and there is no output schema, but those are minor relative to the safe invocation guidance provided.

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 only parameter, id, has no description in the schema (0% coverage), and the tool description does not explicitly document it. Context clues such as 'a company' imply id is the company identifier, but the description should have explicitly clarified what id refers to, especially given the lack of schema-level parameter documentation.

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?

Opens with the specific verb-resource pair 'Soft-delete a company,' making the core operation immediately clear. It then disambiguates the side effects by stating contacts and deals are unlinked but not deleted, which distinguishes it from contacts_delete, deals_delete, or a hard-delete 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 capitalized 'DESTRUCTIVE — confirm with the user first' explicitly provides an important usage condition: user confirmation is required before invoking. It does not enumerate alternatives or exclusions such as when companies_update should be preferred, so it stops short of a perfect usage guide.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources