Three tools with basic definitions but significant quality gaps. GetProjects and SearchWikis have minimal descriptions (34 and 33 chars respectively, below the 50-char baseline for clarity). SetProject lacks parameter description entirely. No input schemas visible in tool registration, only inferred from method signatures. No output schemas documented. Error handling is minimal (SearchWikis returns raw JSON; SetProject returns plain strings). No parameter validation guidance. Tool composition is weak: SetProject mutates shared state (memory dict) rather than returning structured data, violating single-responsibility principle.

• Add explicit JSON Schema to each tool parameter. For SetProject, define: {"type":"object","properties":{"project":{"type":"string","description":"The Azure DevOps project name (e.g. 'MyProject'). Must match an existing project in the organization."}},"required":["project"]}
• Expand tool descriptions to 100-150 chars. Example for GetProjects: 'Retrieves all Azure DevOps projects in the configured organization. Returns project names. Call this first to discover available projects before setting a target project.'
• Document output schemas. GetProjects should specify: returns array of project names (strings). SearchWikis should return structured object with fields: count (int), results (array of {title, path, url}).
• Refactor SetProject to return a structured response object instead of mutating shared state: {"success":true,"project":"MyProject","message":"Project set to MyProject"}. This makes state changes explicit and testable.
• Add parameter validation and error guidance. SearchWikis should validate searchText is non-empty and return: 'Project not set. Call SetProject(project="ProjectName") first.' instead of relying on implicit state.

Inferred effective spec: <=2025-11-25.

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