Foundaree

Server Details

Find and book real people by skill, city and availability: doctors, developers, plumbers and more.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.9% over 25 days
Last Tested: 2026-10-13 23:42
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-09-27 09:35 across 14 tools

Disambiguation4/5

Most tools target clearly distinct resources or actions, and the descriptions explicitly steer agents between overlapping workflows like find_and_ask versus search_people + request_appointment, and match_people versus search_people. Some ambiguity remains between check_errand and my_bookings for 'what is waiting', and between find_and_ask and request_appointment, but the guidance largely resolves it.

Naming Consistency4/5

All names use snake_case, and most follow a verb_noun pattern such as search_people, get_person, and respond_to_booking. The set is slightly inconsistent because my_bookings and my_connection_requests are possessive noun phrases without a verb, and find_and_ask is verb_and_verb, though the overall convention remains readable.

Tool Count5/5

14 tools fit well within the recommended 3–15 range and each one maps to a distinct capability: people/organization/opportunity search, booking and response, profile draft creation, availability setting, connections, and managed errands. No tool appears redundant enough to remove.

Completeness4/5

The surface covers the core marketplace lifecycle: discovery, profile creation, availability, booking requests, responses, connections, and managed errands. Minor gaps exist, such as no tool to check the status of a direct request_appointment after it is sent (only find_and_ask errands have check_errand) and no general profile editing beyond the initial draft and availability toggling.

Available Tools

14 tools

check_errandSee who answered an errandA

Read-onlyIdempotent

Inspect

Check on an errand started with find_and_ask: which of the people asked have accepted, declined or not answered yet. Use it when the user asks "did anyone get back to me?". Someone who accepted will call the user on the number they gave; Foundaree does not arrange the time.

ParametersJSON Schema

Name	Required	Description	Default
`errandId`	Yes	The errandId that find_and_ask returned.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavior beyond that: accepted people will call the user, and Foundaree does not arrange the time. This helps the agent set user expectations. No contradictions with annotations.

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 three sentences, front-loaded with the core purpose, then the usage trigger, then a key behavioral caveat. Every sentence earns its place, with no filler or repetition.

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 read-only tool with one parameter and no output schema, the description covers everything an agent needs: what the tool reports (accepted/declined/not answered), when to invoke it, and the real-world action after acceptance. The schema and annotations handle the rest, making the definition complete.

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

Parameters3/5

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

Schema coverage for errandId is 100%, so the description does not need to restate the parameter type or constraints. It does reinforce that the errandId comes from find_and_ask, which matches the schema description. This adds minimal extra meaning, so the baseline of 3 is appropriate.

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 states a specific verb ('Check') and resource ('an errand started with find_and_ask'), then details the exact outcome ('which of the people asked have accepted, declined or not answered yet'). It clearly distinguishes this tool from siblings, especially find_and_ask which creates the errand, and the title reinforces the purpose.

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 trigger ('Use it when the user asks "did anyone get back to me?"') and ties the tool to errands created by find_and_ask. It implies this is the status-check companion to find_and_ask, making the when-to-use unambiguous.

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

create_profile_draftPut the user on FoundareeAInspect

Start a Foundaree profile for the user. Use it only when the user asks to join Foundaree, to be listed on it, or to create their own profile. Fill in only details the user gave about THEMSELVES: never about someone else, and never guess. Only name is required. Nothing is published: this saves a private draft and returns one link (finishUrl). The user opens it, checks the profile, signs in and taps Publish; until then nobody can find it. Show the user the link. It works once, for 7 days. Nobody is emailed or texted.

ParametersJSON Schema

