[MCP] company outputSchema declares employees as integer, but API returns string

[aaajiao]

Problem

The company MCP tool advertises an outputSchema where employees is an integer, but the underlying Longbridge API represents employees as a JSON string. MCP clients that validate structuredContent against the advertised schema reject the otherwise successful result.

This was observed with the Hosted MCP company tool. Other tested read-only tools work normally, so this is not an OAuth scope or MCP tool-filter issue.

Evidence

• longbridge-mcp/src/tools/output/fundamental.rs defines CompanyResponse.employees as Option<i64>:
  https://github.com/longbridge/longbridge-mcp/blob/main/src/tools/output/fundamental.rs#L620-L634
• The company tool attaches that type as its output_schema:
  https://github.com/longbridge/longbridge-mcp/blob/main/src/tools/mod.rs#L2276-L2294
• The canonical Longbridge OpenAPI SDK defines employees as String:
  https://github.com/longbridge/openapi/blob/main/rust/src/fundamental/types.rs
• The official API documentation also shows employees as a string:
  https://open.longbridge.com/docs/fundamental/fundamental/company_profile

Expected

The company structured result validates against its advertised MCP outputSchema.

Actual

When the response includes an employees string, validation fails because the output schema requires an integer.

Suggested fix

Change CompanyResponse.employees from Option<i64> to Option<String> so it matches the canonical API contract, and add a regression test that validates the returned structuredContent against the declared outputSchema.

Converting the API value to an integer would be less robust because the canonical contract intentionally exposes this field as a string.

[huacnlee]

That because of the original API data is a string value, as SDK part, we can't just parse to int.

[aaajiao]

Thanks — that is exactly the point of this issue. Since the original API returns employees as a string and the SDK should not coerce it to an integer, the MCP outputSchema should also declare it as a string.

The current main branch still defines CompanyResponse.employees as Option<i64>, so validating MCP clients will continue to reject the structured result. Could you please reopen the issue or change it to Option<String> and add a schema-validation regression test?