{
  "mcpServers": {
    "teamretro-mcp-server": {
      "command": "npx",
      "args": ["-y", "teamretro-mcp-server"],
      "env": {
        "TEAMRETRO_AUTH_TYPE": "apiKey",
        "TEAMRETRO_API_KEY": "your-api-key"
      }
    }
  }
}

ソースコードから

リポジトリをクローンし、依存関係をインストールして、プロジェクトをビルドします。

git clone https://github.com/adepanges/teamretro-mcp-server.git
cd teamretro-mcp-server
npm install
npm run build

AIクライアントで実行

AI クライアントを次の設定で構成します。

{
  "mcpServers": {
    "teamretro-mcp-server": {
      "command": "node",
      "args": ["/path/to/teamretro-mcp-server/dist/index.js"],
      "env": {
        "TEAMRETRO_AUTH_TYPE": "apiKey",
        "TEAMRETRO_API_KEY": "your-api-key"
      }
    }
  }
}

Inspectorで実行する

.env.exampleを.envにコピーし、必要に応じて変更して環境変数を設定します。
インスペクターでサーバーを実行します:

npm run inspector

環境変数の例

ベースURL

TeamRetro APIのベースURLは、 TEAMRETRO_BASE_URL環境変数を使用して設定できます。デフォルトでは、 https://api.teamretro.comに設定されています。

{
  "env": {
    "TEAMRETRO_BASE_URL": "https://api.teamretro.com"
  }
}

APIキー認証

{
  "env": {
    "TEAMRETRO_AUTH_TYPE": "apiKey",
    "TEAMRETRO_API_KEY": "your-api-key"
  }
}

利用可能なツール

サーバーは次のツールを提供します。

ユーザー

list_users : オフセットと制限パラメータを使用してページ区切りでユーザーをリストし、返される結果の数を制御します。
add_user : オプションの name と emailAddress を指定して、新しいユーザーを追加するか、既存のユーザーの情報をメールアドレスで更新します。
update_user : 現在のメールアドレスを入力して、既存のユーザーの詳細（名前やメールアドレスなど）を更新します。
delete_user : メールアドレスでユーザーを削除する
get_user : メールアドレスから特定のユーザーの詳細情報を取得します。

チーム

list_teams : タグとIDでフィルタリングし、オフセットと制限パラメータを使用してページ区切りでTeamRetroからチームをリストします。
detail_team : 一意のIDで単一のチームの詳細情報を取得します。
update_team : チームのIDを指定して、名前や関連タグなどの既存のチームの詳細を更新します。
create_team : 必須の名前、オプションのタグとメンバーで新しいチームを作成します。
delete_team : ID で既存のチームを削除する

チームメンバー

list_team_members : オフセットと制限のページ区切り制御を使用して、指定されたチームIDのチームメンバーのリストを取得します。
get_team_member : 指定されたチーム内のメールアドレスでチームメンバーを取得します
update_team_member : 指定されたチーム内のメールアドレスで、チームメンバーの詳細（名前やチーム管理者ステータスなど）を更新します。
remove_team_member : メールアドレスでチームメンバーをチームから削除する
add_team_member : チーム管理者ステータスのオプション指定を使用して、メールアドレスで新しいチームメンバーをチームに追加します。

アクション

list_actions : チームタグとチームIDによるフィルタリング、オフセットと制限のページネーション制御など、TeamRetroからアクションのリストを取得します。
create_action : チームID、タイトル、期日、完了ステータス、割り当てられたユーザーなどの必要な詳細を使用して、TeamRetroで新しいアクションを作成します。
get_action : TeamRetroから一意のIDで単一のアクションを取得します。
update_action : TeamRetro の既存のアクションを、タイトル、期日、完了ステータス、優先度、割り当てられたユーザーなどの新しい詳細で更新します。
delete_action : アクションIDでTeamRetroから既存のアクションを削除します。

合意

list_agreements : チームタグとチームIDによるフィルタリングやページ区切りのコントロールなど、TeamRetroからの契約を一覧表示します。
create_agreement : 所属するチームとタイトルを指定して、TeamRetro で新しい契約を作成します。
get_agreement : 一意の識別子で単一の契約を取得する
update_agreement : タイトルや関連チームなどの既存の契約の詳細を更新します
delete_agreement : 一意の識別子を指定して既存の契約を削除します

