Update cohere and MCP, add support for MCP ResourceLink returned from tools

[medaminezghal]

I've updated known model list with new OpenAI version, fixed MistralAI test issue in new version, added new ResourceLink MCP type and fixed tests for new MCP version.

[hyperlint-ai]

PR Change Summary

Updated tests to ensure compatibility with the latest versions of OpenAI, MistralAI, and MCP.

• Updated known model list with the new OpenAI version
• Fixed MistralAI test issue in the new version
• Adjusted tests for compatibility with the new MCP version

Modified Files

• docs/mcp/server.md

---

How can I customize these reviews?

Check out the Hyperlint AI Reviewer docs for more information on how to customize the review.

If you just want to ignore it on this PR, you can add the hyperlint-ignore label to the PR. Future changes won't trigger a Hyperlint review.

Note specifically for link checks, we only check the first 30 links in a file and we cache the results for several hours (for instance, if you just added a page, you might experience this). Our recommendation is to add hyperlint-ignore to the PR to ignore the link check for this PR.

[DouweM]

@medaminezghal Thanks Mohamed! The only thing I'm not sure about is how we should handle ResourceLink.

[DouweM]

@medaminezghal Can you please have a look at the failing coverage check?

[medaminezghal]

@DouweM Does it need to add some tests to fix coverage problem?

[DouweM]

Does it need to add some tests to fix coverage problem?

@medaminezghal Yep, there are already a number of test_tool_returning_<x> tests in tests/test_mcp.py, and we'll want one for ResourceLink. The test MCP server it uses is defined in tests/mcp_server.py, so that's where you'll want to add a new @mcp.tool that returns a ResourceLink, as well as an @mcp.resource that will return that actual resource once it's looked up.

[medaminezghal]

Does it need to add some tests to fix coverage problem?

@medaminezghal Yep, there are already a number of test_tool_returning_<x> tests in tests/test_mcp.py, and we'll want one for ResourceLink. The test MCP server it uses is defined in tests/mcp_server.py, so that's where you'll want to add a new @mcp.tool that returns a ResourceLink, as well as an @mcp.resource that will return that actual resource once it's looked up.

Do I need a real API key to use make update-vcr-tests?

[DouweM]

@medaminezghal I wouldn't use make update-vcr-tests as it will try to update every single cassette. To just record a cassette for your own test, you can run pytest --record-mode=rewrite <test file path>::<test function name>. If the test uses a real model, you do need an API key.

[medaminezghal]

@DouweM I don't have any API key to use it for tests, so, the make update-vcr-tests will not work.

Do you think I should use one of the file inside tests/assets/ for the ResourceLink?

For example:

@mcp.tool()
async def get_resource_link() -> ResourceLink:
    return ResourceLink(
        type='resource_link',
        uri=AnyUrl(Path(__file__).parent.joinpath('assets/kiwi.png').absolute().as_uri()),
        name='kiwi.png',
    )

[DouweM]

@medaminezghal I think you should only need the actual full file path in the @mcp.resource function that actually reads the resource, but yes using that file is great!

If you have your own OpenAI API key, you can generate the cassette for your new test with that, but if not feel free to push up the test and I can generate the cassette myself locally.

[medaminezghal]

@DouweM I will just duplicate the tests that use EmbeddedResource to use ResourceLink.

[DouweM]

@medaminezghal I was out for a few days but just had a chance to review this again. Please have a look at my comments and let me know if I can provide additional guidance (or take over).

[DouweM]

@medaminezghal Thanks for your work on this Mohamed! I don't think the MCP resource stuff is quite right yet though. Let me know if you'd like me to finish this up!

[DouweM]

@medaminezghal Please have a look at the failing tests

[medaminezghal]

@DouweM I've fixed the tests. The only failed ones are related with Logfire and mcp new tools.

[alexmojaki]

@medaminezghal I suggest maybe separating the OTel stuff into a different PR to not block this one.

[DouweM]

@medaminezghal As @alexmojaki suggested, can you please move the Logfire/OTel changes out into a separate PR? Because this was one was almost done and now those changes created some more issues to address :) If you can pull that out, I can make the MCP tests pass and merge this quickly.

[medaminezghal]

@DouweM Good idea, I will create new PR for Logfire/OTel.

[medaminezghal]

@DouweM The changes are reverted now.

[DouweM]

@medaminezghal Thanks Mohamed!