Loads organization-approved donation data from a VGP declaration and provides tools for verifying nonprofit identity, listing authorized donation destinations, and preparing donation URLs with prefilled parameters.
VGP server has clear, well-documented tool definitions with strong descriptions (avg 150 chars) and complete input schemas. All 4 tools are read-only and properly annotated. However, output schemas are not formally documented in the code, and parameter descriptions lack detail on constraints and error cases. Tools follow a coherent naming pattern (giving_*) but lack verb-first convention. No error handling guidance or recovery paths documented.
Return the funds or programs this nonprofit currently permits donors to select in its approved VGP declaration.
Return only the donation destinations this nonprofit explicitly lists as authorized in its VGP declaration.
Prepare an organization-authorized donation URL. This does not submit a form, charge a payment method, or complete a donation; the donor must authorize final payment.
Return this nonprofit's organization-approved Verified Giving Protocol identity and verification metadata.
Output schemas not formally documented. Tools return structured objects but LLMs cannot see field types, required fields, or nested structure. Downstream tool composition and error handling are blind.
Parameter descriptions lack constraint details. 'amount' has numeric bounds (exclusiveMinimum: 0, maximum: 1000000) but description does not mention currency, rounding, or what happens if amount exceeds max. 'frequency' description says 'read them from giving_options' instead of documenting valid values inline.
No error handling or recovery guidance. Code validates VGP version, organization approval, and authorized destinations but returns generic Error() messages. LLM cannot distinguish retryable failures (network) from user-fixable ones (no authorized destinations).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Tool names do not follow verb_noun convention. 'giving_verify', 'giving_options', 'giving_designations' are domain-specific but lack action verbs (get_, list_, describe_). LLMs infer intent from verb-first names; these require reading descriptions.
giving_prepare's 'rejected' field in response is undocumented. Code returns {url, applied, rejected} but LLM does not know what 'rejected' contains, when to expect it, or how to interpret it for user feedback.