健康診断

list_health_checks : TeamRetro からのヘルスチェックを一覧表示します。ヘルスモデル ID、チームタグ、チーム ID、ページ区切りコントロールによるフィルタリングもオプションで可能です。
get_health_check : 一意の識別子とオプションの属性で単一のヘルスチェックを取得します。
delete_health_check : 一意の識別子を指定して既存のヘルスチェックを削除します。

健康モデル

list_health_models : ページネーションコントロール付きのTeamRetroからの健康モデルの一覧
get_health_model : 一意の識別子で単一のヘルスモデルを取得します。

回顧展

list_retrospectives : チームタグとIDでフィルタリングし、オフセットと制限パラメータを使用してページ区切りでTeamRetroからのレトロスペクティブを一覧表示します。
get_retrospective : 一意のIDで単一の回顧展の詳細情報を取得します。
delete_retrospective : ID で既存のレトロスペクティブを削除する

変更履歴

変更と更新の詳細なリストについては、 CHANGELOG.md を参照してください。

Available Tools

11 tools

add_userC

Add or update a user by email

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes
`name`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this requires admin permissions, if it's idempotent, what happens on conflicts, or the response format. For a mutation tool with zero annotation coverage, this is inadequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error cases, return values, and differentiation from siblings, making it insufficient for reliable agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds minimal parameter context. It mentions 'by email' which hints at the 'email' parameter but doesn't explain the 'name' parameter or their semantics (e.g., is name optional for updates?). This leaves significant gaps in parameter understanding.

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 states the action ('Add or update') and target resource ('a user by email'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_user' (which doesn't exist) or 'update_user' (which does exist), missing explicit sibling distinction.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'update_user' or 'delete_user'. The description implies it can handle both addition and update, but doesn't specify scenarios or prerequisites for choosing it over other user management tools.

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

create_teamC

Create a new team with optional members and tags

ParametersJSON Schema

Name	Required	Description
`members`	No	{ email: string, name?: string, teamAdmin?: boolean }[]
`name`	Yes	string
`tags`	No	string[]

TDQS

C2.9/5.0

Behavior2/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. It states the tool creates a team but doesn't disclose behavioral traits like required permissions, whether it's idempotent, what happens on duplicate team names, rate limits, or what the return value contains. For a creation tool with zero annotation coverage, this is a significant gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose ('Create a new team') and adds only necessary qualifiers ('with optional members and tags'). Every word earns its place.

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

Completeness2/5

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

Given the complexity (a creation tool with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, idempotency, or error handling, and doesn't explain what the tool returns. For a tool that creates resources, this leaves critical gaps for an agent.

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 description coverage is 100%, so the schema already documents all parameters (name, members, tags) with their types, constraints, and descriptions. The description adds minimal value by noting that members and tags are optional, but this is already implied by the schema (only 'name' is required). Baseline 3 is appropriate when the schema does the heavy lifting.

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 states the action ('Create') and resource ('a new team'), and mentions optional features ('with optional members and tags'). It doesn't explicitly differentiate from siblings like 'add_user' or 'update_team', but the verb 'Create' is specific enough to indicate this is for initial team creation rather than modification.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With siblings like 'add_user' (for adding members to existing teams), 'update_team' (for modifying teams), and 'list_teams' (for viewing), the description doesn't help an agent choose between these tools or indicate prerequisites (e.g., whether you need admin permissions).

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

delete_teamC

Delete an existing team

ParametersJSON Schema

Name	Required	Description	Default
`teamId`	Yes	string

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states 'delete' but doesn't disclose if this is permanent, reversible, requires admin permissions, affects associated data (e.g., members, projects), or has side effects. For a destructive tool with zero annotation coverage, this is a significant gap in behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.

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

Completeness2/5

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

For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context such as irreversible consequences, permission requirements, error conditions, or return values. Given the complexity and risk of deletion, more behavioral and usage details are needed.

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 description coverage is 100%, with the parameter 'teamId' documented in the schema (including pattern and type). The description adds no parameter-specific information beyond implying a team identifier is needed. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 'Delete an existing team' clearly states the action (delete) and target resource (team). It distinguishes from siblings like 'create_team' or 'update_team' by specifying deletion. However, it lacks specificity about what 'delete' entails (e.g., permanent removal vs archiving).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., team must be empty), exclusions (e.g., cannot delete default teams), or related tools like 'detail_team' for verification. The description alone offers no usage context.

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

