btlabs Core

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

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Optional: specific document ID to retrieve. If not provided, returns all documents
`page`	No	Page number for pagination (default: 1)
`sort`	No	Field to sort by (e.g., "createdAt", "-updatedAt" for descending)
`depth`	No	How many levels deep to populate relationships (default: 0)
`draft`	No	Optional: Whether the document should be queried from the versions table/collection or not.
`limit`	No	Maximum number of documents to return (default: 10, max: 100)
`where`	No	Optional JSON string for where clause filtering (e.g., '{"title": {"contains": "test"}}')
`locale`	No	Optional: locale code to retrieve data in (e.g., "en", "es"). Use "all" to retrieve all locales for localized fields
`select`	No	Optional: define exactly which fields you'd like to return in the response (JSON), e.g., '{"title": true}'
`fallbackLocale`	No	Optional: fallback locale code to use when requested locale is not available

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 21, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers: drafts not returned without draft:true, style being redacted in find responses, public read via /api/agents, permanent deletion for the delete operation, and the fact that order is used by the team block. These are critical behavioral traits that an agent needs to know.

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?

The description is very long and dense, covering extensive field details and behaviors. While comprehensive, it could be better structured and more concise. The core purpose is front-loaded, but the volume of information may overwhelm an agent. It earns a 3 because it's thorough but not well-organized for quick consumption.

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 find tool with no output schema, the description provides all necessary context: entity definition, field types, localization, required fields, redaction, draft behavior, public read access, capabilities, and cross-references to posts and getPersona. An agent has everything needed to correctly use the find tool and interpret results.

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 all parameters are already described in the input schema. The description adds minimal parameter-specific meaning beyond what's in the schema; it only touches on draft:true behavior and the redaction of style in responses, which are response-level details rather than parameter semantics. Baseline 3 is appropriate.

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?

The description clearly identifies the resource as 'Team members / people (Person profiles)' and explains its purpose as a collection that can be listed via the find tool. It distinguishes the entity from siblings by describing its specific fields and behaviors (e.g., no /team index page, linking to posts). However, it doesn't explicitly state that the tool's function is to retrieve team members, but that's implied.

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?

Provides clear usage guidance: use the find tool to list members with their id (needed for post's teamAuthor), and mentions that draft:true is required to see drafts. It also notes that style is redacted and to use getPersona for the real value. While it doesn't compare against sibling find tools, each collection is distinct, so usage is reasonably clear.

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

All btlabs Core 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?