Little Green Light MCP Server

search_constituents_advanced

Read-only

Search constituents by combining custom attribute filters (including blank/not-blank) with standard LGL filters like keyword, location, membership, groups, lists, and updated date. All filters AND together.

Instructions

Server-side constituent search combining custom attribute filters (including blank/not-blank checks) with standard LGL filters (keyword, location, membership, groups, lists, updated date) and an optional free-text query. All provided filters AND together, matching LGL's actual q[] behavior — there is no OR support. Custom attributes, keywords, groups, lists, and membership levels are all referenced by their display name (not internal LGL IDs); names are resolved and cached for the life of this server process, so only the first call referencing a given name pays a lookup round-trip. Filtering ON a custom attribute (via custom_attributes) works independently of whether its VALUE comes back in results — set include_custom_attrs to also fetch attribute values, which is otherwise omitted to keep responses small.

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

Input Schema

Name	Required	Description
`city`	No
`limit`	No
`query`	No	Optional free-text query, routed to name/email/phone like search_constituents
`state`	No	2-letter state code
`offset`	No
`country`	No
`keyword`	No	Keyword name (single keyword only — LGL's API does not support filtering by multiple keywords at once)
`list_names`	No	List display names
`updated_to`	No	YYYY-MM-DD; constituents updated on/before this date
`external_id`	No
`group_names`	No	Group display names
`postal_code`	No	Matches left-most characters
`updated_from`	No	YYYY-MM-DD; constituents updated on/after this date
`constituent_type`	No
`custom_attributes`	No	Filters on custom attributes, by their display name (e.g. 'Background Info'), not their internal key
`membership_status`	No
`include_custom_attrs`	No	Include each result's custom attribute values (name/value pairs). Off by default — filtering on custom_attributes does not require this, and turning it on adds the full value of every custom attribute (e.g. long text fields) to every result.
`membership_end_date_to`	No	YYYY-MM-DD
`membership_level_names`	No	Membership level display names
`membership_end_date_from`	No	YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.7.0Jul 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds critical behavioral details: AND-only filtering, name resolution and caching, independence of custom_attributes filtering from include_custom_attrs, and performance implications of include_custom_attrs. No contradiction with annotations.

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?

The description is comprehensive without unnecessary words. It is front-loaded with the main purpose and then details. Every sentence adds value, covering behavior, limitations, and parameter specifics. Well-structured for an AI agent.

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?

Given 20 parameters and no output schema, the description covers all critical behavioral aspects: filter combination, caching, name resolution, and the optional nature of include_custom_attrs. It provides enough context for an agent to use the tool correctly without needing external documentation.

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

Parameters5/5

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

Schema coverage is 65%; the description adds significant meaning. It explains custom_attributes structure (oneOf with blank/not_blank or with value operators), that names are display names, that keyword is single only, and that include_custom_attrs adds full attribute values. This compensates for gaps in schema descriptions.

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 it is a 'server-side constituent search' combining custom attribute filters with standard LGL filters and optional free-text query. It specifies the resource (constituents) and action (search with advanced capabilities), distinguishing it from siblings like search_constituents by highlighting custom attributes.

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?

Explicitly states that all provided filters AND together and that there is no OR support. Provides guidance on when to use include_custom_attrs vs not. Does not explicitly mention alternatives, but the context of advanced vs basic search is clear from the description and sibling list.

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

Deploy Server