Skip to main content
Glama

Foundaree

Search people

search_people
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNoOptional neighbourhood filter within the city (case-insensitive substring), e.g. "Kakkanad"
limitNoMaximum number of results. Defaults to 20.
queryNoOptional free-text search query, e.g. "postgres engineer" or "technical co-founder"
offsetNoPagination offset. Defaults to 0. Paging stops after the first 100 results.
skillsNoOptional comma-separated skills filter (AND semantics), e.g. "AI,ML" or "React,TypeScript"
categoryNoOptional comma-separated trade/profession filter (OR semantics), e.g. "electrician" or "electrician,carpenter"
languageNoOptional language they work in (whole name, any case), e.g. "Malayalam", "Tamil" or "Hindi"
locationNoOptional location filter (case-insensitive substring), e.g. "Bangalore" or "San Francisco"
workTypeNoOptional 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...)
lookingForNoOptional comma-separated looking-for filter (AND semantics), e.g. "cofounder" or "job,freelance"
availabilityNoOptional availability filter (exact match)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYes
totalYes
peopleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema 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"
      +}
  2. Changed1 schema field changed
    • addedOutput schema / properties / people / items / properties / updatedAt
      Added value: +{
      +  "type": "string"
      +}
  3. Changed3 schema 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"
      +}
  4. Changed1 schema field changed
    • addedOutput schema / properties / people / items / properties / priceLine
      Added value: +{
      +  "maxLength": 200,
      +  "type": "string"
      +}
  5. Changed1 schema field changed
    • changedOutput schema / properties / people / items / properties / verifiedBy / items / enum
      Previous value: -[
      -  "phone",
      -  "github",
      -  "google"
      -]New value: +[
      +  "phone",
      +  "github",
      +  "google",
      +  "licence"
      +]
  6. Changed1 schema field changed
    • addedOutput schema / properties / people / items / properties / foundareeRole
      Added value: +{
      +  "enum": [
      +    "founder",
      +    "team"
      +  ],
      +  "type": "string"
      +}
  7. Changed1 schema 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"
      +}
  8. Changed1 schema field changed
    • addedOutput schema / properties / people / items / properties / email
      Added value: +{
      +  "type": "string"
      +}
  9. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources