This is a proxy server that forwards MCP protocol to a remote dochost.io HTTP API. The actual tool definitions are not defined in this server's source code, they are discovered from the remote API at runtime. All 6 tools (publish, update_page, list_my_pages, get_page, get_account, delete_page) are passed through unchanged from dochost.io/api/mcp. Per the HARD SCORING RULES, tool definitions that are inferred rather than directly visible in the source code must have their overall score capped at 50. Additionally, since the server's source does not contain explicit tool registration with full schemas and descriptions, only a proxy forwarding mechanism, we cannot verify the actual parameter schemas, input validation rules, or output structures. The publish.sh example shows ONE tool being called manually (publish) with a documented 2-parameter schema (body, format), but the other 5 tools are ONLY mentioned in the smoke test as assertions that they exist, no schemas are shown. Score is reduced further because this is a STDIO-only proxy with no direct integration of tool quality assurance; it merely relays whatever the remote server returns.

• Add explicit tool registration in server/index.js instead of relying on discovery from the remote API. Define schemas for all 6 tools locally so they are verifiable in code review and not opaque proxied responses. Currently, update_page, list_my_pages, get_page, get_account, and delete_page are black boxes.
• For each tool, write a description of 50-200 characters that answers: What does it do? When should the LLM use it instead of a similar tool? What does it return? Example for update_page: 'Update the content or metadata of an existing page. Returns the updated page object with new revision timestamp.'
• Document input parameter descriptions for all tools. For publish: 'body' should clarify it is the full document content (string); 'format' should explain when to use markdown vs html. For update_page, list_my_pages, etc., document all parameters (name, types, constraints, defaults).
• Document output schemas for all tools. Specify what fields are returned (e.g., for publish: returns {ok: boolean, url: string, expiresAt: string|null, message?: string}). This enables LLMs to understand what data is available for downstream operations.
• For list_my_pages, add pagination support: accept 'limit' (default 20, max 100) and 'offset' or 'cursor' parameters. Return a 'total' field so agents know if more pages exist. Document in the description: 'Returns up to 20 pages per request; use offset to fetch next pages.'
• For delete_page, implement and document a confirmation/dry-run pattern. E.g., add a 'confirm' parameter (boolean, default false). When false, return a preview of what would be deleted. This prevents accidental destruction by agents.