Skip to main content
Glama
Sign In

Argorant

by com.argorant
OverviewDiscussionsAdmin

List reply labels

argorant_reply_statuses
Read-onlyIdempotent

List the labels replies can carry in the Unibox, with each one's key, name, description and whether it is visible. Use it to get a key for argorant_inbox_classify or argorant_inbox, and before adding a label with argorant_create_reply_status. A customer workspace has five standard labels, positive (shown as Interested), meeting_request, out_of_office, unsubscribe and neutral (shown as Other). It can switch on extra labels (not_interested, question, referral, wrong_person, meeting_booked) and add its own. It is free. More in the docs at https://docs.argorant.com/docs/agents/tools#inbox

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": "argorant_reply_statuses"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real context beyond them: the workspace-scoped standard label set with display aliases (positive shown as Interested, neutral shown as Other), which extra labels can be switched on, that workspaces can add custom ones, and that the call costs nothing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and primary usage are front-loaded in the first two sentences, with the label inventory and docs link trailing. The long enumeration of optional labels is the only thing that dilutes the opening, but it is genuinely useful for interpreting returned keys.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained, yet the description still summarizes the fields returned. Combined with the fixed-vs-optional label model and the zero-parameter signature, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4; there is no parameter surface the description needs to explain. It does not pretend otherwise or add spurious input guidance, which is the correct choice for a no-arg lister.

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?

States a specific verb and resource ('List the labels replies can carry in the Unibox') and enumerates exactly what each entry contains (key, name, description, visibility). An agent can distinguish it immediately from argorant_create_reply_status, argorant_update_reply_status, and argorant_delete_reply_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names when to use it and which sibling it feeds: 'Use it to get a key for argorant_inbox_classify or argorant_inbox, and before adding a label with argorant_create_reply_status.' The ordering dependency against the create tool is stated, leaving nothing to inference.

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

All Argorant toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources