Foundaree

Find the right people and ask them, in one go

find_and_ask

Hand the whole errand to Foundaree: "find me a plumber in Kochi for Saturday morning". Foundaree searches, ranks the way its website does (people free now first), sends a booking request to the best one to three, and reports who was asked. Use this instead of search_people + request_appointment when the user wants it sorted rather than a list to choose from. Needs the user’s OWN name and phone number, which they gave you, and their clear yes before calling: real people will be contacted. Each person asked calls the user back if they can take it; nothing is confirmed until they do, so say that. Keep the returned errandId and use check_errand later to see who said yes. No account needed.

Input Schema

TableJSON Schema

Name	Required	Description
`area`	No	Neighbourhood, e.g. Kakkanad. Optional.
`name`	Yes	The user's own name, as they gave it.
`need`	Yes	What the user needs done, in a sentence or two.
`when`	Yes	When they would like it, in plain words, e.g. 'Saturday morning' or 'today after 5 pm'.
`phone`	Yes	The user's own phone number, with country code when known, e.g. +91 98470 12345. The person calls back on it.
`howMany`	No	How many people to ask, 1 to 3. Two is a good default: a choice without pestering.
`language`	No	Only ask people who work in this language, e.g. Malayalam. Leave out if any language is fine.
`location`	No	City, e.g. Kochi. Strongly recommended.
`workType`	No	local_service for trades, repairs, driving and care; professional for office work. Leave out if unsure.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

addedInput schema / properties / language

Added value: +{
+  "description": "Only ask people who work in this language, e.g. Malayalam. Leave out if any language is fine.",
+  "maxLength": 40,
+  "minLength": 1,
+  "type": "string"
+}

AddedSep 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, the description discloses key behavioral traits: real people will be contacted, their call-back is the only confirmation mechanism, nothing is confirmed until they call, and no account is needed. It also warns that consent is required before acting, which is critical for an external-contact side effect. This does not contradict the annotations.

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 longer than a terse tool doc, but every sentence earns its place: the example, ranking behavior, alternative tool routing, consent warning, confirmation semantics, and next step all add operational value. It is front-loaded with the core action and ends with practical return handling.

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 tool with 9 parameters, no output schema, and real-world side effects, the description is complete enough. It explains the return artifact (errandId), the follow-up tool (check_errand), the confirmation model, and the consent requirement. There is no output schema, so the description appropriately carries the return-value explanation.

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?

Schema coverage is 100%, so the baseline is 3. The description adds value by emphasizing that name and phone must be the user's own details and by connecting the 'best one to three' behavior to the howMany parameter and the ranking behavior. This goes slightly beyond the schema without repeating it.

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 is specific and action-oriented: Foundaree searches, ranks, sends booking requests, and reports who was asked. It also clearly differentiates from siblings by saying 'Use this instead of search_people + request_appointment' when the user wants a sorted outcome rather than a list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives an explicit decision rule: use this instead of search_people + request_appointment when the user wants the whole errand handled and sorted. It also states prerequisites (user's own name/phone, clear consent) and directs the agent to check_errand later, so when-to-use and follow-up are both covered.

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

All Foundaree tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?