flow-team-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes: listing vs fetching a single endpoint, project vs participant-specific project lists, and different column types. However, get_project_columns and get_project_status_columns could be confused, and list_projects vs list_participant_projects may overlap without careful reading.
Naming Consistency4/5
The naming convention is predominantly verb_noun snake_case (get_, list_, create_, add_) which is predictable. The exception is flow_request, which does not follow the get/list pattern but still communicates its action clearly.
Tool Count5/5
With 11 tools, the set is well-scoped for a Flow project management and API integration server. Each tool addresses a distinct need, and the count is within the ideal 3-15 range without feeling bloated or thin.
Completeness4/5
The server covers core project operations: listing/creating projects, managing participants, accessing columns, and handling API endpoints including schema, list, get, and invocation. Missing are update/delete for projects or participants, but these may be out of scope for the intended workflows.
Average 2.9/5 across 11 of 11 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on June 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as required permissions, side effects, idempotency, rate limits, or response details. The description only states the basic action, leaving the agent without insight into operational implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and structurally simple, which is inherently concise. However, it under-specifies and essentially repeats the title, so it does not effectively use its brevity to convey important context. It is not as problematic as a single vague word, but it fails to add value beyond the name.
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 (8 parameters, nested objects, no output schema, no annotations), the description is grossly insufficient. It does not explain what constitutes a Flow project, the significance of required fields, or any expected outcomes, leaving the agent to infer everything from the schema.
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?
The description adds no meaning to parameters. The schema covers 75% of parameters, but the description does not clarify the remaining undocumented parameters (apiKey, baseUrl) or explain how the parameter groups (e.g., postPermission, commentPermission) relate to project creation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Flow 프로젝트를 생성합니다' (Creates a Flow project) is essentially a direct restatement of the tool name and title. It does not add specific scope or distinguish itself from sibling tools beyond the obvious create action, making it tautological.
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. There is no mention of situations where a different project-related tool (e.g., list_projects, add_project_participants) would be more appropriate, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 implies a read-only operation ('retrieves'), but it does not disclose authentication requirements, pagination, rate limits, or the structure of the returned participants. The description is minimal and adds only the read intent, lacking substantive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets to the point without unnecessary words or repetition. It is appropriately front-loaded with the action and resource. However, it is arguably under-specified, which slightly detracts from its effectiveness, but as a concise statement it is 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 simplicity (a read operation) and the lack of an output schema, the description is insufficient for an agent to fully understand the invocation context. It does not describe the return format, potential errors, or the significance of the parameters. The complete absence of parameter semantics and behavioral details leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining any parameters. It mentions project participants, hinting at projectId's role, but it does not clarify the purpose of apiKey or baseUrl, nor the format of projectId. With three parameters and no description coverage, the agent receives no added semantic value beyond the raw schema.
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 tool retrieves a list of project participants for a Flow project. It uses a specific verb ('조회합니다' - retrieves) and identifies the resource (project participants), which is understandable and distinct from sibling tools like list_projects or get_project_columns. However, it does not explicitly differentiate from list_participant_projects, so it misses the top 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. There is no mention of context, prerequisites, or exclusions. It simply states what the tool does without any usage direction, so the agent must infer applicability from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It does not disclose whether the operation is read-only, what authentication (apiKey) is required, or pagination behavior, even though the cursor parameter implies pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise, but it is under-specified. It conveys the basic purpose yet lacks structure or additional context, providing little beyond the tool name.
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 3 parameters, no annotations, and no output schema, this description is incomplete. It fails to mention pagination, authentication requirements, or relationships to sibling tools, leaving the agent under-informed.
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 coverage is only 33% (only cursor described), and the description adds no parameter semantics. apiKey and baseUrl are left undocumented, and the description does not explain how they relate to the tool's use.
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 'Flow 프로젝트 목록을 조회합니다' clearly states the action (list) and resource (Flow projects). It differentiates from sibling tools like list_flow_endpoints by focusing on projects, but does not explicitly name alternatives.
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?
There is no guidance on when to use this tool versus alternatives. It only states the listing action, with no context on pagination, prerequisites, or scenarios where other tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It only states that the tool retrieves columns, giving no information about return format, pagination, error behavior, or authorization requirements. This is insufficient for the agent to understand side effects or data semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently states the tool's core action and resource. It is front-loaded with the action and contains no redundant words, though it is so brief that it borders on under-specification.
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?
The tool has four parameters and no output schema, so the description should provide extra context about what the returned column list looks like and how it relates to status columns. The current one-liner offers no guidance on response structure or when to use this over related tools, making it incomplete for an agent to invoke confidently.
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?
The schema provides descriptions only for userId ('프로젝트 컬럼 조회 기준 사용자 ID'), while projectId, apiKey, and baseUrl have no description. The tool description adds no parameter-specific meaning beyond the schema, and with only 25% schema coverage, it fails to compensate for the lack of documentation on the remaining parameters.
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 tool retrieves the column list of a Flow project using the verb '조회합니다' (retrieve) and the resource 'Flow 프로젝트 컬럼' (Flow project columns). However, it does not explicitly distinguish this from the sibling tool get_project_status_columns, which likely returns status columns specifically, leaving some ambiguity about scope.
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?
There is no guidance on when to use this tool versus alternatives such as get_project_status_columns or list_projects. The description lacks any mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('adds participants') without explaining side effects, idempotency, whether existing participants are overwritten, authorization needs, or what happens on error. This is a significant transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and easy to read. However, it is extremely brief and essentially restates the title, so while it is efficient, it does not add substantive value beyond the title itself.
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 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns (if anything), how to handle errors, or the relationship between registerId and participants. The moderate schema descriptions are not enough for an agent to confidently invoke the tool correctly in varied situations.
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?
The description adds no parameter semantics beyond the schema. Schema coverage is 60% (3 of 5 parameters have minimal labels such as 'project ID' or 'participant info'), but the description does not clarify the role of 'registerId' (writer ID) or how it differs from 'participantId'. It also ignores apiKey and baseUrl, leaving their purpose undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Adds participants to a Flow project' (Korean). It uses a specific verb ('adds') and a specific resource ('participants to a Flow project'), which fully distinguishes it from sibling tools like get_project_participants that handle retrieval. The title reinforces this, 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.
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 does not mention conditions like 'use when you need to add participants', nor does it reference any prerequisites, limitations, or exclusions. The use case is only implied by the function itself, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. The verb '조회합니다' (inquire/retrieve) indicates a read-only operation, which is positive. However, it does not mention authentication, error behavior, or other side effects, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function with no filler. However, it is brief to the point of omitting crucial parameter context, so it is not maximally effective despite its brevity.
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 2 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the parameters, when to use the tool, or what the returned documentation looks like, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (toolName, operationId) with zero description coverage, and the tool description does not mention these parameters at all. The agent receives no guidance on what values to provide or how they affect the query, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Metadata, Request, Response, and Error documentation for a project API, using the verb '조회합니다' (retrieves). This distinguishes it from sibling endpoint-focused tools like get_flow_endpoint and list_flow_endpoints, though 'project API' could be more explicit.
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 this tool should be used when schema documentation for a project API is needed, but it provides no explicit comparison to alternatives or conditions for use. Sibling tools exist for endpoints, so clearer guidance would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full transparency burden. However, it merely restates the tool's function without disclosing additional behavioral traits such as authentication requirements, read-only nature, or result characteristics. The name and title already imply a list operation, so no extra value is added.
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, concise Korean sentence that directly states the purpose with no wasted words or unnecessary detail. It is appropriately sized for a simple list operation.
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?
The tool has no annotations, no output schema, and 0% parameter coverage. The description only covers the basic action, leaving all parameter semantics and any behavioral nuances unaddressed. For a simple listing tool this is minimal but still incomplete, especially without param explanations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (group, method, search, version). The burden is on the description to compensate, but it provides no parameter information whatsoever.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of endpoints from the Flow OpenAPI document. The verb '조회합니다' (retrieve/list) and resource 'endpoint 목록' (endpoint list) are specific, and the plural '목록' distinguishes it from sibling get_flow_endpoint which likely retrieves a single endpoint.
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. The description only states what the tool does, without any context for selection, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It labels the operation as a query ('조회합니다'), implying read-only intent, but does not mention authentication requirements, permissions, potential errors, or side effects. This minimal information is insufficient for safe autonomous invocation.
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, concise sentence that clearly states the function. It is well-structured, front-loaded with the action, and contains no redundant or filler words. Every part of the sentence 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?
Without an output schema, the description should clarify what the returned 'list' contains, but it only says 'status columns' without specifying fields, format, or error handling. Essential context like project membership requirements or rate limits is missing, making the tool poorly specified for complex autonomous workflows.
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 only 25%, with only userId having a description in the schema. The tool description itself adds no parameter-level meaning. projectId, apiKey, and baseUrl remain unexplained, forcing the agent to infer their purpose from the tool name and context. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('retrieves the list') and the specific resource ('status columns of a Flow project'). This distinguishes it from sibling tool get_project_columns, which likely handles general columns, by explicitly narrowing scope to 'status columns'.
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. There is no mention of 'use get_project_columns for other columns' or any exclusion criteria. The only hint is the tool name itself, which implies a specific use case but does not explicitly state it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context by revealing the default use of FLOW_API_KEY and automatic x-flow-api-key header. However, it omits critical behavioral traits: since it supports POST, PATCH, and DELETE, it can perform mutations, yet no warning about destructive operations or error handling is given. With no annotations, the description carries the full burden but only partially fulfills it.
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, two short sentences, with each providing distinct value: one states the function, the other the auth mechanism. There is no redundant or filler content, making it well-structured 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 8 parameters, nested objects, and no output schema or annotations, the description is too sparse. It fails to explain how to construct requests, what the response format is, or how to use path/query/body parameters. It also doesn't relate to sibling tools, making it incomplete for an agent to invoke reliably.
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 high (88%), with most parameters already having descriptive text. The description adds no parameter-specific meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls the Flow OpenAPI, with a specific verb and resource. It provides a bit more detail than the title by mentioning the automatic header, but it doesn't distinguish this generic request tool from the more specific sibling tools, so it lacks full differentiation.
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 the alternative sibling tools. The description does not mention scenarios like 'use for custom endpoints not covered by specialized tools' or any exclusions, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates a read operation but does not disclose return format, pagination, authentication requirements, or behavior when no projects are found.
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, concise sentence in Korean that immediately conveys the tool's purpose. It contains no redundant or filler content.
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?
The tool is relatively simple with 3 parameters and no output schema, and the description gives the core purpose. However, it lacks usage guidance, parameter context for apiKey/baseUrl, and any indication of the response shape, making it barely adequate.
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. It clarifies participantId as the 'specific user' but does not explain apiKey or baseUrl beyond what their names imply. More guidance on these parameters is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('retrieves') and a specific resource ('Flow projects in which a specific user participates'). This clearly distinguishes it from sibling tools like list_projects (all projects) and get_project_participants (participants of a project).
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 intended use case is implied by the description, but there is no explicit guidance on when to use this tool versus alternatives such as list_projects or get_project_participants. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It conveys that this is a read-only lookup ('조회합니다') and specifies the returned fields, but it does not disclose potential errors, permissions, rate limits, or side effects. It is adequate but not rich.
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, front-loaded sentence that states the action and target. It contains no filler or redundant information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, no output schema, no annotations), the description covers the essential aspects: what it does, what it returns, and what the parameter means. It lacks explicit usage guidance but is otherwise complete for a straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly states '엔드포인트 ID로' (by endpoint ID), giving semantic meaning to the single 'id' parameter beyond the raw schema. Since schema description coverage is 0%, this is valuable and clarifies what kind of identifier is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '조회합니다' (retrieves) and identifies the exact resource: Flow OpenAPI path, HTTP method, and document URL by endpoint ID. This clearly distinguishes it from sibling tools like list_flow_endpoints (listing) and flow_request (executing).
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 when you have a specific endpoint ID and need its metadata, but it does not explicitly mention when to use this versus list_flow_endpoints or alternatives. No when-not conditions or alternative tool names are provided, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![flow-team-mcp MCP server](https://glama.ai/mcp/servers/baekbeombyeon/flow-team-mcp/badges/card.svg)](https://glama.ai/mcp/servers/baekbeombyeon/flow-team-mcp)

Score Badge

Copy to your README.md:

[![flow-team-mcp MCP server](https://glama.ai/mcp/servers/baekbeombyeon/flow-team-mcp/badges/score.svg)](https://glama.ai/mcp/servers/baekbeombyeon/flow-team-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/baekbeombyeon/flow-team-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server