Documentation inconsistency: ListTools method signature on mcp-go.dev

[gtxy27]

Description

The documentation on mcp-go.dev shows an incorrect method signature for ListTools.

Issue

Documentation shows (incorrect):

c.ListTools(ctx)

Actual API signature:
func (c *Client) ListTools(
    ctx context.Context,
    request mcp.ListToolsRequest,
) (*mcp.ListToolsResult, error)

Correct usage:
toolsResult, err := c.ListTools(ctx, mcp.ListToolsRequest{})

Evidence

1. https://pkg.go.dev/github.com/mark3labs/mcp-go/client#Client.ListTools shows the correct 2-parameter signature
2. https://github.com/mark3labs/mcp-go/blob/main/examples/simple_client/main.go#L127-L138 uses 2 parameters
3. https://github.com/mark3labs/mcp-go/blob/main/client/client.go#L425 requires 2 parameters

Impact

New users following the mcp-go.dev documentation will encounter compilation errors when calling ListTools with only one parameter.

Suggested Fix

Update the documentation on mcp-go.dev to show the correct method signature with both parameters.

Environment

- mcp-go version: v0.43.2 (latest)

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• MCP error -32601: Tools not supported #37
• bug: Argument order not preserved in MCP JSON output #450
• feature: Add dynamic/runtime tools definition functionality #402
• sse connect error #74
• bug: MCP-Go Library Tool Schema Serialization Bug #671
• bug: Invalid method parameters while calling tool #338
• bug: Tools can be invoked without initialization #579
• bug: #648

🔗 Related PRs

#202 - Use correct name in Go documentation [merged]
#316 - docs(examples): correct use of GetArguments [merged]
#322 - docs: use helper functions and return error as result [merged]
#430 - Fix docs [merged]
#560 - docs(client): improve server reliability and error handling [merged]

👤 Suggested Assignees

• reigeo
• phplego
• floatingIce91
• wlxwlxwlx
• Pilsertech

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Coding Plan

Approach

Update documentation files to show the correct two-parameter signature for ListTools, ListResources, and ListPrompts methods, which require both a context and a request struct parameter.

Observations

This is a Go-based MCP (Model Context Protocol) library with documentation in MDX format under www/docs/pages/. The client API follows a consistent pattern where all List* methods (ListTools, ListResources, ListPrompts) require two parameters: a context and a request struct. The documentation currently shows inconsistent signatures - some files correctly show two parameters while others incorrectly show only the context parameter.

Assumptions

Assumption 1: Empty Request Struct Pattern

Options Considered:

• Use empty request struct mcp.ListToolsRequest{}
• Use nil for request parameter
• Use request struct with explicit fields

Chosen Option: Use empty request struct mcp.ListToolsRequest{}

Rationale: The plan explicitly specifies using empty struct initialization (e.g., mcp.ListToolsRequest{}) for all corrections

Assumption 2: Documentation Format Preservation

Options Considered:

• Preserve existing formatting and context
• Rewrite examples with improved formatting
• Consolidate examples

Chosen Option: Preserve existing formatting and context

Rationale: The plan emphasizes maintaining document style, readability, and teaching approach while only correcting signatures

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Correct List* Method Signatures Across Documentation

Update all documentation files that currently show single-parameter List* method calls to use the correct two-parameter signature matching the actual API implementation.

Task 1: Update operations.mdx Method Signatures

Update the 7 method call instances in www/docs/pages/clients/operations.mdx to include the request parameter.

• Update ListResources calls at lines 30, 55, 71, and 133 from c.ListResources(ctx) to c.ListResources(ctx, mcp.ListResourcesRequest{})
• Update ListTools calls at lines 327 and 430 from c.ListTools(ctx) to c.ListTools(ctx, mcp.ListToolsRequest{})
• Update ListPrompts call at line 554 from c.ListPrompts(ctx) to c.ListPrompts(ctx, mcp.ListPromptsRequest{})
• Ensure the code examples remain readable and properly formatted within their respective sections (resource listing, tool calling, and prompt usage demonstrations)

Task 2: Update basics.mdx Method Signatures

Update the 4 ListTools call instances in www/docs/pages/clients/basics.mdx to include the request parameter.

• Update all ListTools calls at lines 159, 416, 429, and 635 from c.ListTools(ctx) to c.ListTools(ctx, mcp.ListToolsRequest{})
• Maintain consistency with the document's teaching style and ensure examples remain clear for users learning client basics

Task 3: Update index.mdx Method Signatures

Update the 3 ListTools call instances in www/docs/pages/clients/index.mdx to include the request parameter.

• Update all ListTools calls at lines 56, 331, and 428 from c.ListTools(ctx) to c.ListTools(ctx, mcp.ListToolsRequest{})
• Ensure overview examples remain concise while showing correct usage

Task 4: Standardize transports.mdx Method Signatures

Review and standardize all List* method calls in www/docs/pages/clients/transports.mdx which currently shows mixed patterns.

• Update single-parameter calls at lines 303, 447, and 493 to include the appropriate request parameter
• Verify the two-parameter call at line 59 uses correct formatting consistent with other documentation
• Ensure all examples in the transports context demonstrate the correct API usage pattern

🤖 Prompt for AI agents

Update documentation files to correct List* method signatures from
single-parameter to two-parameter format.

In `www/docs/pages/clients/operations.mdx`:
- Change `c.ListResources(ctx)` to `c.ListResources(ctx,
mcp.ListResourcesRequest{})` at 4 locations
- Change `c.ListTools(ctx)` to `c.ListTools(ctx, mcp.ListToolsRequest{})` at 2
locations
- Change `c.ListPrompts(ctx)` to `c.ListPrompts(ctx, mcp.ListPromptsRequest{})`
at 1 location

In `www/docs/pages/clients/basics.mdx`:
- Change all `c.ListTools(ctx)` calls to `c.ListTools(ctx,
mcp.ListToolsRequest{})` at 4 locations

In `www/docs/pages/clients/index.mdx`:
- Change all `c.ListTools(ctx)` calls to `c.ListTools(ctx,
mcp.ListToolsRequest{})` at 3 locations

In `www/docs/pages/clients/transports.mdx`:
- Update single-parameter List* calls to two-parameter format with appropriate
request structs at 3 locations
- Verify existing two-parameter call uses consistent formatting

Preserve all existing formatting, code block structure, and surrounding
documentation text.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Update documentation files to correct List* method signatures from
single-parameter to two-parameter format.

In `www/docs/pages/clients/operations.mdx`:
- Change `c.ListResources(ctx)` to `c.ListResources(ctx,
mcp.ListResourcesRequest{})` at 4 locations
- Change `c.ListTools(ctx)` to `c.ListTools(ctx, mcp.ListToolsRequest{})` at 2
locations
- Change `c.ListPrompts(ctx)` to `c.ListPrompts(ctx, mcp.ListPromptsRequest{})`
at 1 location

In `www/docs/pages/clients/basics.mdx`:
- Change all `c.ListTools(ctx)` calls to `c.ListTools(ctx,
mcp.ListToolsRequest{})` at 4 locations

In `www/docs/pages/clients/index.mdx`:
- Change all `c.ListTools(ctx)` calls to `c.ListTools(ctx,
mcp.ListToolsRequest{})` at 3 locations

In `www/docs/pages/clients/transports.mdx`:
- Update single-parameter List* calls to two-parameter format with appropriate
request structs at 3 locations
- Verify existing two-parameter call uses consistent formatting

Preserve all existing formatting, code block structure, and surrounding
documentation text.

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!