Little Green Light MCP Server

submit_gift_for_review

Submit gifts, pledges, or goals to the Little Green Light Integration Queue for human review. Includes tribute details and constituent matching via name and email.

Instructions

Submit a gift, pledge, or goal to LGL's Integration Queue for human review, including tribute (honor/memorial) details. Provide first_name/last_name/email to match the constituent this belongs to. This does NOT write to LGL directly.

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

Input Schema

Name	Required	Description
`email`	No	Constituent's email, for matching
`fund_name`	No
`gift_date`	No	YYYY-MM-DD
`gift_note`	No
`gift_type`	No	Gift, In Kind, Pledge, Other Income, In Honor of, In Memory of, Soft Credit, Matching, Installment
`goal_date`	No
`goal_name`	No
`last_name`	No	Constituent's last name, for matching
`ask_amount`	No
`first_name`	No	Constituent's first name, for matching
`gift_amount`	No
`goal_status`	No
`team_member`	No
`check_number`	No
`deposit_date`	No
`payment_type`	No
`tribute_name`	No	"Honorary - General", "Memorial - General", or a named tribute
`campaign_name`	No
`gift_category`	No
`pledge_amount`	No
`payment_amount`	No
`write_off_date`	No
`gift_event_name`	No
`ack_mailing_date`	No
`deposited_amount`	No
`external_gift_id`	No
`gift_appeal_name`	No
`payment_interval`	No	W, B, M, Q, S, or Y
`projected_amount`	No
`write_off_amount`	No
`deductible_amount`	No
`gift_is_anonymous`	No	yes/no
`pledge_start_date`	No
`tribute_dedication`	No
`ack_mailing_template`	No
`installment_due_date`	No
`tribute_honoree_name`	No
`tribute_recipient_name`	No
`tribute_recipient_email`	No
`projected_minimum_amount`	No
`tribute_recipient_address`	No
`auto_generate_installments`	No	yes/no
`tribute_recipient_salutation`	No
`tribute_notification_template`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.7.0Jul 29, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The description adds key behavioral context beyond annotations: it explicitly states that this does NOT write to LGL directly, which clarifies the non-read-only but non-destructive nature. Annotations indicate readOnlyHint=false, so the description's emphasis on queuing for review is valuable transparency.

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 two sentences, front-loaded with the core action and key nuances (tribute details, matching fields, no direct write). Every sentence serves a purpose with no extraneous information.

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

Completeness2/5

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

Despite the complexity (44 parameters, no output schema, no required params), the description fails to explain the submission queue process, error handling, or the purpose of many parameters. It is not complete enough for an agent to effectively invoke the tool without additional context.

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

Parameters2/5

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

With only 20% schema description coverage, the description must compensate for 44 parameters. It highlights first_name, last_name, email, and tribute details, but the vast majority of parameters remain unexplained. The description adds some meaning but is insufficient given the low schema coverage.

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 verb (submit), the resource (gift, pledge, or goal), and the destination (Integration Queue for human review). It distinguishes from sibling tools like submit_note_for_review by specifying the exact entity types.

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?

The description implies when to use this tool (for gifts, pledges, goals) and mentions providing matching fields. However, it does not explicitly state alternative tools for other entities or provide when-not-to-use guidance. The context of sibling tools helps, but the description itself lacks explicit usage boundaries.

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

Deploy Server