delete_userC

Delete a user by email

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	string

TDQS

C2.9/5.0

Behavior2/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 of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are needed, or what happens to associated data. This leaves significant gaps in understanding the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. Every word contributes to understanding the tool's basic function efficiently.

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

Completeness2/5

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

Given that this is a destructive tool with no annotations and no output schema, the description is insufficiently complete. It lacks critical details like confirmation requirements, error handling, or return values, leaving the agent with incomplete context for safe and effective use.

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?

The input schema has 100% description coverage, with the 'email' parameter fully documented in the schema itself. The description adds no additional semantic information beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.

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 states the action ('Delete') and the resource ('a user by email'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'delete_team' or 'update_user' beyond the obvious resource difference, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'update_user' or 'get_user', nor does it mention prerequisites such as user existence or permissions required. It simply states what the tool does without contextual usage information.

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

detail_teamB

Get a single team by ID

ParametersJSON Schema

Name	Required	Description	Default
`teamId`	Yes	string

TDQS

B3.1/5.0

Behavior2/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 of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read operation, but doesn't mention whether it requires authentication, has rate limits, returns error conditions, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that states the core purpose without any fluff. It's front-loaded with the essential information ('Get a single team by ID'), making it immediately clear. Every word earns its place, with no wasted verbiage.

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?

Given the simple single-parameter input schema with full coverage and no output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral details like authentication needs, error handling, or output format. For a read operation with no annotations, it should ideally provide more context about what 'Get' entails beyond just the action.

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 description coverage is 100%, with the single parameter 'teamId' fully documented in the schema including its type, pattern, and requirement. The description adds no additional parameter information beyond what's in the schema, such as explaining what a team ID represents or where to find it. Baseline 3 is appropriate when the schema does all the work.

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 states the action ('Get') and resource ('a single team by ID'), making the purpose immediately understandable. It distinguishes this from list_teams by specifying retrieval of a single team rather than multiple teams. However, it doesn't explicitly contrast with other sibling tools like get_user or list_team_members, keeping it from a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use detail_team versus list_teams, get_user, or list_team_members, nor does it specify prerequisites like needing a team ID. Without any usage context, the agent must infer when this tool is appropriate.

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

get_userC

Get a single user by email

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	string

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: whether it's a read-only operation, what happens if the user doesn't exist (error handling), response format, or any rate limits. The description is minimal and lacks operational context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with a single sentence that directly states the tool's purpose. Every word serves a functional purpose with zero redundancy or unnecessary elaboration, making it perfectly front-loaded and efficient.

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

Completeness2/5

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

For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned about the user, how errors are handled, or any operational constraints. Given the lack of structured metadata, the description should provide more context about the tool's behavior and expected outcomes.

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?

The description mentions the single parameter ('by email') which aligns with the schema's 100% coverage. However, it doesn't add meaningful semantic context beyond what the schema already provides through the email format validation. No additional guidance is given about email format requirements or edge cases.

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 states the action ('Get') and resource ('a single user') with the specific lookup method ('by email'), which distinguishes it from sibling tools like 'list_users' or 'detail_team'. However, it doesn't explicitly differentiate from similar tools like 'update_user' or 'delete_user' that also operate on users.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get_user' over 'list_users' for retrieving user information, nor does it specify prerequisites like authentication requirements or access permissions.

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

list_team_membersC

List team members with pagination

ParametersJSON Schema

Name	Required	Description
`limit`	No	number
`offset`	No	number
`teamId`	Yes	string

TDQS

C2.9/5.0

Behavior2/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 mentions pagination, which is useful context, but fails to describe other critical behaviors such as whether this is a read-only operation (implied by 'List' but not stated), what permissions are required, rate limits, or the format of returned data. For a tool with no annotation coverage, this leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste—'List team members with pagination'—front-loading the core action and key feature. Every word earns its place, making it highly concise and well-structured for quick comprehension.

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

Completeness2/5

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

Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, output format, error handling, and usage context relative to siblings. While concise, it doesn't provide enough information for an agent to fully understand how to invoke and interpret results, especially with no output schema to compensate.

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 description coverage is 100%, so the schema already documents all three parameters (teamId, limit, offset) with descriptions like 'number' and 'string'. The description adds no additional meaning beyond implying pagination through 'limit' and 'offset', but doesn't clarify parameter interactions or usage details. Baseline 3 is appropriate as the schema does the heavy lifting.

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 states the verb ('List') and resource ('team members'), making the purpose immediately understandable. It distinguishes from siblings like 'list_users' by specifying team members rather than all users, though it doesn't explicitly contrast with 'detail_team' which might provide team details rather than member listings.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'list_users' or 'detail_team'. It mentions pagination, which hints at usage for large datasets, but lacks explicit when/when-not instructions or named alternatives, leaving the agent to infer context from sibling tool names alone.

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

list_teamsB

List teams from TeamRetro with filtering and pagination

ParametersJSON Schema

Name	Required	Description
`limit`	No	number
`offset`	No	number
`teamIds`	No	string,string,...
`teamTags`	No	string,string,...

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'filtering and pagination' which hints at capabilities, but fails to describe critical behaviors: whether this is a read-only operation, what authentication is required, rate limits, error conditions, or the structure of returned data. For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how the tool behaves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose ('List teams from TeamRetro') followed by key capabilities ('with filtering and pagination'). Every word serves a purpose with zero redundancy or unnecessary elaboration, making it optimally concise for its informational content.

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

Completeness2/5

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

Given the tool has 4 parameters, no annotations, and no output schema, the description is insufficiently complete. While concise, it fails to address critical context: what authentication is needed, whether this is a safe read operation, what the return format looks like, or how filtering parameters interact. For a list tool with filtering capabilities, users need more guidance on expected behavior and 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 description coverage is 100%, so the schema already documents all parameters (limit, offset, teamIds, teamTags) with their types, constraints, and defaults. The description adds marginal value by mentioning 'filtering and pagination' which aligns with teamIds/teamTags and limit/offset parameters respectively, but provides no additional semantic context beyond what the schema already specifies.

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 states the verb ('List') and resource ('teams from TeamRetro'), making the purpose immediately understandable. It distinguishes from siblings like 'detail_team' (which shows details of a specific team) and 'create_team' (which creates new teams). However, it doesn't explicitly differentiate from 'list_team_members' (which lists members within teams), leaving some ambiguity.

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?

The description implies usage context by mentioning 'filtering and pagination', suggesting this tool is for retrieving multiple teams with optional constraints. However, it provides no explicit guidance on when to use this versus alternatives like 'detail_team' for single teams or 'list_team_members' for team composition. The context is implied but not clearly articulated.

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

list_usersC

List users with pagination

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	number
`offset`	No	number

TDQS

C2.9/5.0

Behavior2/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 mentions 'pagination' which hints at a read-only, list operation, but doesn't specify whether this requires authentication, rate limits, or what the output format looks like (e.g., array of user objects). For a tool with zero annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose ('List users') and adds only essential context ('with pagination'). Every word earns its place, making it highly concise and well-structured.

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

Completeness2/5

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

Given the tool's complexity (a list operation with pagination), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., user objects, total count), authentication needs, or error conditions. For a tool with no structured behavioral data, more context is needed.

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 description coverage is 100%, so the schema fully documents the 'limit' and 'offset' parameters with defaults and constraints. The description adds no additional meaning beyond implying pagination, which is already clear from the parameter names. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states the verb ('List') and resource ('users'), making the purpose immediately understandable. It distinguishes from siblings like 'get_user' (singular) and 'add_user' (creation). However, it doesn't specify what kind of listing this is (e.g., all users, filtered users) beyond pagination.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get_user' (for single user details) or 'list_team_members' (for users within a team). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.

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

update_teamC

Update an existing team

ParametersJSON Schema

Name	Required	Description
`name`	Yes	string
`tags`	No	string[]
`teamId`	Yes	string

TDQS

C2.9/5.0

Behavior2/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 states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, auth needs), response format, and usage context, leaving significant gaps for an agent to operate safely and effectively.

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 description coverage is 100%, so the schema fully documents the three parameters (teamId, name, tags) with descriptions and constraints. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high coverage.

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 'Update an existing team' clearly states the verb (update) and resource (team), distinguishing it from siblings like create_team or delete_team. However, it doesn't specify what aspects of the team can be updated (e.g., name, tags), which would make it more specific.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like create_team or update_user. It doesn't mention prerequisites (e.g., needing an existing teamId) or exclusions, leaving the agent to infer usage from the tool name alone.

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

