Add optional page and limit parameters to list_tools for server‑side pagination

[samrat12x]

Body:
Describe the feature
Right now FastMCP’s list_tools always returns the full set of registered tools. For users embedding very large tool‐catalogs into LLM contexts, this can bloat payloads and exhaust context length. It would be great to support optional page and limit query parameters so clients can pull tools page‑by‑page.

Motivation and use cases

Context‑size management: LLM clients often need to send only a subset of tools at a time.

Performance: Large tool lists can increase parsing time; paginating on the server avoids sending unnecessary entries.

Consistency with other endpoints: Many GitBook APIs (and our own tools like list_spaces) already accept page/limit.

Proposed implementation

Update the core ListTools handler in fastmcp/server/fastmcp.py to accept two optional query params:

python
Copy
Edit
async def list_tools(self, page: int = 0, limit: int = 100):
all_tools = list(self._tools.values())
start = page * limit
return {
"data": all_tools[start:start+limit],
"page": page,
"limit": limit,
"total": len(all_tools)
}
Ensure backwards compatibility: if page/limit are omitted, return the full list as today.

Add unit tests covering default behavior and several pagination combinations.

Update README and OpenAPI schema to document the new parameters and response shape.

Alternatives considered

Keeping client‑side slicing only—but server‑side pagination is more efficient for very large catalogs.

Additional context
This mirrors how other FastMCP tools (e.g., list_spaces, list_collection_spaces) already handle paging. Happy to open a PR implementing this!