Find US food pantries near a ZIP or City, ST, and look up a State's TEFAP rules with sources. Free.
Scored across 2 tools
The tools have highly distinct and non-overlapping functions: one provides geographic location data, while the other provides specific regulatory and eligibility policy information.
Both tools adhere to a consistent snake_case naming convention, making them highly readable and predictable for an agent to use.
With only 2 tools, the server is minimalist, but this count is appropriate for such a highly specific and well-defined niche (Food Pantry Finder and TEFAP rules).
The tools provide comprehensive coverage of the stated goals, covering location-based searches and detailed regulatory knowledge without significant functional gaps.
Find nearby food pantries for someone who needs food. Give a location — a US ZIP code, "City, ST", or "lat,lng" — and it returns the closest pantries with address, phone, website and distance, from a directory of ~17,000 US food pantries. Use it when someone asks where to get free food or find a food pantry. Free, no signup. Call the pantry to confirm hours and eligibility before visiting — this tool does not have live hours.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many pantries to return (default 5, max 15). | |
| location | Yes | US ZIP code, "City, ST", or "lat,lng". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as read-only, idempotent, and non-destructive. The description goes beyond this safety profile by disclosing the ~17,000-entry dataset, the absence of live hours, the instruction to call the pantry, and that it is free with no signup. This is useful context, though it does not address potential errors or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose, then compactly cover input formats, output details, usage context, and the live-hours caveat. There is no filler and every sentence contributes to helping the agent decide and invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing return fields (address, phone, website, distance) and input formats, plus the data source size and a key limitation. For a two-parameter tool with full schema coverage and no siblings, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'location' and 'limit' documented including examples, defaults, and max. The description repeats the location formats but adds little beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Find nearby food pantries' and enumerates exactly what the tool returns: closest pantries with address, phone, website, and distance. Even with no siblings, the verb+resource+scope is specific and distinguishes the tool's directory of ~17,000 US food pantries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use it when someone asks where to get free food or find a food pantry', which is clear use-case guidance. There are no sibling tools or alternatives, so exclusions are not needed; the absence of a 'when not to use' is not a meaningful gap here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Emergency Food Assistance Program (TEFAP) rules a food pantry follows in one US State or DC: income limit as a percent of the federal poverty guidelines, categorical eligibility, the eligibility form and how often the declaration is renewed, whether clients sign at each visit and e-signatures are allowed, proxy rules, what may not be required (ID, address, birth dates), record retention, civil-rights complaint forwarding and reporting. Each answer lists its sources (State agency and food bank publications) and the date they were verified. Free, no signup.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter State code or State name (50 States and DC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). Beyond that, the description adds genuinely useful behavior: each answer cites its State agency and food bank sources with a verification date, and use is free with no signup. It does not state what happens when a state has no verified rules, which is the main remaining behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Scope is front-loaded in the first clause, followed by a dense but purposeful enumeration of rule topics and then two short sentences on sourcing and cost. The topic list is long but every item describes actual returned content, so it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value information, and it does: it lists the rule facets returned plus the per-answer source citations and verification dates. It falls short only on failure/empty-case behavior and response shape, which are minor for a single-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter and 100% schema description coverage plus examples (OH, Texas, DC), the schema already does the work. The description only reinforces the domain ('one US State or DC') and adds nothing about accepted formats or behavior for ambiguous input. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by expanding the acronym and stating the exact resource: the TEFAP rules a food pantry follows in one US State or DC. It then enumerates the specific rule topics covered, so an agent knows precisely what it retrieves. It does not name or contrast the sibling find_food_pantry, but the subject matter (rules vs. pantry locations) is distinct enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the tool is a per-state lookup, and 'one US State or DC' signals the granularity. There is no explicit statement of when to call this versus find_food_pantry, nor any prerequisite or exclusion (e.g., what to do for a state with no published rules). Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
tefap_rulesfind_food_pantryUS food pantries, meal programs, SNAP and WIC help from Feed America (EIN 92-1761881)
Find US senior benefits by ZIP and check eligibility via deterministic rules citing .gov sources.
Free US data lookups: ZIP demographics, CISA KEV/EPSS CVEs, domain rank, county spending, recalls.
Free US data lookups: ZIP demographics, CISA KEV/EPSS CVEs, domain rank, county spending, recalls.
Add one secure layer between your agents and this server.
