Skip to main content
Glama

create_segment

Create targeted contact segments by applying custom filters to organize newsletter recipients based on specific criteria like email domains or signup dates.

Instructions

Create a new contact segment with a filter.

Filter examples: {"email": {"$like": "%@example.com"}} — contacts with example.com emails {"inserted_at": {"$gt": "2026-01-01"}} — contacts added after Jan 1

Args: name: Segment name. filter: Filter JSON object for matching contacts.

Returns: The created segment record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
filterYes

Implementation Reference

  • The underlying client method that performs the API call to create a segment.
    def create_segment(self, name: str, filter: dict) -> dict:
        """Create a new segment."""
        resp = self.session.post(f"{self.url}/api/v1/segments", json={"data": {"name": name, "filter": filter}},
                                headers=self._headers(), timeout=30)
        resp.raise_for_status()
        return resp.json()
  • mcp_server.py:231-247 (registration)
    The MCP tool registration and handler implementation that calls the KeilaClient.
    @mcp.tool()
    def create_segment(name: str, filter: dict) -> dict:
        """
        Create a new contact segment with a filter.
    
        Filter examples:
            {"email": {"$like": "%@example.com"}}  — contacts with example.com emails
            {"inserted_at": {"$gt": "2026-01-01"}} — contacts added after Jan 1
    
        Args:
            name: Segment name.
            filter: Filter JSON object for matching contacts.
    
        Returns:
            The created segment record.
        """
        return _client.create_segment(name=name, filter=filter)
Behavior2/5

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

With no annotations provided, the description carries full burden but only discloses return type ('The created segment record'). Missing critical behavioral details: whether the filter validates against existing contacts immediately, if segments are dynamic/static, error conditions, or side effects of creation.

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?

Well-structured with Args/Returns sections. The filter examples are essential rather than wasteful given the opaque object type. Slightly formal with labeled sections but efficient overall.

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?

Covers basic operation and parameters adequately, but lacks depth on segment behavior (dynamic evaluation vs static snapshot) and relationship to the contact database. Given nested object complexity and zero schema descriptions, needs more behavioral context.

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?

Excellent compensation for 0% schema coverage. Provides human-readable descriptions for both parameters ('Segment name', 'Filter JSON object for matching contacts') and crucially includes concrete syntax examples for the complex nested filter object, clarifying the query language semantics.

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?

Clear specific verb (Create) + resource (contact segment) + mechanism (with a filter). Distinguishes effectively from siblings like create_contact (individual records) and create_campaign (messaging), establishing this creates filtered groups.

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?

Provides rich filter syntax examples that implicitly guide usage, but lacks explicit when-to-use/when-not-to-use guidance versus alternatives like list_contacts or how segments relate to campaigns.

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/gwbischof/keila-mcp'

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