tests: add MCP-spec regression coverage

[NeKroFR]

Adds a test suite that catches the class of bug that broke tools/list for MCP clients like LM Studio.

New dep

• jsonschema>=4.0 (dev only). The existing _matches_schema helper in tests/test_output_schema.py was too permissive and missed the missing outputSchema.type. A real JSON-Schema validator matches what strict Zod clients do on the wire, so regressions fail here instead of in production.

However if you don't want to add the dependency, I can drop it and hand-roll a minimal validator covering the subset we actually use (type, properties, required, anyOf, oneOf, const, items, additionalProperties, pattern).

What's covered

6 files, 93 tests, all IDA-free.

• test_mcp_spec_tools_list.py: tool schema invariants over a broad fixture (name regex, description, inputSchema.type, outputSchema.type, no dupes). Direct regression guard for Fix MCP output schema wrapping for union object results #357.
• test_mcp_spec_schema_generation.py: every return-type shape (int, list, Optional, Union[TypedDict], nested, NotRequired, dict[str, TypedDict]) produces a root type: "object" schema, and runtime returns validate against it.
• test_mcp_spec_envelope.py: JSON-RPC 2.0 envelope over real HTTP (id echo, method-not-found code, error-code range, notifications return no body).
• test_mcp_spec_endpoints.py: initialize, ping, prompts/list, resources/list, resources/templates/list.
• test_mcp_spec_truncation.py: regression guard for Error during analysis: Invalid structured content returned by tool decompile: Additional properties are not allowed ('_download_hint', '_download_url', '_output_id', '_output_truncated', '_total_chars #361 and e802b32. Truncated structuredContent still validates the advertised outputSchema, no _-prefixed leaks, no {"_truncated": ...} sentinels.
• test_mcp_spec_http_e2e.py: real localhost ThreadingHTTPServer, urllib client, full envelope validation.

I made sure to be implementation-independent for the tests so we can change the internal attributes with no problems as long as the MCP contract holds, and all tests pass obviously :)

[mrexodia]

I was thinking about the following approach (possibly as a replacement, possible as an addition to what you have now):

• Run the tests in 'end-to-end MCP mode'
• We hook all @tool functions to go through a full MCP client/server flow (+schema validation). This can be done using the openai-agents package discussed in find_regex returns undeclared n field and fails MCP structured-content validation #327

This way we do not need to create specialized tests, 'just' some glue code and run all the tests twice. What do you think?

[NeKroFR]

I think the two approaches test different layers and complement each other.

The current tests target schema generation, so every Python return-type shape (Union[TypedDict], NotRequired, nested, Optional, etc.) _generate_tool_schema must produce a spec-compliant schema. Production tools don't exercise every shape, so dropping the synthetic fixtures would create blind spots.

And the E2E-through-MCP approach targets runtime conformance, so every production tool's real response must validate its advertised schema. That's a class of bug the current PR doesn't catch. I will add the E2E-through-MCP layer alongside my tests.

Just one question first, what do you want me to use to do that? Would the official mcp Python SDK is fine? The goal as I understand it is just to route test calls through MCP and validate schemas, I think it is enough.

[mrexodia]

Yeah agreed! I think any SDK is fine, as long as the client actually validates the schemas from the outputs (not sure what the official one does)

[mrexodia]

Nice! I think we also need to enable this option for at least one IDA version (9.3, maybe all?)

[NeKroFR]

no wait before merging, shouldn't have pushed yet mybad. I need to check a few things first

[NeKroFR]

Tested with 9.3, all good now. I think the better option would be to enable it on 9.3 only for now. MCP-mode catches schema and wire-format regressions, which aren't IDA-version dependent, so running on every version would roughly double CI time for little added signal. And as it is it will be easy to extend to 9.4+ later.