Skip to main content
Glama
borgels

mcp-server-telgea

by borgels

Remove Cost Threshold

telgea_remove_cost_threshold

Removes a spend cap for DATA, VOICE, SMS, or MMS usage, releasing paused usage for a team, user, or organization.

Instructions

Remove a spend cap, releasing paused usage. Requires TELGEA_ENABLE_WRITES=true on the server.

Input Schema

NameRequiredDescriptionDefault
teamIdNoTeam the threshold is for. Omit teamId and userId for the organisation.
userIdNoUser the threshold is for. Omit teamId and userId for the organisation.
usageTypeYesVOICE means international calling.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already signal a non-read-only, non-destructive mutation, and the description adds two things they don't: the side effect of releasing paused usage and the server-side write-enablement requirement. It stops short of stating idempotency or behavior when the threshold is absent, but the added context is genuinely beyond the annotations.

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?

Two sentences, zero filler: the action and its effect come first, then the operational prerequisite. Nothing is repeated from the schema or annotations.

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 3-parameter mutation with full schema coverage and annotations, the description supplies the effect and the write-gate precondition, which is what an agent most needs. It is only slightly thin on the no-threshold edge case and on pointing back to the sibling setter.

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 teamId/userId omission semantics and the VOICE enum meaning already documented in the schema. The description adds no parameter information at all, so the baseline 3 applies.

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?

"Remove a spend cap" is a specific verb+resource that clearly distinguishes this from telgea_set_cost_threshold and telgea_list_cost_thresholds by name alone. The added clause "releasing paused usage" clarifies the effect, though it doesn't explicitly contrast with the setter sibling.

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?

Usage is only implied by the name and the stated precondition (TELGEA_ENABLE_WRITES=true). There is no explicit when-to-use vs. telgea_set_cost_threshold guidance, nor what happens if no threshold is currently set.

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