The NowAIKit server provides 19 tools with generally clear names following verb_noun conventions (search_tools, query_records, get_table_schema, create_record, update_record, delete_record). Descriptions are present for all tools and range from moderate to good detail. However, there are significant gaps: (1) Input schemas visible in the provided data show descriptions for parameters, but full JSON Schema type information cannot be verified from the code excerpt provided, only parameter names and descriptions are shown. (2) Output schemas are NOT documented, the evaluation data does not include return type schemas for any tool, forcing LLMs to infer result structure. (3) Error handling guidance is minimal, tools do not describe recovery paths or error classifications. (4) Some parameter names are ambiguous or lack type suffixes (e.g., 'query' appears in multiple tools but formats differ; 'limit' is numeric but min/max not specified in descriptions). (5) The dry_run pattern on destructive operations (create_record, update_record, delete_record) is good practice, but dry_run is not clearly described in what it returns, does it show the resolved payload, a diff, or just validation? (6) Tool descriptions average ~150 chars (within 10 - 1024 baseline), but several are vague about WHEN to use them vs alternatives (e.g., search_cmdb_ci vs get_cmdb_ci). (7) No evidence of permission scopes or security-gating declarations in tool definitions.

• Document output schemas for every tool using JSON Schema. Example: query_records should return {records: [{sys_id: string, [field]: any}], total_count: number, next_offset?: number}. Validate_query already does this well (returns {valid, issues, suggestions}), replicate that pattern.
• Add error handling guidance to each tool. Example for delete_record: 'If record not found, returns error: {code: NOT_FOUND, message: "Record not found", suggestion: "Verify sys_id is correct. Call get_record first to confirm."}'. Apply pattern:recovery-guide.
• Specify min/max constraints in parameter descriptions. Example: 'limit (default 10, range 1 - 1000)' instead of just 'Max records (default: 10, max: 1000)'. Add to: search_tools, query_records, search_cmdb_ci, list_active_events.
• Clarify tool selection guidance. Add disambiguation sections to descriptions. Example for get_user: 'Use this to retrieve a known user by email/username. For searching by partial name or attributes, use query_records(table="sys_user").' Apply to get_user, get_group, get_record, get_cmdb_ci.
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to schema definitions for create_record, update_record, delete_record. Mark create_record and update_record as non-idempotent without dry_run; mark dry_run variants as read-only.
• Expand brief descriptions to 50 - 150 chars. Examples: get_user ('Look up user details (name, email, department, manager) by email or username. Accepts both john@example.com and john.doe formats.'), cmdb_health_dashboard ('Retrieve CMDB data quality metrics: % server CI completeness, % network CI completeness, % CI relationships verified.').

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry