A Model Context Protocol (MCP) server enabling AI assistants to interact with Spira by Inflectra. Exposes project management, testing, and requirements tools with support for artifacts like incidents, tasks, requirements, test cases, and releases.
The server implements 13 tools across search, create, update, and metadata operations for a project management platform. Tool naming is generally good (verb_noun pattern), but parameter descriptions and output schemas are inconsistently documented. Most tool descriptions are present but brief (many under 100 chars), and input schemas appear to be present but lack visible parameter descriptions in the source code provided. Error handling is not evident from the provided code. The server demonstrates reasonable organization via fastmcp but lacks comprehensive per-parameter documentation and structured output schema definitions needed for production-grade agentic tools.
Tools (13)
create_associationwriteauth50/100
Create an association/link between artifacts (related-to, depends-on, coverage)
create_commentwriteauth50/100
Create a comment on an artifact (supports 7 artifact types)
get_artifact_schemaread onlyauth50/100
Get field schema lookup for artifacts
mywork_search_artifactsread onlyauth50/100
Search for artifacts in the user's mywork (task, incident, requirement, test_case, test_set)
Input schemas not visible in provided source code. While fastmcp likely auto-generates schemas from function signatures, no explicit parameter descriptions, type constraints, enums, or format specifications are visible. Cannot verify schema completeness without seeing tool definitions.
Tool descriptions are minimal (most under 100 chars). They state WHAT but lack WHEN to use, dependencies, prerequisites, or return structure. Descriptions should answer: What does it do? When should the LLM call it instead of similar tools? What does it return?
Expand all tool descriptions to 80-200 characters. Include: (1) What does it do? (2) When to use vs similar tools? (3) Key return fields. Example: 'Search for artifacts in a product by type, status, or custom properties. Returns paginated list of IDs, titles, statuses. Use product_get_artifact for full details.'
Document input schemas explicitly in tool registration. Specify for each parameter: (1) type (string|integer|boolean|array|object), (2) enum values where applicable, (3) format (date-time, email, regex pattern), (4) min/max bounds, (5) required vs optional. Example: 'artifact_type' should declare enum=[task, incident, requirement, test_case, test_set].
Add output schema documentation to each tool. Describe returned fields, their types, and nesting structure. Example for mywork_search_artifacts: 'Returns {artifacts: [{id, name, type, status, assignee_id}], total_count, page, limit}'.
Add pagination parameters to search tools: limit (1-100, default 20), offset (0+), and cursor support. Return total_count and next_cursor to guide multi-page retrieval without context explosion.
Implement recovery guidance in error messages. Instead of 'Artifact not found', return 'Artifact 123 not found in product 456. Try: (1) workspace_search to list available products, (2) product_search_artifacts to find by name/status, (3) mywork_search_artifacts if it's your own item.'
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to schema definitions. Mark read-only tools (get_*, search_*, list_*) with readOnlyHint=true. Mark irreversible operations (create_*, delete_*, record_test_run) with destructiveHint=true.
Score history
Overall score trend
↑ 8 points across a rubric change (v1 → v2)
45/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
45
2026-07-28+
v2
2026-03-09
F
37
-
v1
50/100
Search for artifacts in a product (project)
product_update_artifactwriteauth50/100
Update an existing artifact in a product
program_search_artifactsread onlyauth50/100
Search for artifacts in a program (capability, milestone)
template_get_metadataread onlyauth50/100
Get template metadata including types, statuses, priorities, custom properties, severities, importances, probabilities, and impacts
workspace_getread onlyauth50/100
Retrieve a specific workspace (program or product)
No visible output schema documentation. Tools return artifact/workspace/metadata objects but the response structure is not documented. LLMs cannot plan downstream calls without knowing what fields are available.
No visible error handling documentation or recovery guidance. Tools do not specify what errors are retryable, user-fixable, or fatal, nor do they provide actionable recovery steps (e.g., 'If artifact not found, call mywork_search_artifacts to locate it').
Search tools (mywork_search_artifacts, product_search_artifacts, program_search_artifacts, workspace_search) lack pagination parameters (limit, offset, page_size). Large result sets will exhaust context window. No visible documentation of result limits or pagination strategy.
Naming collision risk: 'product_search_artifacts' vs 'program_search_artifacts' are similar names operating on different hierarchy levels (product vs program). While technically distinct, the resemblance could cause LLM confusion when many tools are available.
Create/update operations (product_create_artifact, product_update_artifact, create_comment, create_association) lack dry-run or confirmation step. Irreversible operations should support confirmation to prevent accidental data changes.
Parameter names like 'workspace_type' are generic without type hints (e.g., 'workspace_type_enum'). Without visible enum constraints in provided code, LLMs may hallucinate invalid values. Constraints must be declared in schema.
workspace_search
Document artifact type enumerations. Create_artifact, product_search_artifacts, and others reference artifact types (task, incident, requirement, test_case, test_set), formalize these as constrained enums in schema and description.
Add 'natural identifier' support where applicable. product_get_artifact likely needs artifact_id, but document whether it also accepts artifact_key, artifact_name, or other lookup fields. Accept multiple identifier types (id, name, key) and resolve internally.
Implement dry-run for create_* and update_* tools. Add optional 'dry_run=true' parameter that validates input without persisting. Return 'Validation successful. Call again with dry_run=false to confirm.' This prevents accidental writes.
Create a tool composition guide in server instructions. Add: 'Common flows: (1) workspace_search → product_get_artifact (→ create_comment), (2) mywork_search_artifacts → product_update_artifact, (3) product_get_artifact → create_association'. This guides multi-step planning.
Add field chaining hints. If create_artifact returns artifact_id, document that it's immediately usable in create_comment(artifact_id) and create_association(artifact_id). If product_search_artifacts returns product_id, confirm that product_id is valid for product_get_artifact.
Reduce scope of template_get_metadata. Currently returns 8 types of metadata (types, statuses, priorities, custom_properties, severities, importances, probabilities, impacts). Consider splitting into two tools: template_get_statuses (statuses, priorities, severities) and template_get_custom_properties to reduce response size and token cost.