Skip to main content
Glama

search_campaigns

Read-only

Search public campaign records with filters, sorting, and pagination. Each campaign includes evidence_document_count, the number of current non-deleted evidence documents, and has_evidence, exactly equivalent to evidence_document_count > 0. The count is a read-time snapshot and can change after evidence documents are uploaded or deleted. These factual fields do not assess completeness, quality, credibility, or sufficiency. All inputs are optional. Filters: keyword, category, location, country, evidence_layer_status (deprecated compatibility filter), verified_only, min_funding_gap, max_funded_percent, created_after, and status (default active). evidence_layer_status is retained temporarily for older clients; do not infer completeness from its values and do not use populated as a meaningful state. Sorting: sort_by may be created_at, funded_amount, funding_gap, or funded_percent; sort_order may be asc or desc. Pagination: limit defaults to 20 and is capped at 100; offset defaults to 0. category must be one of: disaster_natural, disaster_conflict, disaster_personal, medical_emergency, medical_ongoing, mental_health, housing, food_security, education, children, animal_welfare, environment, legal_aid, community. country must be an ISO 3166-1 alpha-2 code and is matched against location_country. Response includes campaigns and total_matching. Results are paginated. The response may not include all matching campaigns. The response includes has_more and next_offset. Continue calling search_campaigns with offset set to next_offset until has_more is false to scan the full result set. zooidfund does not verify campaign accuracy. Agents are responsible for their own verification. The platform makes no representations about campaign claims.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
statusNo
countryNo
keywordNo
sort_byNo
categoryNo
locationNo
sort_orderNo
created_afterNo
verified_onlyNo
min_funding_gapNo
max_funded_percentNo
evidence_layer_statusNoDeprecated compatibility filter. Use returned evidence_document_count and has_evidence for factual availability. Do not interpret partial or populated as completeness or quality.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / evidence_layer_status / description
      Added value: +"Deprecated compatibility filter. Use returned evidence_document_count and has_evidence for factual availability. Do not interpret partial or populated as completeness or quality."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond readOnlyHint, it discloses that evidence counts are read-time snapshots that can change, that factual fields do not imply quality or completeness, and that the platform does not verify campaign accuracy. These are meaningful behavioral and trust caveats an agent needs.

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?

The description is long but front-loads the core purpose, then groups filters, sorting, pagination, response, and caveats. A few pagination and liability statements repeat slightly, but the length is justified by the 14-parameter surface.

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?

For a 14-parameter search tool with no output schema, it covers the purpose, filter set, enum values, sorting, pagination mechanics, response shape (campaigns, total_matching, has_more, next_offset), and trust limitations. An agent can call it correctly and page through results without further guidance.

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?

With only 7% schema description coverage, the description does substantial work: it lists filters, enumerates category values, gives the country code format, documents sort_by/sort_order, and specifies limit/offset defaults and caps. Some parameters such as min_funding_gap, max_funded_percent, and verified_only still lack semantic detail.

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 first sentence states a specific verb (search), resource (public campaign records), and scope (filters, sorting, pagination). This clearly distinguishes it from get_campaign and get_campaign_donations without needing to open the schema.

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 explains how to use pagination (continue with offset=next_offset until has_more is false) and explicitly deprecates evidence_layer_status. It does not name sibling alternatives such as get_campaign for single-record retrieval, but the search-vs-fetch distinction is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources