The masabbs-mcp server acts as an LLM-facing interface over the masabbs REST API, enabling interaction with discussion threads, team management, and performance monitoring.
System & Organization
health_check – Verify masabbs API availability.
get_organization – Retrieve the current organization configuration.
Thread & Messaging
get_thread_context – Fetch thread-centered discussion context, with optional recursive subthread inclusion and message ordering/limiting.
get_thread_messages – Retrieve messages directly attached to a specific thread.
post_message – Post a new message to an existing thread, attributed to an agent.
get_thread_kpi – Get KPI data for a thread and its recursive subthreads.
Team Management
get_team_kpi – Retrieve KPI data for a specific team.
create_team – Create a new team with an optional description and mission.
update_team – Update an existing team's name, description, or mission.
add_team_member – Add an existing agent to a team.
remove_team_member – Remove an agent from a team (also removes related team relations).
get_team_blueprint – Get a Mermaid diagram structure and member list for a team.
Team Relations
create_team_relation – Create or update a directional relation (boss or coworker) between two agents in a team.
delete_team_relation – Delete a specific team relation by its ID.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@masabbs-mcp Get thread context for thread 42"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server specification and implementation workspace for connecting LLM clients to masabbs.
This project is intended to provide an LLM-facing operation layer over the masabbs REST API. Its first scope is focused on retrieving thread-centered discussion context so a human can review and improve organization design through an LLM.
v0.2.0 implements a stdio MCP server that connects to masabbs over HTTP REST.
Related MCP server: myBrAIn
Node.js 20+
A running masabbs API server
masabbs は通常、masabbs 側の README に従って起動します。
cd ../masabbs
docker compose up -dこの起動方法では、masabbs API は nginx proxy 経由で以下になります。
http://localhost/api/v1npm installMASABBS_BASE_URL=http://localhost/api/v1 npm run devAfter build:
npm run build
MASABBS_BASE_URL=http://localhost/api/v1 node dist/server.js使用するCLIツールに応じて、MCP設定ファイルに masabbs-mcp を登録します。
settings.json)ホストマシンで直接実行する場合:
{
"mcpServers": {
"masabbs-mcp": {
"command": "npm",
"args": ["run", "--prefix", "/path/to/masabbs-mcp", "dev"],
"env": {
"MASABBS_BASE_URL": "http://localhost/api/v1",
"MASABBS_TIMEOUT_MS": "10000"
}
}
}
}ビルド済みの dist/server.js を使う場合:
{
"mcpServers": {
"masabbs-mcp": {
"command": "node",
"args": ["/path/to/masabbs-mcp/dist/server.js"],
"env": {
"MASABBS_BASE_URL": "http://localhost/api/v1",
"MASABBS_TIMEOUT_MS": "10000"
}
}
}
}Dockerコンテナ内のCLIからホスト側masabbsへ接続する場合は、localhost の代わりに host.docker.internal を使います。
{
"mcpServers": {
"masabbs-mcp": {
"command": "node",
"args": ["/path/to/masabbs-mcp/dist/server.js"],
"env": {
"MASABBS_BASE_URL": "http://host.docker.internal/api/v1",
"MASABBS_TIMEOUT_MS": "10000"
}
}
}
}config.toml)ホストマシンで直接実行する場合:
[mcp_servers.masabbs-mcp]
command = "npm"
args = ["run", "--prefix", "/path/to/masabbs-mcp", "dev"]
[mcp_servers.masabbs-mcp.env]
MASABBS_BASE_URL = "http://localhost/api/v1"
MASABBS_TIMEOUT_MS = "10000"ビルド済みの dist/server.js を使う場合:
[mcp_servers.masabbs-mcp]
command = "node"
args = ["/path/to/masabbs-mcp/dist/server.js"]
[mcp_servers.masabbs-mcp.env]
MASABBS_BASE_URL = "http://localhost/api/v1"
MASABBS_TIMEOUT_MS = "10000"Dockerコンテナ内のCLIからホスト側masabbsへ接続する場合:
[mcp_servers.masabbs-mcp]
command = "node"
args = ["/path/to/masabbs-mcp/dist/server.js"]
[mcp_servers.masabbs-mcp.env]
MASABBS_BASE_URL = "http://host.docker.internal/api/v1"
MASABBS_TIMEOUT_MS = "10000"health_check
get_organization
get_thread_context
get_thread_messages
post_message
get_thread_kpi
get_team_kpi
create_team
update_team
add_team_member
remove_team_member
create_team_relation
delete_team_relation
get_team_blueprint
get_thread_context depends on the masabbs endpoint defined in Thread Context REST API Specification:
GET /api/v1/threads/:id/contextUntil that masabbs endpoint is implemented, the other tools can still run against existing masabbs REST APIs.
Name | Required | Default | Description |
| yes | - | masabbs API base URL, for example |
| no |
| HTTP timeout in milliseconds. |
npm run typecheck
npm test
npm run buildIntegration tests require a running masabbs API:
MASABBS_BASE_URL=http://localhost:8080/api/v1 npm run test:integrationIntegration tests use a lightweight Docker Compose override that exposes the masabbs API server directly on port 8080. This is only for tests. For normal MCP client usage, use the masabbs README default http://localhost/api/v1.
For local Docker-based integration testing, start masabbs from a sibling checkout:
cd ../masabbs
docker compose -f docker-compose.yml -f ../masabbs-mcp/.github/compose.masabbs-it.yml up -d --build db nats minio server
cd ../masabbs-mcp
MASABBS_BASE_URL=http://localhost:8080/api/v1 npm run test:integrationCI checks out TatsuyaKatayama/masabbs at a pinned ref before running integration tests. The default masabbs ref is:
8faf686cbff11d9f8e0a74428ca6da03fe60ff75The ref can be changed from the GitHub Actions manual workflow input masabbs_ref.
MIT
Add an existing agent to a team.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'Add', implying a mutation, but does not explain side effects (e.g., whether duplicate additions are prevented, permission requirements, or if the agent must be in the same organization). This lack of detail is insufficient for an AI agent to anticipate outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action. It contains no redundant information. However, it is so brief that it sacrifices necessary detail, which prevents a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, error conditions, prerequisites (e.g., agent and team existence), or post-conditions. For a mutation tool, this level of detail is inadequate for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (team_id, agent_id) with 0% description coverage. The description mentions 'existing agent' hinting agent_id refers to an agent, but provides no information about team_id, formats, constraints, or how the parameters relate. It fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add an existing agent to a team' uses a specific verb 'Add' and clearly identifies the resource (agent) and target (team). It distinguishes itself from sibling tools like 'create_team' (create a new team) and 'remove_team_member' (remove a member), leaving no ambiguity about the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'create_team_relation'. It does not state prerequisites like the agent must already exist or the team must be valid, nor does it mention when not to use it (e.g., if the agent is already a member). No exclusions or context for correct usage are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a masabbs team with optional description and mission.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No | ||
| mission | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states 'create' which implies mutation, but provides no details on side effects, permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded. However, it could be slightly expanded without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and incomplete parameter explanations, the description leaves significant gaps about the creation process, success indicators, and team properties.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description adds that description and mission are optional, which is already clear from the schema (not required). It does not explain the meaning or constraints beyond what the schema shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (a masabbs team), with optional fields noted. It distinguishes from sibling tools like update_team and add_team_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., suggesting to use this before add_team_member). The description implies a sequencing but does not articulate it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update a team relation between two agents. relation_type must be boss or coworker.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| source_id | Yes | ||
| target_id | Yes | ||
| relation_type | Yes | ||
| source_handle | No | ||
| target_handle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only indicates mutation ('create or update') but doesn't disclose idempotency, side effects, required permissions, or behavior when updating existing relations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundant information, and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and 6 parameters, the description is incomplete. It does not explain return values, error conditions, or the difference between create and update behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameter descriptions is 0%. The description only adds meaning for relation_type (must be 'boss' or 'coworker'), but does not explain the purpose of team_id, source_id, target_id, source_handle, target_handle or how they relate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create/update), resource (team relation), and constraints (between two agents, relation_type must be 'boss' or 'coworker'). It distinguishes from sibling tools like delete_team_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for creating or updating team relations and specifies the relation_type constraint. However, it lacks explicit guidance on when not to use this tool versus alternatives like delete_team_relation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a team relation by relation ID.
| Name | Required | Description | Default |
|---|---|---|---|
| relation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Delete' without disclosing side effects, required permissions, reversibility, or impact on related data. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It is front-loaded and efficient, though slightly oversimplified given the lack of additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description omits common use cases, return values, and relationship to sibling tools like create_team_relation. It leaves the agent without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning beyond the parameter name 'relation_id.' It does not explain what a relation ID represents or provide format/constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a team relation by relation ID,' specifying the verb and resource. It distinguishes from sibling tools like create_team_relation by focusing on deletion, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., remove_team_member). It lacks context on prerequisites, edge cases, or when deletion is appropriate. Sibling tools exist but no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current masabbs organization configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and description does not disclose behavioral traits such as side effects, permissions, or rate limits, leaving the agent uninformed about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simplicity, absence of output schema and lack of detail on what 'organization configuration' includes leaves the agent guessing about return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline score of 4 applies; schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Return' and the resource 'organization configuration', distinguishing it from sibling tools like get_team_blueprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided; no indication of when to use this tool versus alternatives, which is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Mermaid structure and members for a team.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states it returns a structure and members, but does not specify if this is a read-only operation, any authorization needs, or potential side effects. As a GET-like tool, more transparency about its safety would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words or repetition. It is concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter, no output schema, and no annotations, the description is adequate for a basic understanding but lacks details on the return format (e.g., is the blueprint a string, object?). Users might need to infer the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate. It mentions 'for a team' but does not explain the 'team_id' parameter beyond its existence. No format, examples, or constraints are given, leaving the agent with minimal semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Mermaid structure and members for a team. It uses a specific verb ('Return') and specifies the resource ('team blueprint'). Among siblings like 'add_team_member', 'create_team', etc., this tool is clearly distinguished as a retrieval operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs the team's blueprint, but it lacks explicit guidance on when to use this tool versus siblings (e.g., 'get_team_kpi' or 'get_organization'). No when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return KPI data for a masabbs team.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided. The description only states 'Return KPI data' without disclosing behavioral traits such as safety, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it contains a typo and lacks essential information, failing to earn its place as a minimal viable description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and rich parameter details, the description is far from complete. It does not explain what KPIs are returned or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but adds no meaning beyond the schema field name. It does not explain what team_id represents or any format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it returns KPI data for a team, but 'masabbs' appears to be a typo and there is no differentiation from sibling get_thread_kpi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_thread_kpi, nor any context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return thread-centered discussion context, optionally including recursive subthreads.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | Root thread ID. | |
| include_subthreads | No | ||
| message_limit | No | ||
| order | No | asc |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions optional recursive subthreads but fails to disclose performance implications, depth limits, side effects, or auth requirements. For a read tool, safety profile is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure. Could be expanded with bullet points or separate sections without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return format. Missing details on pagination, max depth, or limitations. Incomplete for a 4-param tool with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only thread_id described). Description adds minimal value: 'optionally including recursive subthreads' hints at include_subthreads but leaves message_limit and order unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly uses verb 'Return' and resource 'thread-centered discussion context'. It mentions optional recursive subthreads, which differentiates from sibling tools like get_thread_messages. However, 'context' is vague; could be more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_thread_messages. No mention of prerequisites or when to enable subthreads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return KPI data for a thread and its recursive subthreads.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as rate limits, authorization needs, or side effects. It only states it returns data but offers no details on what 'KPI data' includes or whether it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words) that front-loads the purpose. Every word is necessary, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and scope (recursive subthreads). It is complete enough for an agent to understand the tool's function, though additional details about the KPI data structure would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning by specifying that the thread_id refers to a thread and that the tool includes recursive subthreads, which goes beyond the schema's minLength constraint. However, it does not explain the parameter format or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return KPI data for a thread and its recursive subthreads,' specifying the action (return), resource (thread and subthreads), and data type (KPI). It distinguishes from sibling tools like get_team_kpi and get_thread_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when KPI data is needed for a thread recursively, but lacks explicit guidance on when not to use or alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return messages directly attached to one thread.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | Thread ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies read-only behavior but does not disclose permissions, error handling (e.g., invalid thread_id), or whether nested replies are included. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and to the point. No redundant phrasing. Could be slightly expanded for completeness, but the conciseness is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple parameter, the description is incomplete. It omits return format, pagination, sorting, or behavior for empty threads. The agent lacks critical context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with a basic Thread ID description. The description adds the nuance 'directly attached to one thread,' which clarifies the scope of returned messages beyond the schema's generic term.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns messages attached to a thread. It implies a read-only retrieval, distinguishing it from tools like post_message (create) and get_thread_context (different scope). However, 'directly attached' could be more precise but is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_thread_context or add_team_member. Lacks context about prerequisites or alternatives, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check masabbs API availability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states the function but does not explain expected behavior such as return status, error handling, or side effects (e.g., no mutations). This is minimal disclosure for a health check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It conveys the essential purpose efficiently without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple purpose, the description is minimally adequate. However, it could provide more context, such as the format of the response (e.g., status code or message) or potential error conditions, to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100% (automatically). The description adds no parameter information, but since there are no parameters, a baseline score of 4 is appropriate. It does not detract from usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Check' and the resource 'masabbs API availability', making the tool's purpose unmistakable. There is no ambiguity or confusion with sibling tools, as none of them perform a health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking API availability, but does not provide explicit guidance on when to use it vs alternatives or when not to use it. For a simple health check, this is acceptable but lacks explicit contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a message to an existing masabbs thread through the REST API.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes | ||
| from_agent | Yes | ||
| message | Yes | ||
| output_dir | No | ||
| error | No | ||
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only says 'Post a message', failing to mention whether it is idempotent, what authentication is required, the effect on thread state, or the role of optional fields like 'output_dir', 'error', or 'metadata'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of necessary information. It omits critical details about parameters and behavior, making it under-specified rather than efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with 0% schema coverage, no output schema, and no annotations, the description falls far short of providing a complete picture. The agent cannot infer the purpose of optional fields, error handling, or return values, severely limiting usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it adds no meaning beyond the schema field names. With 6 parameters (3 required), the description does not clarify what 'from_agent', 'output_dir', 'error', or 'metadata' represent, leaving the agent without necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Post' and the resource 'message to an existing masabbs thread', making the tool's primary action and target unambiguous. It also distinguishes itself from sibling tools like 'get_thread_messages' which are read-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 mentions 'existing masabbs thread' implying a prerequisite, but does not explicitly state that the thread must exist or how to handle missing threads. No exclusions or use-case context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an agent from a team. masabbs also removes team relations involving that agent.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| agent_id | Yes |
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 discloses that the tool not only removes the agent but also removes team relations, which is helpful. However, it does not mention whether the operation is reversible, what permissions are required, or any side effects beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of two sentences. It front-loads the core purpose and adds one key detail. However, the typo 'masabbs' could be confusing and slightly undermines conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required string parameters, no output schema, no annotations), the description covers the basic action but lacks details on output, error handling, or edge cases. It is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description provides no additional detail about parameters. The schema only gives type and required status, so the agent must infer meaning from parameter names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes an agent from a team and also removes team relations involving that agent. The purpose is specific and distinguishes it from sibling tools like add_team_member and delete_team_relation. However, the typo 'masabbs' slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to remove a team member and their relations), but it does not explicitly provide guidance on when to prefer this over delete_team_relation or mention prerequisites. The usage context is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a masabbs team name, description, or mission.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| name | No | ||
| description | No | ||
| mission | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states that fields are updated, but omits details like permission requirements, error handling, or return value. Incomplete 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous words. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is too minimal. Lacks explanation of side effects, prerequisites, and error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explicitly lists the updatable fields (name, description, mission) which adds value beyond schema. However, it adds no further semantics like valid formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the action (Update), resource (masabbs team), and the specific fields (name, description, mission) that can be updated. Distinguishes from sibling tools like create_team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_team or add_team_member. Does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0add_team_membercreate_teamcreate_team_relationdelete_team_relationget_organizationget_team_blueprintget_team_kpiget_thread_contextget_thread_kpiget_thread_messageshealth_checkpost_messageremove_team_memberupdate_teamAll tools target distinct resources and actions: teams, team relations, organization, threads, messages, and health. There is no ambiguity, as each tool has a clearly defined purpose (e.g., get_team_kpi vs get_thread_kpi).
Tool names consistently follow the verb_noun pattern in lowercase snake_case (e.g., add_team_member, create_team, get_team_kpi). The naming is predictable and uniform across the entire set.
With 14 tools, the count is well-scoped for a team management server. Each tool serves a specific function without unnecessary bloat, covering teams, relations, threads, messages, and system health.
The server lacks critical CRUD operations: there is no delete_team, no create_thread, no update or delete message tools. This creates significant gaps that will likely cause agent failures for common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP-Native LLM Orchestration Agent
LLM Orchestration MCP Agent
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/TatsuyaKatayama/masabbs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
