July 11th, 2025 by Adam Sandman
In this blog series we are introducing our new MCP Server for Spira, and demonstrating how you can use it to turbocharge your development processes. Model Context Protocol (MCP) is a new technology for connecting AI tools with backend services. This is the third article in the series, and demonstrates in detail some of the specific use cases that you can use the Spira MCP Server for. It assumes you have already installed and configured the Spira MCP Server as described in the previous article.
Using the My Work Feature
Now that we've got the MCP server configured and running, what I want to do first is ask it some simple questions.
Retrieving My Assigned Tasks
Using the My Work feature, I want to find out some information about the work I have to do. For example, imagine that I'm a developer, and I really want to be able to find out the tasks and bugs I've been assigned to work on. So we can ask Cline to get me a list of my assigned tasks:
The agent will then take your question and examine the list of available MCP tools to see if it can find one that it can use to answer your question:
The user wants to get a list of their assigned tasks in Spira. Looking at the file structure, I can see this is a project related to Spira, which appears to be a project management or issue tracking system. There's an MCP server connected called "inflectra-spira" that provides tools for interacting with Spira.
Looking at the available MCP tools, I see there's a tool called "get_my_tasks" that seems perfect for this request. This tool is described as:
"Retrieves a list of the open tasks that are assigned to me. Use this tool when you need to view the complete details of a specific task, examine the current state, assigned user, and other properties, get information about multiple tasks at once, or access the full description and selected fields of tasks."
This tool doesn't require any parameters according to its input schema, so I can use it directly.
I'll retrieve your assigned tasks from Spira using the MCP server.
In this case it has found a possible tool get_my_tasks and so it invokes the MCP tool (which in turn calls the Spira REST API) to get the list of open tasks assigned to the current user:
It retrieves back the list of tasks from Spira (that are formatted as markdown) and then comments on what it has found:
I've successfully retrieved the list of tasks assigned to the user in Spira. The response shows 18 tasks with their details including:
- Task ID and name
- Status (mostly "Not Started" with one "In Progress")
- Type (Development, Management, Infrastructure)
- Priority (ranging from None to 1-Critical and 2-High)
- Due DateNow I should use the attempt_completion tool to present this result to the user.
Now the really cool part is that the agent uses its special attempt_completion tool coupled with the brain of Claude Sonnet to then analyze the returned data and provide a aggregated and analyzed set of information, rather than just a raw listing of the 18 tasks:
One of the great aspects of the Cline agent interface is that I can then ask it follow up questions to further refine the data it has retrieved:
By asking this question, the Cline agent attempts to use the current date together with the due date of the various tasks to answer my question:
The user wants to know how many of the tasks are overdue. I need to analyze the due dates of the tasks and compare them with the current date.
From the environment details, the current date is July 7, 2025 (7/7/2025).
Looking at the due dates of the tasks:
1. [TK:52] - Due: 2022-07-22
2. [TK:54] - Due: 2022-07-22
3. [TK:64] - Due: 2022-07-02
4. [TK:65] - Due: 2022-07-02
5. [TK:84] - Due: 2022-02-11
6. [TK:228] - No due date
7. [TK:229] - No due date
8. [TK:230] - No due date
9. [TK:231] - No due date
10. [TK:232] - No due date
11. [TK:233] - No due date
12. [TK:83] - Due: 2022-02-11
13. [TK:125] - Due: 2022-04-09
14. [TK:126] - Due: 2022-04-09
15. [TK:73] - Due: 2022-04-04
16. [TK:93] - No due date
17. [TK:127] - Due: 2022-04-10
18. [TK:274] - Due: 2022-05-28All tasks with due dates are from 2022, which is about 3 years before the current date (2025). So all tasks with due dates are overdue. That's 12 tasks with due dates, all of which are overdue.
Again using the special completion tool, Cline can analyze this data to give the user a succinct answer:
Note that it is smart enough to let me know that 6 of the tasks have no due dates at all and therefore might need further analysis:
Now that I have my tasks, what about finding out if I also have any bugs to work on.
Retrieving My Assigned Bugs
I can use Cline to ask for my assigned incidents as well:
Again the agent will use Claude to figure out what I'm looking to do:
The user now wants me to get a list of their assigned incidents from Spira. Looking at the available MCP tools, I see there's a tool called "get_my_incidents" that would be perfect for this request. This tool is described as:
"Retrieves a list of the open incidents that are assigned to me. Use this tool when you need to view the complete details of a specific incident, examine the current state, assigned user, and other properties, get information about multiple incidents at once, or access the full description and selected fields of incidents."
Like the get_my_tasks tool, this doesn't require any parameters according to its input schema, so I can use it directly.
I'll retrieve your assigned incidents from Spira.
From this it will run the appropriate MCP tool get_my_incidents which calls the Spira REST API to get the list of assigned incidents in markdown:
The Cline built-in completion tool will yet again try and read this data to present it to me in the most meaningful way:
I've successfully retrieved the list of incidents assigned to the user in Spira. The response shows 9 incidents with their details including:
- Incident ID and name
- Status (mostly "New" with one "Assigned")
- Type (Bug or Incident)
- Priority (mostly "None" with one "1 - Critical")
- Severity (mostly "None" with one "3 - Medium")
- Due Date (mostly "None" with one dated 2022-03-11)Now I should use the attempt_completion tool to present both the tasks (from the previous query) and incidents to the user.
Note that because I have not started a new task (session) with Cline it has the context of my previous question (get my tasks) so it has decided to combine my tasks with my incidents. I did not explicitly request that, and if I wanted to keep the requests separate I should have used the "Start New Task" option:
So you can see how Cline is trying to add intelligence to the output rather than just blindly regurgitating what is in Spira. In this case I get the following:
plus I get the tasks lower down:
It even gives a nice summary at the end:
Now we technically wanted to know only about bugs, but the Spira MCP server doesn't include specific filtering capabilities. We did this to keep things simple, and as we will see, it's not really needed as the Cline agent can simply use Claude to handle it internally.
For example, if we ask Cline:
Then it can simply interpret the existing data that it has already retrieved. If you see the reasoning:
The user wants to know which of the incidents are critical bugs. I need to analyze the list of incidents I retrieved earlier and identify those that are both:
1. Type: Bug
2. Priority: Critical (1 - Critical)Looking at the incidents list:
1. [IN:119] - Type: Bug, Priority: None
2. [IN:112] - Type: Incident, Priority: None
3. [IN:113] - Type: Incident, Priority: None
4. [IN:114] - Type: Incident, Priority: None
5. [IN:115] - Type: Incident, Priority: None
6. [IN:116] - Type: Incident, Priority: None
7. [IN:118] - Type: Incident, Priority: None
8. [IN:120] - Type: Incident, Priority: None
9. [IN:7] - Type: Bug, Priority: 1 - CriticalFrom this analysis, only one incident meets both criteria:
- [IN:7] Cannot add a new book to the system (Type: Bug, Priority: 1 - Critical)
Using this analysis it will give me the information I asked for right away, with no additional API calls to Spira:
Note the final sentence though: It has answered my direct question and found the one bug that was critical (and provided its details), but more interestingly it found one incident that was classed as a Bug but had no priority set.
That could be a bug that was missed during incident review and therefore poses a potential unknown risk.
So here we can see the benefit of using Artificial Intelligence, the agent has found an item that us humans missed. It did not answer my explicit question, but based on the AI's understanding of software quality, it realized that it was important and needed to be flagged.
Getting More Information
Now that I have been made aware of this flagged Bug, I can simply ask Cline to get me more information right from the context window:
The agent now tries to determine if it has all the information on this Bug, or whether it has a way to get more information from Spira:
This is all the information I have about this incident. It's a bug with the name "Incident 2" and description "Incident 2", but it doesn't have priority, severity, or due date set. It's in "New" status.
I don't have a specific MCP tool to get more detailed information about a single incident by ID. The available tools are more focused on getting lists of different types of artifacts. I should inform the user about the details I already have for this incident.
Since we haven't provided a more specific MCP tool to get all the incident fields (something on our backlog for the MCP Server), the agent has decided to simply tell the user all it already found:
As you can see, not only did it return the requested information, but it added subtle commentary that the Bug needs a better description... touché Cline (or maybe Claude!)
Now that we've explored the My Work MCP tools, in the next article we'll take a look at some of the other tools in depth.
