OpenOSINT provides 23 OSINT reconnaissance tools with basic but incomplete definition quality. Strengths: all tools have names following verb_noun pattern (search_*, scrape_*), all have descriptions (10-200 chars typical), and input schemas are present with type definitions. Critical weaknesses: (1) parameter descriptions are almost entirely missing, 22 of 23 tools have input parameters like 'target', 'query', 'ip', 'domain' with NO descriptions explaining what they control or accept; (2) output schemas are completely undocumented, no tool declares what it returns, forcing LLMs to guess at response structure; (3) no error handling guidance, tools return success/failure with no recovery hints; (4) missing security details, many tools require API keys (HIBP_API_KEY, SHODAN_API_KEY, VIRUSTOTAL_API_KEY, CENSYS_API_ID/SECRET, IP2LOCATION_API_KEY, ABUSEIPDB_API_KEY) injected via environment variables (correct pattern) but no tool description mentions this or guides the user; (5) one tool (graph_review_candidates) is a WRITE operation but has minimal description of what 'decide' does or what side effects occur. The server lands at the lower end of 'fair', definitions exist but lack the rigor production systems require.

• Add a description to every input parameter. For parameters like 'email', write: 'The email address to search (e.g. user@example.com). Must be a valid email format.' For 'target', write: 'The domain, IP, username, or entity to investigate.' This makes the tool self-documenting for LLMs.
• Document the output schema for each tool. Add a text field like: 'Returns a JSON object with fields: accounts (array of account objects with name, url, found), error (string if lookup failed)' or 'Returns geolocation data including country, city, latitude, longitude, ISP, ASN.' Use the actual structure returned, not a generic placeholder.
• For tools requiring API keys (search_breach, search_shodan, search_virustotal, etc.), add a note to the description: 'Requires SHODAN_API_KEY environment variable. Set via: export SHODAN_API_KEY=your_key_here' This prevents silent failures and guides setup.
• For graph_review_candidates, add detailed descriptions: action: 'Either "list" (show pending candidates) or "decide" (record a verdict on a candidate)'; decision: 'Accept or reject the candidate for merging.' Also document what happens when 'decide' is called, is this reversible? Does it trigger a merge?
• Add error handling guidance to tool descriptions. E.g. 'Returns an error if the email is not found in breaches (error: not_found). Returns an error if API rate limit is exceeded (error: rate_limit_exceeded, retry after 1 minute).' This guides the LLM on what to do next.
• For search_gdelt_geo, add a format example: 'geofence_geojson: A GeoJSON FeatureCollection or Polygon string, e.g. {"type":"Polygon","coordinates": [[[-74, 40], [-73, 40], [-73, 41], [-74, 41], [-74, 40]]]}' This prevents malformed input.