Skip to main content
Glama

zendesk_ticket_to_gitlab_context

Formats a Zendesk ticket and its comments as a Markdown issue draft containing metadata, full conversation, and an empty Steps to Reproduce section for handoff to GitLab.

Instructions

Format a Zendesk ticket and its comments as an issue draft. Returns Markdown with ticket metadata, full conversation, and an empty Steps to Reproduce section. Use this output as the description when creating an issue in your tracker.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ticket_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The MCP tool handler that calls _get_gitlab_context to format ticket data into GitLab issue markdown.
    def zendesk_ticket_to_gitlab_context(ticket_id: int) -> str:
        """Format a Zendesk ticket and its comments as an issue draft. Returns Markdown with ticket metadata, full conversation, and an empty Steps to Reproduce section. Use this output as the description when creating an issue in your tracker."""
        return _get_gitlab_context(ticket_id)
  • Helper function that fetches the Zendesk ticket (using zenpy client), retrieves comments, and formats them as a structured Markdown document with ticket metadata, description, conversation, and steps to reproduce section.
    def _get_gitlab_context(ticket_id: int) -> str:
        try:
            client = get_client()
            ticket = client.tickets(id=ticket_id)
            comments = list(client.tickets.comments(ticket_id))
    
            subdomain = load_config().get("subdomain", "")
            ticket_url = f"https://{subdomain}.zendesk.com/agent/tickets/{ticket_id}"
    
            comment_lines = []
            for comment in comments:
                try:
                    author = client.users(id=comment.author_id)
                    author_name = author.name
                except Exception:
                    author_name = "Unknown"
    
                visibility = "Internal Note" if not comment.public else "Public Reply"
                timestamp = str(comment.created_at)[:10]
                comment_lines.append(
                    f"**[{visibility}] {author_name} ({timestamp}):**\n{comment.body}"
                )
    
            conversation = "\n\n---\n\n".join(comment_lines) if comment_lines else "_No comments._"
    
            return f"""## [Ticket #{ticket_id}] {ticket.subject}
    
    **Zendesk:** {ticket_url}
    **Requester:** {ticket.requester.name} <{ticket.requester.email}>
    **Status:** {ticket.status} | **Priority:** {ticket.priority} | **Type:** {ticket.type}
    **Tags:** {", ".join(ticket.tags) if ticket.tags else "none"}
    
    ---
    
    ## Description
    
    {ticket.description}
    
    ---
    
    ## Conversation
    
    {conversation}
    
    ---
    
    ## Steps to Reproduce
    
    <!-- Fill in from ticket context or leave for engineer -->
    1.
    2.
    3.
    
    ---
    
    _Source: Zendesk ticket #{ticket_id} — {ticket_url}_
    """
        except ConfigError as e:
            return str(e)
        except Exception as e:
            if "RecordNotFound" in str(e) or "404" in str(e):
                return f"Ticket #{ticket_id} not found or not accessible with current credentials."
            return f"Zendesk API error: {e}"
  • Registration function that uses the @mcp.tool() decorator to register zendesk_ticket_to_gitlab_context as an MCP tool.
    def register_gitlab_context_tools(mcp) -> None:
        @mcp.tool()
  • Import and call of register_gitlab_context_tools in the main server entrypoint to wire up the tool.
    from zendesk_mcp.tools.gitlab_context import register_gitlab_context_tools
    from zendesk_mcp.tools.write_comments import register_write_comment_tools
    from zendesk_mcp.tools.update_ticket import register_update_ticket_tools
    from zendesk_mcp.tools.time_tracking import register_time_tracking_tools
    from zendesk_mcp.tools.git_zen import register_git_zen_tools
    
    register_ticket_tools(mcp)
    register_comments_tools(mcp)
    register_attachment_tools(mcp)
    register_gitlab_context_tools(mcp)
Behavior4/5

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

With no annotations, the description carries the burden of behavioral disclosure. It states the tool formats and returns Markdown, implying a read-only transformation. It does not mention potential side effects or permissions, but for a formatting tool, this is adequate.

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 sentences with no filler: first defines action and result, second details output, third gives usage. Information is front-loaded and every sentence adds value.

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?

The description covers purpose, output format, and usage context. It omits error handling or prerequisites, but since an output schema exists (context indicates true), the return details are likely covered. Overall, it is sufficiently complete for a straightforward formatting tool.

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 single parameter 'ticket_id' is not explicitly described in the description, but its purpose is inferred from the tool name and context. With 0% schema coverage, the description minimally compensates by implying the identifier is a Zendesk ticket ID.

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 clearly states the tool formats a Zendesk ticket and comments into a Markdown issue draft, specifying the output sections. This is distinct from sibling tools like zendesk_get_ticket or zendesk_get_comments, which provide raw data without reformatting.

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 description instructs to use the output as the description when creating an issue, providing clear usage context. It does not explicitly mention when not to use it or compare with alternatives, but the guidance is sufficient given the tool's unique purpose.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/michaelrice/zendesk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server