…mcp server outputs a long line (#464)

Change-Id: Iaaaf44f80d2e49f5275c5f6903c87dcb4dbb53a3

Co-authored-by: tangyuyi <[email protected]>

This commit returns the `OutputSchema` from the tool definition as per
the MCP spec: https://modelcontextprotocol.io/specification/2025-06-18/server/tools#output-schema

The behaviour of `WithOutputSchema()` also changed as `RawOutputSchema`
is not longer populated, but `OutputSchema` is from the `T` generic
type. The only way now to set `RawOutputSchema` is through the
`WithRawOutputSchema()` method.

* feat: add resource handler middleware capability

This is a fairly direct adaption of the existing tool handler middleware
to also allow support for resource middlewares.

Use case: I'm working on an MCP server that manages an API client that
is used for both tool and resource calls. The tool handler middleware
provides a nice pattern to wrap tool calls that fits some use cases
better than the before/after tool call hooks. It would be helpful to
have first party support for this pattern in the library so I don't need
to work around it with custom closures etc.

Notes:
- There are currently (that I can find) that exercise the existing tool
  handler middleware logic, so I did not add tests for the resource
handler middleware logic.
- Existing docs, specifically those for the streamable HTTP transport,
  reference some middleware functions (for both tools and resources)
that don't exist (ex: `s.AddToolMiddleware` does not,
`s.AddResourceMiddleware` does not exist, etc). It seems they may be out
of date. Happy to discuss updates to docs in a separate PR.

Signed-off-by: TJ Hoplock <[email protected]>

* feat: add `WithResourceRecovery()` ServerOption

The existing `WithRecovery()` ServerOption is tool oriented, this adds a
corresponding recovery handler for resources. This will be especially
useful if Resource middlewares are used, where things may possibly/need
to panic.

Signed-off-by: TJ Hoplock <[email protected]>

---------

Signed-off-by: TJ Hoplock <[email protected]>

* tests

tls

* log

* fail

* clean

* docs

* nit

* nit

* fix: prevent double-starting stdio transport in client

Avoid starting stdio transport twice by checking transport type before
calling Start(). The stdio transport from NewStdioMCPClientWithOptions
is already started and doesn't need to be started again.

* docs: update NewStdioMCPClient comment for clarity

* docs(client): improve server reliability and error handling

- Add a health check step using Ping to verify server availability
- Change error handling for listing tools and resources to terminate the program on failure

Signed-off-by: Bo-Yi Wu <[email protected]>

* style: remove emojis for neutral health check log output

- Remove emojis from health check log and success messages for a more neutral output

Signed-off-by: appleboy <[email protected]>

---------

Signed-off-by: Bo-Yi Wu <[email protected]>
Signed-off-by: appleboy <[email protected]>

If the user has set the MCP_CLIENT_ID environmental variable then they
don't want Dynamic Client Registration and it should be skipped.

* fix(tool): Do not return empty `outputSchema`

If the output schema is not specify, we do not return it as we break the MCP specification that are expecting the following format:

```json
  "outputSchema": {
    "type": "object",
    "properties": {},
    "required": []
  }
```

* fix(tool): typo in test