Skip to main content
Glama

findTeam

Team members / people (Person profiles). Each member has a public author page at /<locale>/team/<slug> (slug is localized, auto-generated from name); there is deliberately NO /team index page. name is required (language-neutral); role/department/bio/quote/qualifications/knowsAbout are localized. socialLinks, languages and knowsAbout are one-per-line textareas (→ Person sameAs / knowsLanguage / knowsAbout). photo is an upload. Manual order via order (used by the team block, not by the route). Linked to the site Organization (worksFor) in JSON-LD; referenced as a post author — use the find tool to list members with their id (needed for a post's teamAuthor + getPersona(<id>)), which makes every such post point its author at this person's profile node. style (the writing voice) is REDACTED in find responses — read the real value via getPersona(<id>). team collection. Drafts: yes (publish workflow; a find WITHOUT draft:true returns the published main-table state only). Public read: yes via /api/agents. MCP capabilities: find, create, update, delete. ⚠ delete is PERMANENT (hard-delete; the admin Trash does NOT catch MCP deletes). Before writing public text here, call getWritingGuidelines with this collection and the locale (brand voice, writing rules, fixed terms, SEO rules, taken keywords, field rules). Fields: name (required), slug (localized), role (localized), bio (richText, localized), quote (textarea, localized), photo (upload: media|brand), order (number), kind (enum: member (Team member (shown + author))|display (Display only (shown, not author))|author (Author only / guest (not shown)), required), department (localized), email, phone, socialLinks (textarea), qualifications (textarea, localized), languages (textarea), knowsAbout (textarea, localized), style (textarea, localized, redacted), publishedAt (date), robots (enum: index (Index (default))|noindex (noindex (hide))), searchText (textarea, localized, ≤60000 chars, redacted), meta (group: title, description, focusKeyword, secondaryKeyword1-4, searchIntent, eeatInsight, image — localized).

Input Schema

NameRequiredDescriptionDefault
idNoOptional: specific document ID to retrieve. If not provided, returns all documents
pageNoPage number for pagination (default: 1)
sortNoField to sort by (e.g., "createdAt", "-updatedAt" for descending)
depthNoHow many levels deep to populate relationships (default: 0)
draftNoOptional: Whether the document should be queried from the versions table/collection or not.
limitNoMaximum number of documents to return (default: 10, max: 100)
whereNoOptional JSON string for where clause filtering (e.g., '{"title": {"contains": "test"}}')
localeNoOptional: locale code to retrieve data in (e.g., "en", "es"). Use "all" to retrieve all locales for localized fields
selectNoOptional: define exactly which fields you'd like to return in the response (JSON), e.g., '{"title": true}'
fallbackLocaleNoOptional: fallback locale code to use when requested locale is not available

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden, and it does disclose genuinely non-obvious behavior: `style` and `searchText` are redacted in find responses, draft:true switches to the versions table, and public reads are exposed via /api/agents. But it spends substantial space on a hard-delete warning and create/update/delete capabilities that findTeam does not expose, and never describes pagination or response shape.

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 text is a content-model dump rather than a tool description: field lists, URL routing rules, JSON-LD wiring, and SEO/meta groupings crowd out the actual operation. The most important operational facts (redaction, draft behavior) are buried mid-paragraph rather than front-loaded.

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

Completeness3/5

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

It is rich on collection semantics—localization, redaction, draft state, author linkage—which compensates for the absence of annotations. With 10 parameters and no output schema, though, it never explains what a findTeam response looks like, how populated relationships (depth) appear, or pagination totals, leaving operational gaps.

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%, so the baseline is 3. The description adds real meaning for `draft` (versions vs. published main table) and `locale` (localized field resolution), but says nothing about `depth` relationship population, `where` filtering, or `sort` usage beyond what the schema already documents.

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

Purpose3/5

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

The opening 'Team members / people (Person profiles)' identifies the resource but never states the operation this tool performs; the only verb-adjacent instruction—'use the `find` tool to list members with their `id`'—points at a sibling rather than describing findTeam. It also advertises 'MCP capabilities: find, create, update, delete', which overstates the scope of a read-only retrieval tool and muddies what findTeam actually does.

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

Usage Guidelines3/5

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

Useful conditional guidance exists: draft:true is needed to see versioned state, and `style` must be read via getPersona(<id>) because it is redacted here. However there is no guidance on when to choose findTeam over findPosts/findPages/findTags, and the 'call getWritingGuidelines before writing public text' instruction is irrelevant to a read operation.

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