update_userC

Update an existing user's information

ParametersJSON Schema

Name	Required	Description
`email`	Yes	string
`emailAddress`	Yes	string
`name`	Yes	string

TDQS

C2.9/5.0

Behavior2/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 states this is an update operation (implying mutation), but doesn't disclose any behavioral traits such as required permissions, whether changes are reversible, error conditions, or what happens to unspecified fields. This is a significant gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a straightforward update operation and is perfectly front-loaded with the essential information.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens during the update (e.g., partial updates, validation), what the response contains, or potential side effects. The 100% schema coverage helps with parameters but doesn't compensate for the lack of behavioral context.

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?

The schema description coverage is 100%, so the schema already documents all three parameters (email, emailAddress, name) with their types and formats. The description adds no additional meaning about what these parameters represent beyond the generic 'user's information' reference, meeting the baseline for high schema coverage.

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 states the action ('Update') and resource ('an existing user's information'), making the purpose immediately understandable. It distinguishes from sibling tools like 'add_user' (creation) and 'delete_user' (deletion), though it doesn't explicitly differentiate from 'update_team' which updates a different resource type.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user must exist), when not to use it, or how it differs from similar tools like 'update_team' or 'add_user' beyond the obvious resource difference.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv1.0.0Mar 25, 2025
- First observedadd_user
- First observedcreate_team
- First observeddelete_team
- First observeddelete_user
- First observeddetail_team
- First observedget_user
- First observedlist_team_members
- First observedlist_teams
- First observedlist_users
- First observedupdate_team
- First observedupdate_user

Deploy Server

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

TDQS

A3.5/5.0

Scored 2026-04-18 10:55 across 11 tools

Disambiguation5/5

Every tool has a clearly distinct purpose targeting specific resources and actions, with no ambiguity. For example, add_user vs. update_user are differentiated by create/update semantics, and list_team_members is distinct from list_teams in scope. The descriptions reinforce these distinctions, making misselection unlikely.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case, such as create_team, update_user, and list_teams. This predictability aids agent understanding and tool selection, with no deviations in naming conventions across the set.

Tool Count5/5

With 11 tools, the count is well-scoped for managing teams and users in a TeamRetro domain. Each tool earns its place by covering essential operations like CRUD for both resources, plus specific actions like listing members, without being excessive or sparse.

Completeness5/5

The tool set provides complete CRUD and lifecycle coverage for teams and users, including create, read, update, delete, and list operations. There are no obvious gaps, such as missing pagination or filtering, and agents can handle typical workflows without dead ends.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

console-mcp-server
io.github.mia-platform
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
Cloud Platforms Developer Tools App Automation
23
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
Swagger MCPOAuth
com.smartbear
MCP server for AI access to Swagger by SmartBear.
API Testing Documentation Access Developer Tools
144
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
2

Related MCP Servers

Bitbucket MCP Server
Version Control CI/CD & DevOps
ATERCATES
A
license
C
quality
B
maintenance
MCP server for integrating with Bitbucket Cloud and Server APIs, enabling AI assistants to interact with repositories, pull requests, pipelines, and more.
Updated 2 months ago (2026-07-30 12:01 UTC)
59
51 npm
3
MIT
MCP Server with Authentication
Security API Testing
ahmad-act
A
license
C
quality
D
maintenance
Implements a secure MCP server with API Key and JWT authentication, providing tools like echo, login, secure_action, and admin_action. Includes MCP Inspector integration for testing and debugging.
Updated a year ago (2025-07-04 18:40 UTC)
1
3
MIT
Jira MCP Server
Project Management Workplace & Productivity
OrenGrinker
A
license
Not graded
quality
D
maintenance
A comprehensive, production-ready MCP server for seamless Jira Cloud integration, enabling AI agents and custom applications to manage boards, issues, users, projects, and workflows via natural language commands.
Updated a year ago (2025-06-22 06:42 UTC)
490 npm
4
MIT
jira-mcp
Project Management Developer Tools
ibacher
F
license
Not graded
quality
C
maintenance
A local MCP server that wraps the Jira REST API v3, enabling issue management, searching, commenting, and transitions for openmrs.atlassian.net via Basic Auth.
Updated 2 months ago (2026-08-06 14:20 UTC)
1
-