Skip to main content
Glama
jhl8041

Dooray MCP Server

by jhl8041
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get-project-member-list

Read-onlyIdempotent

Retrieve a Dooray project's member list with names and email addresses, optionally filter by admin or member roles, and paginate results for task assignment or team review.

Instructions

Get list of members in a project with their details.

This tool fetches project members and enriches each member with detailed information including name and email address.

URL Pattern Recognition: When given a Dooray URL like "https://nhnent.dooray.com/task/PROJECT_ID", extract the PROJECT_ID (the first numeric ID after "/task/") and use it as the projectId parameter.

Role Filtering:

  • Optionally filter by roles: ["admin"], ["member"], or ["admin", "member"]

  • If not specified, returns all members regardless of role

Pagination:

  • Default page size is 20 (maximum: 100)

  • Use page parameter to get additional pages if totalCount > size

Note: Returns compact response with essential fields only (id, name, externalEmailAddress).

Examples:

  • Get all members: {"projectId": "123456"}

  • Get only admins: {"projectId": "123456", "roles": ["admin"]}

  • Get with pagination: {"projectId": "123456", "page": 0, "size": 50}

Returns a paginated response with totalCount and array of members containing:

  • id: Member ID (organizationMemberId)

  • name: Member's display name

  • externalEmailAddress: Member's email address

Use this tool to find project members for assigning tasks or understanding team composition.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for pagination (default: 0)
sizeNoNumber of items per page (default: 20, max: 100)
rolesNoFilter by roles (optional)
projectIdYesProject ID to get members from

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and openWorld, so safety is covered; the description adds real behavioral context beyond that — optional role filtering semantics, default page size 20 with a hard max of 100, and a deliberately compact response shape. It doesn't say what happens on invalid projectId or whether members are deduplicated.

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, then clearly headed sections for URL recognition, role filtering, pagination and return shape, with examples at the end. Slightly redundant: the 'compact response' note and the 'Returns a paginated response' list restate the same field set twice.

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?

No output schema exists, yet the description documents the returned fields (id, name, externalEmailAddress) and that the payload is paginated with totalCount. Combined with the paging and filtering guidance, an agent has everything needed to call it and interpret the result.

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, but the description earns above that by explaining the non-obvious projectId derivation rule from a Dooray task URL and by spelling out role filter combinations and pagination limits in prose. This meaning is not present in the schema's terse parameter descriptions.

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?

States a specific verb and resource: 'Get list of members in a project with their details', plus an enrichment note (name, email). It never distinguishes itself from the closely-named siblings get-member-list, get-member, get-my-member-info, or get-project-member-group-list, so an agent must infer the project-scoped difference.

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 concrete use case ('find project members for assigning tasks or understanding team composition') and three worked examples covering the main invocation variants. It stops short of explicit when-not-to-use guidance or naming the sibling to use for org-wide member lookups.

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

Deploy Server

Other Tools