Skip to main content
Glama

get_tapd_stories

Fetch formatted JSON data for requirements from TAPD projects in a paginated manner, enabling efficient access to project management details for AI-driven analysis.

Instructions

获取TAPD平台指定项目的需求数据(支持分页)

Returns:
    str: 格式化后的需求数据JSON字符串

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • MCP tool handler and registration for 'get_tapd_stories'. Fetches TAPD stories data via helper function and returns formatted JSON.
    @mcp.tool()
    async def get_tapd_stories(clean_empty_fields: bool = True) -> str:
        """获取TAPD平台指定项目的需求数据(支持分页)
        
        功能描述:
            - 从TAPD API获取指定项目的所有需求数据
            - 支持分页获取大量数据
            - 自动处理API认证和错误
            - 数据不保存至本地,建议仅在数据量较小时使用
            
        返回数据格式:
            - 每个需求包含ID、标题、状态、优先级、创建/修改时间等字段
            - 数据已按JSON格式序列化,确保AI客户端可直接解析
            
        Returns:
            str: 格式化后的需求数据JSON字符串,包含中文内容
        """
        try:
            stories = await get_story_msg(clean_empty_fields=clean_empty_fields)
            return json.dumps(stories, ensure_ascii=False, indent=2)
        except Exception as e:
            return f"获取需求数据失败:{str(e)}"
  • Helper function that implements the core logic of fetching TAPD stories via paginated API requests using aiohttp.
    async def get_story_msg(clean_empty_fields: bool = True):
        url = 'https://api.tapd.cn/stories'  # TAPD需求API地址
        stories_list = []  # 存储所有需求数据的列表
        page = 1  # 初始页码
        while True:
            params = {
                'workspace_id': WORKSPACE_ID,
                # 若需要获取所有字段,请注释下面的fields参数
                # 'fields': 'id,workitem_type_id,name,description,workspace_id,creator,created,modified,status,step,owner,cc,begin,due,size,priority,developer,iteration_id,test_focus,type,source,module,version,completed,category_id,path,parent_id,children_id,ancestor_id,level,business_value,effort,effort_completed,exceed,remain,release_id,bug_id,templated_id,created_from,feature,label,progress,is_archived,tech_risk,flows,priority_label',
                'page': page
            }
            async with aiohttp.ClientSession() as session:
                async with session.get(url, auth=aiohttp.BasicAuth(API_USER, API_PASSWORD), params=params) as response:
                    if response.status != 200:
                        print(f'获取需求第{page}页失败: {await response.text()}')
                        break
                    result = await response.json()
                    if result.get('status') != 1:
                        print(f'获取需求第{page}页失败: {result.get("info")}')
                        break
                    current_page_data = result.get('data', [])
                    if not current_page_data:  # 无更多数据时结束循环
                        break
                    for story in current_page_data:  # 遍历当前页的每条需求数据,提取Story字段
                        story_data = story.get('Story', {})
                        if not story_data.get('id'):  # 检查需求id是否为空
                            print(f'发现需求数据id为空(第{page}页),结束获取')
                            return stories_list  # 遇到空值立即终止并返回已有数据
                        # 根据参数决定是否清洗空数据字段(None/空字符串)
                        if clean_empty_fields:
                            processed_story = {k: v for k, v in story_data.items() if v not in (None, "")}
                        else:
                            processed_story = story_data
                        stories_list.append(processed_story)
            page += 1  # 页码递增
        print(f'需求数据获取完成,共获取{len(stories_list)}条')
        return stories_list
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 pagination support and the return format ('格式化后的需求数据JSON字符串'), but fails to disclose critical behavioral traits such as authentication requirements, rate limits, error handling, or what '指定项目' (specified projects) means operationally. For a data retrieval tool with zero 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.

Conciseness3/5

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

The description is brief (two sentences) but could be more front-loaded. The first sentence states the purpose and pagination support, while the second describes the return format. However, the structure isn't optimal - the return format information might be better integrated or placed in an output schema. It's concise but not perfectly 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 absence of annotations and output schema, the description is incomplete. While it covers the basic purpose and mentions pagination and return format, it lacks crucial context about authentication, error conditions, how projects are specified, and differentiation from the sibling bug tool. For a data retrieval tool in what appears to be a TAPD integration, this leaves too many unanswered questions.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and behavior. This meets the baseline expectation for tools without 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's purpose: '获取TAPD平台指定项目的需求数据' (get requirement data for specified projects on TAPD platform). It includes a specific verb ('获取' - get) and resource ('需求数据' - requirement data). However, it doesn't explicitly differentiate from its sibling tool 'get_tapd_bugs', which likely retrieves bug data rather than requirement data.

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 minimal usage guidance. It mentions support for pagination ('支持分页'), which suggests when to use this tool for large datasets, but offers no explicit guidance on when to use this versus the sibling 'get_tapd_bugs' tool, nor any prerequisites or alternative scenarios. The guidance is insufficient for proper tool selection.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

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/OneCuriousLearner/MCPAgentRE'

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