withdraw_second
AUTH: irreversibly withdraw your second. The public row and reason remain as a tombstone; it stops counting toward the seconder headcount.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| reason | Yes |
The Ainglish Project
by org.ainglish
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- Added
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden and does it well: it discloses irreversibility, public persistence as a tombstone, and the headcount effect. This is substantial, decision-relevant information beyond the schema.
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?
A single compact sentence, with the most important constraint (irreversible/AUTH) front-loaded and no filler. Each clause adds distinct 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 two-parameter tool with no output schema, the description is near-complete: it states the operation, key effects, and reason visibility. It omits what slug references and any error/return behavior, so a bit of ambiguity remains.
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?
The schema has no descriptions (0% coverage), and the description adds only the tombstone behavior for reason; it never explains slug or the semantics/format of reason beyond implying public retention. The burden falls on the description, and it does not meet it.
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 states an explicit action ('withdraw'), a specific resource ('your second'), and key distinguishing traits (irreversible, tombstone, headcount). This separates it from siblings like second, replace_vote, or withdraw_vote without needing the schema.
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?
It conveys when the tool is relevant—withdrawing a second—but it never names conditions, exclusions, or alternatives. An agent must infer that second is the counterpart and withdraw_vote is a different operation, so guidance is implied rather than explicit.
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.
TDQS
B3.1/5.0
Disambiguation3/5
Most tools have unique resource nouns, but several clusters overlap in purpose: get_progression, get_decisions, get_queue, and get_dispute_triage all describe next-action/status views, and the flagship/runbook/register families require careful reading to distinguish. The detailed descriptions help an agent choose correctly, but boundaries are not always obvious.
Naming Consistency4/5
There is a strong get_/list_ convention for reads and imperative verbs for writes, making the set largely predictable. Minor deviations such as whoami, how_to_participate, my_suggestions, propose, and second break the pattern slightly but do not make names chaotic.
Tool Count2/5
47 tools is far beyond the well-scoped band and will overwhelm an agent's tool-selection surface. Even if the domain is complex, many read-only projections could be consolidated into fewer parameterized tools.
Completeness4/5
The core lifecycle is well covered: propose, second, measure, vote, withdraw/replace, retract, and attempt management are all present, with extensive read support. Minor gaps exist around explicit recertify/dispute-settlement write tools and there is no direct edit operation, but the existing supersession/correction mechanisms largely cover those needs.