PR Title

feat(jira): support `additional_fields` as dict or JSON string

Summary

This patch lets the Jira FastMCP server accept additional_fields when it is passed either as a native dict or as a JSON‐encoded str. It removes validation failures that occurred when XML‐to‐JSON converters wrapped the object in quotes.

Rationale

External clients (e.g. Anthropic Claude, Cursor) often emit tool calls in an XML‐like format. During XML → JSON‐RPC conversion, a nested JSON object is injected as a plain string:

"additional_fields": "{\"priority\": {\"id\": \"2\"}}"

Pydantic rejected this with dict_type. Accepting the string and parsing it server‐side solves the problem without breaking existing callers that already send a dict.

Technical Details

• additional_fields type hint updated to dict[str, Any] | str | None.
• New branch parses a JSON string via json.loads; rejects invalid JSON or values that are not objects.
• Error messages clarified.

Code excerpt:

if additional_fields is None:
 extra_fields = {}
elif isinstance(additional_fields, dict):
 extra_fields = additional_fields
elif isinstance(additional_fields, str):
 extra_fields = json.loads(additional_fields)
 if not isinstance(extra_fields, dict):
 raise ValueError("parsed additional_fields is not an object")
else:
 raise ValueError("additional_fields must be a dict or JSON string")

Tests

• test_create_issue_additional_fields_str_ok – JSON string accepted, issue created.
• test_create_issue_additional_fields_str_invalid – invalid JSON string returns clear ValueError.
• Existing tests for dict input remain green.

Backward Compatibility

• No breaking changes.
• Calls that already send a dict behave exactly as before.
• Calls that send a non‐JSON string still fail fast with a clear error.

Documentation

• Docstring for create_issue updated.
• If the public OpenAPI / tool schema is exported, change the field definition to:

"additional_fields": { "type": ["object", "string", "null"] }

Related Issues

Fixes: #