Name	Required	Description
`bio`	No	A few sentences about them: experience, languages, the work they take.
`area`	No	Neighbourhood or area they work in within the city, e.g. 'Kakkanad'.
`name`	Yes	The person's own name, as they gave it.
`phone`	No	Their phone number, with the country code when they gave one. Shown only if they choose so when publishing.
`skills`	No	Skill names, e.g. ['Pipe fitting', 'Leak repair'].
`intents`	No	What they are open to.
`category`	No	Their trade or job as a short lowercase slug, e.g. plumber, electrician, carpenter, driver, cleaner, tutor, software-engineer, designer, accountant.
`headline`	No	One short line about their work, in their words.
`location`	No	Their city, e.g. 'Kochi' or 'Kochi, Kerala'.
`whatsapp`	No	Their WhatsApp number. Shown only if they choose so when publishing.
`githubUrl`	No	Their GitHub page (http:// or https://).
`lookingFor`	No	The kind of work they want, as short tags, e.g. ['weekend jobs'].
`linkedinUrl`	No	Their LinkedIn page (http:// or https://).
`availability`	No	available = free now; open_to_offers = open to work; not_looking = not looking right now.
`portfolioUrl`	No	Their own website (http:// or https://).

Output Schema

ParametersJSON Schema

Name	Required	Description
`summary`	Yes	One line: whose draft it is, and that nothing is public yet.
`expiresAt`	Yes	When the link stops working (ISO 8601).
`finishUrl`	Yes	The link to give the user: they check the profile, sign in and publish there.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say the tool is non-read-only, non-idempotent, and non-destructive. The description goes far beyond that by disclosing that nothing is published, a private draft is saved, a one-time 7-day finishUrl is returned, and nobody is emailed or texted. This is rich behavioral context that annotations alone would not provide.

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?

Every sentence adds a distinct fact: purpose, usage scope, data-filling rule, publication behavior, link lifetime, and notification side effect. It is slightly long but tightly packed and front-loaded with the primary action.

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 15-parameter mutation with an output schema, the description covers when to call, what to fill, side effects, and the required post-call action ('Show the user the link'). It also explains the draft's privacy and one-time-use behavior, leaving no significant gap for an agent to invoke it correctly.

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 description coverage is 100%, so the baseline is 3. The description adds a cross-parameter rule: fill only details the user gave about themselves and never guess, plus 'Only name is required.' This is meaningful guidance across all 15 parameters and helps prevent hallucinated values.

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?

States a specific verb + resource: 'Start a Foundaree profile for the user.' It clearly distinguishes from sibling read/search tools like get_person, search_people, and match_people by focusing on creation/joining rather than retrieval.

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?

Explicitly scopes when to use: 'Use it only when the user asks to join Foundaree, to be listed on it, or to create their own profile.' It also instructs to never fill details about someone else, effectively excluding look-up scenarios.

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

find_and_askFind the right people and ask them, in one goAInspect

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.

ParametersJSON 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.

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.

get_personGet a person profileB

Read-onlyIdempotent

Inspect

Retrieve the full public profile for a username, including skills, experiences, projects, services (what they offer with prices: name, price in whole currency units or null for "ask", currency, per job/hour/day/visit/session/month, from = starting price, note), licence (a registration number Foundaree's admin looked up on its public register, e.g. a doctor's NMC number: body, number, checkedAt; only once verified, and then "licence" is also in verifiedBy), and the phone, WhatsApp and contact email (phone, whatsapp, contactEmail) when the person made them public. workProof, when at least one kind is proven, is a count, not a score: "Proof: proven of total" over GitHub, website and LinkedIn (LinkedIn has no proof yet), with the facts of each proven one: github (public facts of a GitHub account they proved is theirs by signing in with it: repos, stars, followers, top languages, last push, and when Foundaree read them) and website (their website links back to this profile). person.updatedAt is when they last edited the profile. Returns structured JSON with success, found and person fields. Each answer has two views: the text content is the JSON described above, and the structured content is a profile-card list (people, total, query). In apps that support MCP Apps (ChatGPT, Claude) the cards render as Foundaree profile cards. A person with foundareeRole ("founder" or "team") is part of Foundaree's own team; only Foundaree sets it.

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	Username of the person, e.g. "maya-chen"

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes
`total`	Yes
`people`	Yes

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuine behavioral context beyond them: contact fields are returned only 'when the person made them public', licence data appears only 'once verified', and role assignment is Foundaree-controlled. These are useful disclosures, though they focus more on data semantics than on tool operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single purpose sentence is well front-loaded, but it is followed by an extremely dense run-on cataloguing dozens of output fields. Much of this duplicates the output schema, and the length makes it hard to extract the actionable part.

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

Completeness4/5

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

The task is simple (one required param, read-only), and the description plus annotations plus output schema cover it fully, including the `success`/`found`/`person` result shape. If anything it is over-complete, since it re-explains return values the output schema already owns.

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

Parameters3/5

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

Schema coverage is 100% and there is a single `username` parameter already documented in the schema. The description adds no format, casing, or resolution guidance beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Retrieve the full public profile for a username.' An agent can tell this is a targeted lookup rather than a search. It never explicitly names search_people as the alternative, so sibling differentiation is implied rather than stated.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given. The description never contrasts this with search_people or explains that a username must already be known. Usage is only inferable from the required `username` parameter.

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

match_peopleMatch people to a requirementA

Read-onlyIdempotent

Inspect

Rank public Foundaree profiles against a list of required skills — use when the user describes a need ("a co-founder who knows React and has sold to enterprises", "a dentist in Pune", "someone to rewire my kitchen in Kochi") rather than searching for a known person. Give the required skills as skills (or describe the need in q; skill terms are then derived from it and q also narrows candidates by full text). location, area, workType, category, availability and lookingFor are hard filters; the skills only score: score = matched ÷ required (0–1), where a listed skill counts 1 and a term found in the person's category or lookingFor counts ½. Someone with 3 of 5 skills still appears, below someone with 5; ties break on availability (available first), then founding members (Foundaree's first 150 members), then recency. When nobody matches a single skill, the filtered candidates come back with score 0 and fallback: true instead of an empty list. Returns JSON with items (each: person, score, matchedSkills, missingSkills, profileUrl), total, requiredSkills and fallback. Each answer has two views: the text content is the JSON described above, and the structured content is a profile-card list (people, total, query). In apps that support MCP Apps (ChatGPT, Claude) the cards render as Foundaree profile cards. A person with foundareeRole ("founder" or "team") is part of Foundaree's own team; only Foundaree sets it.

ParametersJSON Schema

Name	Required	Description
`q`	No	Free-text description of the need, e.g. "someone with React and PostgreSQL experience". Used to derive skills when `skills` is absent, and as a full-text filter.
`area`	No	Optional neighbourhood filter within the city (case-insensitive substring), e.g. "Kakkanad"
`limit`	No	Maximum number of ranked results. Defaults to 20.
`skills`	No	The required skills, e.g. ["React", "PostgreSQL", "Kubernetes"]. Required unless q is given.
`category`	No	Optional comma-separated trade/profession filter (OR semantics), e.g. "driver" or "carpenter,electrician"
`location`	No	Optional location filter (case-insensitive substring), e.g. "Bengaluru" or "Kochi"
`workType`	No	Optional audience filter: local_service = blue-collar jobs, hands-on work (electricians, carpenters, drivers, cleaners, carers...); professional = white-collar jobs, office and professional work (developers, designers, accountants...)
`lookingFor`	No	Optional comma-separated looking-for filter (AND semantics), e.g. "cofounder" or "job,freelance"
`availability`	No	Optional availability filter (exact match)

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes
`total`	Yes
`people`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description adds substantial behavior beyond them: the scoring formula (matched/required, with 1 vs ½ weighting), tie-break order, the score-0 fallback flag, the dual text/structured response views, and the meaning of foundareeRole.

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?

Front-loaded with purpose and usage before mechanism, and every sentence carries information. It is dense and long, with some detail (e.g. Foundaree's first 150 members) that is more trivia than decision-relevant, but nothing is truly wasted.

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?

Despite 9 parameters and no required fields, the description covers filtering vs scoring, tie-breaking, fallback, and return shape/views, so an agent can call and interpret it correctly. The output schema is even restated helpfully rather than left unexplained.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds semantics the schema does not: which params act as hard filters (location, area, workType, category, availability, lookingFor) versus which only score (skills), and how q both derives skills and narrows by full text.

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?

States a specific verb+resource ('Rank public Foundaree profiles against a list of required skills') and immediately contrasts with 'searching for a known person', which cleanly separates it from siblings like search_people and get_person.

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?

Gives explicit when-to-use triggers with concrete example queries and an explicit when-not ('rather than searching for a known person'), plus the skills-vs-q decision rule. Routing is unambiguous.

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

my_bookingsThe user's own booking requestsA

Read-onlyIdempotent

Inspect

List the booking requests people sent to the signed-in user: who asked, what they need, when, and whether it is still waiting for an answer. Use it when the user asks what is waiting on Foundaree, who wants to book them, or what they have not answered yet. Needs the user to have connected their Foundaree account. Lead with the ones still waiting, and offer to answer them with respond_to_booking.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: results are sorted with waiting ones first, the user must have connected their Foundaree account, and the status is framed as waiting for an answer. This goes beyond annotations, though it could mention edge cases like an empty account.

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?

Four short, purposeful sentences. The first defines the output content, the second gives usage triggers, the third states the prerequisite, and the fourth suggests a next action. No filler or repetition of schema/annotation data.

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?

Despite lacking an output schema, the description explains the returned content (who, what, when, status) and behavior (pending first). For a no-parameter read-only tool with strong annotations, everything needed to select and invoke it correctly is present.

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?

There are zero parameters and the schema is empty, so the baseline is 4. The description clarifies that the tool implicitly operates on the signed-in user's identity, which adds meaning beyond the empty schema even though no parameters need explanation.

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 opens with a specific verb and resource: 'List the booking requests people sent to the signed-in user,' and enumerates exactly what is shown (who asked, what they need, when, pending status). This clearly distinguishes it from siblings like my_connection_requests or request_appointment.

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?

It gives explicit triggers: 'Use it when the user asks what is waiting on Foundaree, who wants to book them, or what they have not answered yet.' It also names a prerequisite (connected Foundaree account) and routes follow-up to the sibling respond_to_booking, leaving no ambiguity.

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

my_connection_requestsPeople waiting to connect with the userA

Read-onlyIdempotent

Inspect

List the connection requests waiting for the signed-in user, and the ones they sent that are still pending. Use it when the user asks who wants to connect, or what is waiting on Foundaree. Offer to answer them with respond_to_connection.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety behavior is covered. The description adds useful scope information about including both received and sent pending requests, but does not disclose response shape, pagination, or any other behavioral details beyond that scoping.

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?

Two sentences with no filler. The core action and object are front-loaded, followed by concrete usage triggers and a pointer to the follow-up tool. Every sentence contributes value.

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 zero-parameter, read-only listing operation with strong annotations and a straightforward purpose, the description is complete. It tells the agent what is listed, when to use it, and how to continue the interaction, leaving no critical gap for correct invocation.

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?

The tool has zero parameters and the schema coverage is trivially complete, so the description has no parameter semantics to add. The baseline for zero-parameter tools is 4, and the description appropriately relies on the implicit signed-in user context rather than introducing parameters.

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 uses a specific verb ('List') and clearly identifies the resource: connection requests for the signed-in user, both incoming and outgoing pending ones. It is distinct from sibling tools like respond_to_connection, which handles acting on requests, and my_bookings, which covers a different domain.

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 explicit triggers: 'when the user asks who wants to connect, or what is waiting on Foundaree.' It also points to the relevant sibling, respond_to_connection, as the next action, providing routing guidance beyond a simple listing.

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

request_appointmentAsk to book a personAInspect

Send a booking request to one person on Foundaree, for the user: "book this plumber for Saturday morning", "ask this dentist for an appointment". Use it only when the user asked to book or contact that person, and only with the user's OWN name and phone number, which they gave you: never guess or reuse another number. Before calling, tell the user what you will send and to whom, and get their yes. The person sees the request on Foundaree and by email, and calls the user back on that number if they can take it; nothing is confirmed until they do, so say that to the user. Find the username with search_people or match_people first. One open request per phone number and person; a few per number a day.

ParametersJSON Schema

Name	Required	Description
`area`	No	Where the work is: the user's area or address hint, e.g. 'Kakkanad, near Infopark'. 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.
`username`	Yes	Username of the person to book, from search_people, match_people or get_person.

Output Schema

ParametersJSON Schema

Name	Required	Description
`sent`	Yes	True when the request was stored for the person.
`person`	No
`message`	Yes	What to tell the user.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already show readOnlyHint=false, but the description adds crucial side-effect details: the request appears on Foundaree and via email, the person calls back if available, and nothing is confirmed until the call happens. It also discloses a rate limit ('One open request per phone number and person; a few per number a day'), which is not in 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 moderately long but every sentence carries essential information: purpose, examples, safety, consent, side effects, rate limit. It is well-structured and front-loaded with the action and examples, no filler.

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 mutating tool with real-world side effects, the description covers the full workflow: lookup prerequisite, user consent, what happens after the request (person sees/calls back), and confirmation semantics. Since an output schema exists, return values are not needed, and the description leaves no critical gap.

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?

The input schema provides 100% parameter descriptions, so the baseline is 3. The description adds useful constraint on 'name' and 'phone' by emphasizing they must be the user's own and never guessed/reused, and it tells how to source 'username' (search_people/match_people), but these are also partially in the schema.

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 action: 'Send a booking request to one person on Foundaree' and provides concrete examples ('book this plumber', 'ask this dentist'). It distinguishes itself from sibling search tools by instructing to use search_people or match_people first, positioning this as the action after discovery.

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?

It gives an explicit trigger condition: 'Use it only when the user asked to book or contact that person' and requires prior lookup ('Find the username with search_people or match_people first'). It also mandates user consent before the call and forbids guessing phone numbers, which is clear when-to-use guidance.

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

respond_to_bookingAccept or decline a booking requestAInspect

Answer one booking request sent to the signed-in user. Get the id from my_bookings first. Always read the request back to the user and get a clear yes before calling this: it is their answer to a real person, not yours. Accepting does not arrange a time — the user still has to call them — so say that.

ParametersJSON Schema

Name	Required	Description	Default
`answer`	Yes	What the user decided.
`bookingId`	Yes	The request id, from my_bookings.

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations, the description reveals that the action represents the user's answer to a real person, carries social weight, and must not be performed without explicit user confirmation. It also discloses that acceptance has no scheduling side effect. These are meaningful behavioral warnings not present in annotations.

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?

Three dense sentences, each earning its place: what the tool does, where the id comes from, and the critical safety caveat. The procedural front-loading makes the important confirmation requirement immediately visible.

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 two-parameter mutation tool with no output schema, the description covers the prerequisite, the required user confirmation, and the post-call limitation about scheduling. An agent has enough context to invoke it correctly and to explain the outcome to the user.

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 baseline is 3. The description adds value by emphasizing that bookingId comes from my_bookings and that 'answer' is the user's decision rather than the agent's judgment, reinforcing the enum with important pragmatic context.

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 uses a specific verb and resource: 'Answer one booking request sent to the signed-in user.' It also makes the accept/decline role clear and distinguishes itself from siblings by scoping to booking requests and pointing to my_bookings for the id.

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?

It gives explicit workflow: get the id from my_bookings first, read the request back to the user, and obtain a clear yes before calling. It also states a key limitation—accepting does not arrange a time—so the agent knows not to treat this tool as an appointment scheduler.

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

respond_to_connectionAccept or decline a connection requestAInspect

Answer one connection request sent to the signed-in user. Get the id from my_connection_requests first. Tell the user who it is and what they wrote, and get their yes before calling this. Declining removes the request quietly; the other person is not told they were declined.

ParametersJSON Schema

Name	Required	Description	Default
`answer`	Yes	What the user decided.
`requestId`	Yes	The request id, from my_connection_requests.

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already mark the tool as non-readonly, open-world, non-idempotent, and non-destructive. The description adds a valuable behavioral disclosure: 'Declining removes the request quietly; the other person is not told they were declined.' This goes beyond the annotations and informs the agent of the side effect. It does not contradict any annotation, so it's a solid 4.

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 tightly packed sentences. The first sentence states the purpose and the second covers prerequisite, user confirmation, and the decline side effect. Every clause earns its place, with no fluff or redundant content.

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 two required parameters, an enum, no output schema, and no nested objects, the description is complete. It covers the prerequisite (get id), the required user confirmation, and the behavioral nuance of declining. Nothing an agent needs to call this correctly is missing. The annotations cover the side-effect profile, and the schema covers the parameters.

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 description coverage is 100%, so the parameters are well-documented. The description adds semantic value by explicitly tying the requestId to 'my_connection_requests', clarifying its source. It also implies that 'answer' should reflect the user's decision from the confirmation step. Even though the schema fully describes the parameters, this extra source hint elevates the score above baseline.

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 opens with a precise verb+resource: 'Answer one connection request sent to the signed-in user.' It clearly distinguishes itself from siblings like my_connection_requests (which lists requests) and respond_to_booking (which handles bookings). The accept/decline action is explicit, leaving no ambiguity about what the tool does.

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 explicit usage guidance: 'Get the id from my_connection_requests first' establishes the prerequisite, and 'Tell the user who it is and what they wrote, and get their yes before calling this' directs the agent to confirm with the user. It also notes that declining removes the request quietly, which sets expectations. No alternatives are named, but the tool is specialized enough that this is sufficient.

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

search_opportunitiesSearch jobs and openingsA

Read-onlyIdempotent

Inspect

Search public openings on Foundaree: jobs, freelance work, internships, projects, co-founder and advisory roles. Use it when the user is looking for work or a role ("React jobs in Bengaluru", "a co-founder role in fintech", "internships in design"), or asks what a company is hiring for. Matches the title, description, city and skills. Only open listings are returned unless includeClosed is true. Returns JSON with items (each: username, title, type, companyUsername, location, description, skills, status, listingUrl, companyUrl) and total. People apply on the listing page on Foundaree; this tool does not apply for anyone. Foundaree is new, so there may be few or none: say so rather than guessing.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of results. Defaults to 10.
`query`	Yes	Role, skill, kind of work or city, e.g. "React developer Bengaluru"
`includeClosed`	No	Also return listings that are closed. Defaults to false.

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the description adds value by specifying the includeClosed filtering behavior and the absence of application side effects. The caution about Foundaree being new and potentially having few results is helpful behavioral context beyond annotations.

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 well-structured and front-loaded: purpose first, then usage, behavior, return format, and side-effect clarification. Every sentence adds unique value, with no filler. It is longer than average but justified given the tool's complexity and the need to convey multiple behaviors.

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?

Complete for a search tool: covers what it searches, how to invoke it, what results look like (items structure and total), the includeClosed option, and the realistic data scarcity. No output schema exists, so describing the return JSON is necessary and done well. Nothing an agent needs to call it correctly is missing.

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 schema documents all parameters. The description adds meaning by explaining what query matches (title, description, city, skills) and clarifies includeClosed behavior, which goes beyond the schema's basic property descriptions. This extra context justifies a score above the baseline 3.

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?

States a specific verb (search) and resource (public openings on Foundaree) and enumerates the role types it covers. It clearly distinguishes from sibling search tools (search_people, search_organizations) by focusing on openings, so an agent can pick it without ambiguity.

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?

Provides explicit triggers ('when the user is looking for work or a role', 'asks what a company is hiring for') with concrete examples. It also states what it does not do (does not apply for anyone) and warns about sparse data, giving clear guidance on when to use and what to expect.

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

search_organizationsSearch companiesA

Read-onlyIdempotent

Inspect

Search public company and organization pages on Foundaree by name, what they do, or city: "design studios in Kochi", "a clinic in Pune", "startups building for farmers". Use it when the user needs a company or team rather than one person. Returns JSON with items (each: username, name, description, website, location, pageUrl) and total. Foundaree is new, so there may be few or none: say so rather than guessing. A company's open roles come from search_opportunities.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of results. Defaults to 10.
`query`	Yes	Name, kind of company, what they do, or a city, e.g. "design studio Kochi"

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior, and the description stays consistent. It adds useful context beyond annotations: Foundaree is new, results may be few or none, and the agent should say so rather than guess. This is genuine behavioral guidance that structured fields do not provide.

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 four sentences with no filler: purpose and examples first, usage guidance, return shape, data-sparsity caveat, and related-tool pointer. Every sentence earns its place and the structure supports quick agent comprehension.

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?

Even without an output schema, the description names the return envelope and item fields, so the agent knows what to expect. It covers what to search, how to frame results, and which sibling tool handles open roles, making it complete for a simple two-parameter search tool.

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

Parameters3/5

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

Schema coverage is 100%, with meaningful descriptions for both the query and limit parameters, including defaults and bounds. The description reinforces query semantics with examples but adds little beyond what the schema already states, so the baseline of 3 is appropriate.

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?

States a clear action: 'Search public company and organization pages on Foundaree' by name, activity, or city, and gives concrete query examples. It also distinguishes itself from person search ('rather than one person') and from open-roles search by pointing to search_opportunities.

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?

Explicitly tells the agent when to use it: when the user needs a company or team rather than a single person. It also routes company open roles to search_opportunities. It does not explicitly name search_people as the alternative for person lookups, but the contrast is clear enough.

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

search_peopleSearch peopleA

Read-onlyIdempotent

Inspect

Search public Foundaree profiles by free-text query and/or structured filters; give at least one. Free-text matches name, headline, bio, location, skills, experiences and projects. Each result carries services (what the person offers with prices), languages, serviceAreas (areas they cover) and workingHours (one entry per day, 24-hour HH:MM) when they gave them, so you can compare before booking. Each result has updatedAt, when the person last edited their profile: prefer recent ones when details matter, and say so when a profile is old. Among equally good matches, recently updated profiles rank a little higher. Structured filters: location (substring), area (neighbourhood substring; also matches the areas a person says they cover), language (a language they work in, e.g. Malayalam), workType (exact: local_service = blue-collar, hands-on work; professional = white-collar work), category (comma-separated trades/professions, OR semantics), availability (exact: available, open_to_offers, not_looking, unspecified), skills (comma-separated, AND semantics), lookingFor (comma-separated, AND semantics). Only the first 100 results can be paged through (offset + limit ≤ 100); add filters to narrow the search. Among people who fit equally well, founding members (Foundaree's first 150 members, foundingMember) come first; a better match always ranks higher. Returns JSON with a results array of structured people summaries. Results never include phone numbers or emails: use get_person for one profile's public contact details. Each answer has two views: the text content is the JSON described above, and the structured content is a profile-card list (people, total, query). In apps that support MCP Apps (ChatGPT, Claude) the cards render as Foundaree profile cards. A person with foundareeRole ("founder" or "team") is part of Foundaree's own team; only Foundaree sets it.

ParametersJSON Schema

Name	Required	Description
`area`	No	Optional neighbourhood filter within the city (case-insensitive substring), e.g. "Kakkanad"
`limit`	No	Maximum number of results. Defaults to 20.
`query`	No	Optional free-text search query, e.g. "postgres engineer" or "technical co-founder"
`offset`	No	Pagination offset. Defaults to 0. Paging stops after the first 100 results.
`skills`	No	Optional comma-separated skills filter (AND semantics), e.g. "AI,ML" or "React,TypeScript"
`category`	No	Optional comma-separated trade/profession filter (OR semantics), e.g. "electrician" or "electrician,carpenter"
`language`	No	Optional language they work in (whole name, any case), e.g. "Malayalam", "Tamil" or "Hindi"
`location`	No	Optional location filter (case-insensitive substring), e.g. "Bangalore" or "San Francisco"
`workType`	No	Optional audience filter: local_service = blue-collar jobs, hands-on work (electricians, carpenters, drivers, cleaners, carers...); professional = white-collar jobs, office and professional work (developers, designers, accountants...)
`lookingFor`	No	Optional comma-separated looking-for filter (AND semantics), e.g. "cofounder" or "job,freelance"
`availability`	No	Optional availability filter (exact match)

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes
`total`	Yes
`people`	Yes

TDQS

A4.5/5.0

Behavior5/5

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), and the description adds substantial behavior beyond them: which fields each result carries, the tie-break rules (recency boosting, founding members first), the 100-result pagination ceiling, and the fact that phone numbers and emails are deliberately withheld. This is exactly the kind of context structured fields cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and filter mechanics are front-loaded and the ordering is logical, but the passage is well over 250 words and includes low-value detail for a caller, such as the MCP Apps card rendering in ChatGPT/Claude and the explanation of foundareeRole membership. Several clauses restate what the input schema already documents at 100% coverage.

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 an 11-parameter, zero-required search tool with an output schema, the description covers everything an agent needs: precondition, filter semantics, ranking and tie-break behavior, result cap, withheld fields, and the follow-up tool for contact data. Nothing material is left to inference.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning: OR vs AND semantics for category/skills/lookingFor, plain-language definitions of workType, and the note that 'area' also matches the areas a person says they cover (which the schema does not state). The parameter guidance therefore exceeds what an agent would get from the schema alone.

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?

Specific verb + resource ('Search public Foundaree profiles') immediately clarified by the two mechanisms (free-text query and structured filters). It explicitly separates itself from the sibling get_person, which is named as the route for contact details, so an agent can distinguish it without opening either 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?

Gives a hard precondition ('give at least one'), advises narrowing with filters when paging hits the 100-result cap, and directs agents to get_person for phone/email. It does not contrast with other search-family siblings such as match_people or search_opportunities, so the alternative-selection guidance is incomplete but the when-to-use context is clear.

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

set_my_availabilitySet whether the user is free for workA

Idempotent

Inspect

Change the signed-in user's availability on their Foundaree profile: available (free for work now), open_to_offers (working, but will listen), or not_looking. This is public and it changes who finds them in search, so confirm with the user before calling it. Useful when they say they have finished a job, are fully booked, or want to be found again.

ParametersJSON Schema

Name	Required	Description	Default
`availability`	Yes	The state to set on the profile.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds important behavioral context: the change is public and affects the user's visibility in search, and it explicitly recommends confirmation before calling. This goes beyond the annotations and helps the agent understand the social impact and consent requirement.

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 concise sentences with no filler. The first sentence states the action and the values, the second explains the impact and provides usage guidance. It is well-structured and front-loads the core purpose.

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 simple tool with one parameter, no output schema, and annotations covering idempotency and non-destructiveness, the description covers all necessary aspects: the action, the allowed values, the public impact, and the confirmation requirement. Nothing essential is missing for an agent to call it correctly.

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

Parameters3/5

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

The input schema has 100% coverage with an enum and a description for the single parameter. The description lists the three enum values in prose, which adds readability but does not provide additional semantic information beyond the schema. Since schema coverage is high, a baseline of 3 is appropriate; the description offers no extra syntax or format details.

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 (change), the resource (the signed-in user's availability on their Foundaree profile), and the three possible states (available, open_to_offers, not_looking). It also explains the consequence (public, affects search visibility), which distinguishes it from sibling tools that operate on bookings, connections, or people. The purpose is unambiguous and specific.

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 provides clear usage context: when the user says they have finished a job, are fully booked, or want to be found again. It also advises confirming with the user before calling, which is a strong operational guideline. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient to guide selection among siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesSep 27, 2026

Changedget_person3 fields changed

addedOutput schema / properties / people / items / properties / backed

Added value: +{
+  "items": {
+    "maxLength": 160,
+    "type": "string"
+  },
+  "maxItems": 12,
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / workProof / properties / github / properties / languageRepos

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "repos": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "repos"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / workProof / properties / github / properties / topics

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "repos": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "repos"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changedmatch_people3 fields changed

addedOutput schema / properties / people / items / properties / backed

Added value: +{
+  "items": {
+    "maxLength": 160,
+    "type": "string"
+  },
+  "maxItems": 12,
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / workProof / properties / github / properties / languageRepos

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "repos": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "repos"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / workProof / properties / github / properties / topics

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "repos": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "repos"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changedsearch_people3 fields changed

addedOutput schema / properties / people / items / properties / backed

Added value: +{
+  "items": {
+    "maxLength": 160,
+    "type": "string"
+  },
+  "maxItems": 12,
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / workProof / properties / github / properties / languageRepos

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "repos": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "repos"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / workProof / properties / github / properties / topics

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "type": "string"
+      },
+      "repos": {
+        "maximum": 9007199254740991,
+        "minimum": 0,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "repos"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

3 tool updatesSep 27, 2026
- Changedget_person1 field changed
  - addedOutput schema / properties / people / items / properties / updatedAt
```
Added value: +{
+  "type": "string"
+}
```
- Changedmatch_people1 field changed
  - addedOutput schema / properties / people / items / properties / updatedAt
```
Added value: +{
+  "type": "string"
+}
```
- Changedsearch_people1 field changed
  - addedOutput schema / properties / people / items / properties / updatedAt
```
Added value: +{
+  "type": "string"
+}
```

4 tool updatesSep 25, 2026

Changedfind_and_ask1 field changed

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"
+}

Changedget_person2 fields changed

addedOutput schema / properties / people / items / properties / languages

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / serviceAreas

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

Changedmatch_people2 fields changed

addedOutput schema / properties / people / items / properties / languages

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / serviceAreas

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

Changedsearch_people3 fields changed

addedInput schema / properties / language

Added value: +{
+  "description": "Optional language they work in (whole name, any case), e.g. \"Malayalam\", \"Tamil\" or \"Hindi\"",
+  "maxLength": 40,
+  "minLength": 1,
+  "type": "string"
+}

addedOutput schema / properties / people / items / properties / languages

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

addedOutput schema / properties / people / items / properties / serviceAreas

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 5,
+  "type": "array"
+}

3 tool updatesSep 23, 2026
- Changedget_person1 field changed
  - addedOutput schema / properties / people / items / properties / priceLine
```
Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}
```
- Changedmatch_people1 field changed
  - addedOutput schema / properties / people / items / properties / priceLine
```
Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}
```
- Changedsearch_people1 field changed
  - addedOutput schema / properties / people / items / properties / priceLine
```
Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}
```
3 tool updatesSep 22, 2026
- Changedget_person1 field changed
  - changedOutput schema / properties / people / items / properties / verifiedBy / items / enum
```
Previous value: -[
-  "phone",
-  "github",
-  "google"
-]New value: +[
+  "phone",
+  "github",
+  "google",
+  "licence"
+]
```
- Changedmatch_people1 field changed
  - changedOutput schema / properties / people / items / properties / verifiedBy / items / enum
```
Previous value: -[
-  "phone",
-  "github",
-  "google"
-]New value: +[
+  "phone",
+  "github",
+  "google",
+  "licence"
+]
```
- Changedsearch_people1 field changed
  - changedOutput schema / properties / people / items / properties / verifiedBy / items / enum
```
Previous value: -[
-  "phone",
-  "github",
-  "google"
-]New value: +[
+  "phone",
+  "github",
+  "google",
+  "licence"
+]
```
7 tool updatesSep 22, 2026
- Addedcheck_errand
- Addedfind_and_ask
- Addedmy_bookings
- Addedmy_connection_requests
- Addedrespond_to_booking
- Addedrespond_to_connection
- Addedset_my_availability
2 tool updatesSep 21, 2026
- Addedsearch_opportunities
- Addedsearch_organizations
1 tool updateSep 21, 2026
- Addedrequest_appointment
3 tool updatesSep 19, 2026
- Changedget_person1 field changed
  - addedOutput schema / properties / people / items / properties / foundareeRole
```
Added value: +{
+  "enum": [
+    "founder",
+    "team"
+  ],
+  "type": "string"
+}
```
- Changedmatch_people1 field changed
  - addedOutput schema / properties / people / items / properties / foundareeRole
```
Added value: +{
+  "enum": [
+    "founder",
+    "team"
+  ],
+  "type": "string"
+}
```
- Changedsearch_people1 field changed
  - addedOutput schema / properties / people / items / properties / foundareeRole
```
Added value: +{
+  "enum": [
+    "founder",
+    "team"
+  ],
+  "type": "string"
+}
```

3 tool updatesSep 19, 2026

Changedget_person1 field changed

addedOutput schema / properties / people / items / properties / workProof

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "github": {
+      "additionalProperties": false,
+      "properties": {
+        "fetchedAt": {
+          "type": "string"
+        },
+        "followers": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "languages": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "lastPushAt": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "login": {
+          "type": "string"
+        },
+        "publicRepos": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "stars": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "login",
+        "url",
+        "publicRepos",
+        "followers",
+        "stars",
+        "languages",
+        "lastPushAt",
+        "fetchedAt"
+      ],
+      "type": "object"
+    },
+    "proven": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "total": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "website": {
+      "additionalProperties": false,
+      "properties": {
+        "host": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "verifiedAt": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "url",
+        "host",
+        "verifiedAt"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "proven",
+    "total"
+  ],
+  "type": "object"
+}

Changedmatch_people1 field changed

addedOutput schema / properties / people / items / properties / workProof

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "github": {
+      "additionalProperties": false,
+      "properties": {
+        "fetchedAt": {
+          "type": "string"
+        },
+        "followers": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "languages": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "lastPushAt": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "login": {
+          "type": "string"
+        },
+        "publicRepos": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "stars": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "login",
+        "url",
+        "publicRepos",
+        "followers",
+        "stars",
+        "languages",
+        "lastPushAt",
+        "fetchedAt"
+      ],
+      "type": "object"
+    },
+    "proven": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "total": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "website": {
+      "additionalProperties": false,
+      "properties": {
+        "host": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "verifiedAt": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "url",
+        "host",
+        "verifiedAt"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "proven",
+    "total"
+  ],
+  "type": "object"
+}

Changedsearch_people1 field changed

addedOutput schema / properties / people / items / properties / workProof

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "github": {
+      "additionalProperties": false,
+      "properties": {
+        "fetchedAt": {
+          "type": "string"
+        },
+        "followers": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "languages": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "lastPushAt": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "login": {
+          "type": "string"
+        },
+        "publicRepos": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "stars": {
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "url": {
+          "format": "uri",
+          "type": "string"
+        }
+      },
+      "required": [
+        "login",
+        "url",
+        "publicRepos",
+        "followers",
+        "stars",
+        "languages",
+        "lastPushAt",
+        "fetchedAt"
+      ],
+      "type": "object"
+    },
+    "proven": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "total": {
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "website": {
+      "additionalProperties": false,
+      "properties": {
+        "host": {
+          "type": "string"
+        },
+        "url": {
+          "type": "string"
+        },
+        "verifiedAt": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "url",
+        "host",
+        "verifiedAt"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "proven",
+    "total"
+  ],
+  "type": "object"
+}

3 tool updatesSep 19, 2026
- Changedget_person1 field changed
  - addedOutput schema / properties / people / items / properties / email
```
Added value: +{
+  "type": "string"
+}
```
- Changedmatch_people1 field changed
  - addedOutput schema / properties / people / items / properties / email
```
Added value: +{
+  "type": "string"
+}
```
- Changedsearch_people1 field changed
  - addedOutput schema / properties / people / items / properties / email
```
Added value: +{
+  "type": "string"
+}
```
4 tool updatesSep 19, 2026
- First observedcreate_profile_draft
- First observedget_person
- First observedmatch_people
- First observedsearch_people

Related MCP Connectors

Kirah Local Services A
io.github.kirubel
Discover local services and availability, then create, track, reschedule, or cancel bookings.
Calendar Management App Automation
101
AgentBookable A
com.agentbookable
Find local services, check live availability, and book real appointments with consent.
Location Services Calendar Management App Automation
91
Awning A
help.awning
Find and book local services, classes and rentals; businesses set up and manage their pages.
E-commerce & Retail Search Location Services
361
slotrobin A
io.github.KyleClouthier
Find, get quotes from and book local service businesses on their own Square or Google calendar.
Calendar Management Location Services App Automation
81

Related MCP Servers

Ceki
Autonomous Agents Browser Automation Workplace & Productivity
Ceki-me
A
license
B
quality
B
maintenance
Hire specialists by the hour — search, schedule, and pay via MCP protocol.
Updated 7 days ago (2026-10-06 14:43 UTC)
35
2
MIT
Servicialo
Autonomous Agents App Automation Project Management
servicialo
A
license
A
quality
C
maintenance
Open protocol for AI-agent coordination of professional services. Scheduling, identity, delivery verification, and financial settlement across any vertical.
Updated 6 days ago (2026-10-08 10:05 UTC)
10
71 npm
1
Apache 2.0
A³ MCP Server
Calendar Management Customer Support Speech Processing
RemiEtien
A
license
Not graded
quality
B
maintenance
Enables voice assistants to find nearby service providers, connect users to live video representatives for natural conversation, and handle appointment booking. It also returns confirmed bookings so the assistant can add them to its calendar.
Updated 11 days ago (2026-10-02 13:55 UTC)
MIT
AI List My Business
Location Services Real Estate Search
mutamiri-sudo
A
license
A
quality
B
maintenance
Country-agnostic MCP-callable directory for AI agents to find local SMBs — realtors, insurance agents, medical practitioners — by category, location, or natural-language query. Returns business catalog data and UTM-tagged booking URLs (zero PII).
Updated 4 months ago (2026-06-12 02:55 UTC)
5
MIT

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?