Foundaree

Put the user on Foundaree

create_profile_draft

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.

Input Schema

TableJSON 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

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 19, 2026

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.

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?