Three dynamically-generated tools with severely incomplete definitions. All three tools lack proper parameter descriptions, have vague/generic descriptions, and expose dangerous WRITE operations without safety guardrails. Tool schemas are minimal (pathParams/body/query as bare objects with no type constraints). No error handling guidance, no idempotency markers, no permission gates. The dynamic nature means tool names and schemas are runtime-generated and not statically verifiable, this caps per-tool scores at 50 maximum. Descriptions are generic boilerplate that do not explain WHEN to use each tool or what makes them distinct.

• Implement a static tool registry that pre-registers all REST/GraphQL/MCP tools at server startup with full schemas, descriptions, and parameter constraints. Dynamically-generated tools without static definitions cannot be properly validated or documented.
• Add comprehensive parameter descriptions for pathParams, body, and query. Example: 'pathParams (object): URL path segments extracted from the route. Each key is a segment name (e.g., 'id', 'org_id'); values must match the API's type constraints (string, integer, UUID format).'
• Implement a confirmation/dry-run pattern for all WRITE operations. Add a 'dry_run' boolean parameter (default false) or a separate 'preview_*' tool variant so agents can validate before executing destructive operations.
• Enhance tool descriptions to include: (1) What the tool does, (2) When to use it vs. similar tools, (3) What it returns, (4) Any prerequisites or dependencies. Target 100-200 characters per description.
• Add error handling guidance in tool descriptions. Example: 'If the endpoint returns 404, the resource does not exist. If 403, you lack permission, contact the admin. If 500, retry after 5 seconds.'