Skip to main content
Glama
Sign In
gapify-mcp-server

gapify-mcp-server

by mh-zeynal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Messages: Get messages

gapify_get_messages
Read-onlyIdempotent

Retrieves the messages of a specific conversation using its account and conversation IDs, so support agents can review the chat history before replying, assigning, or resolving a ticket.

Instructions

List the messages of a conversation [Messages] GET /api/v1/accounts/{account_id}/conversations/{conversation_id}/messages Auth: User API key (header api-access-token). Text values may be written in Persian (Farsi) or any other language and are sent unchanged; IDs, numbers and phone numbers may use Persian or Arabic-Indic digits.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account_id": "<account_id>",
      "conversation_id": "<conversation_id>"
    },
    "name": "gapify_get_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
account_idYesThe numeric ID of the account
conversation_idYesThe numeric ID of the conversation

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

B3.2/5.0
Behavior3/5

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

The annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=true, so the safety profile is covered. The description adds two useful operational facts beyond the annotations: the required auth header ('api-access-token') and that Persian/Arabic-Indic digit handling is passed through unchanged. It does not disclose pagination behavior or result volume, which matters for a list endpoint.

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?

Front-loads the purpose in the first clause, then supplies endpoint and auth compactly. The trailing Persian/Arabic-Indic digit note is somewhat tangential but is genuinely relevant to text-bearing payloads and costs only one sentence.

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

Completeness3/5

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

For a two-parameter read-only list tool with no output schema, the annotations and 100% schema coverage carry most of the burden, and the description adds auth and text-encoding context. It still omits pagination or ordering behavior, which an agent calling a message-list endpoint would benefit from knowing.

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 both parameters already documented as numeric IDs, so the schema does the heavy lifting. The description adds no further semantics beyond echoing account_id and conversation_id in the URL template, matching the baseline of 3 for fully covered schemas.

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?

States a specific verb+resource ('List the messages of a conversation') and the endpoint path makes the scope unambiguous. However it does not distinguish itself from the sibling gapify_client_list_messages, which appears to cover a similar surface, so the sibling differentiation is not fully resolved.

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

Usage Guidelines2/5

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

The description gives no when/when-not guidance and names no alternative (e.g. gapify_get_conversation, gapify_client_list_messages, or filtering helpers). Usage is only implied by the verb and endpoint path, which is minimal for a tool with this many siblings.

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