Loading ToolBench

Reading the current corpus…

fofa-mcp-server MCP server · F · ToolBench

← Browse

fofa-mcp-server

github.com/help116114/fofa-mcp-server

A Model Context Protocol server for comprehensive FoFa API integration with advanced cybersecurity features

2026-07-28+STDIO2 tools

48/100

Definition Quality65

Protocol Readiness45

Supportability23

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

The FoFa MCP server provides two tools with explicitly defined schemas and basic descriptions. However, significant gaps in parameter descriptions, output schema documentation, and error handling guidance reduce overall quality. The server is functional but falls short of production-grade standards. Naming follows verb conventions (search_, get_), which is positive. Input schemas are present and properly typed, but descriptions lack depth and output schemas are not documented. Parameter descriptions are minimal or absent in key areas.

Tools (2)

get_user_inforead onlyauthsource verified65/100

Get user information from FoFa

search_fofaread onlyauthsource verified65/100

Search FoFa's database for devices and services

Issues (6)

CRITICALtool ↗

Output schemas not documented for any tool. LLMs cannot determine what fields are returned, forcing them to infer structure or guess at downstream tool chain requirements.

search_fofaget_user_info

HIGHpaginated-result ↗

Result pagination limit (hardcoded to 5 items via sampleResponse) is not declared in tool description. Users/agents cannot know results are truncated. Pattern:paginated-result requires explicit limit declarations.

search_fofa

HIGHconstrained-input ↗

Numeric parameters (page, size) lack bounds documentation. No minimum/maximum specified; no guidance on valid ranges. Agents could pass absurd values (page=999999, size=1000000) without validation hints.

search_fofa

MEDIUMtool-description ↗

get_user_info description is only 34 characters, below adequacy threshold. Lacks any detail on output fields, context, or purpose. Pattern:tool-description requires 10-1024 chars; this is technically in range but too terse to guide LLM selection.

Recommendations

Add complete output schema documentation for search_fofa. Example: 'Returns: {results: [{ip: string, port: number, title: string, ...}], total: number, page: number, _sample_note?: string}'. This enables LLM to understand what fields are available and plan follow-up operations.
Add complete output schema documentation for get_user_info. Specify fields like 'username', 'email', 'api_quota', 'account_status', etc., so agents know what to extract.
Declare result limit explicitly in search_fofa description: 'Note: Results are limited to 5 items per call; use page parameter to fetch additional pages.' Also update UI/description to explain the sampleResponse truncation behavior.
Add bounds to numeric parameters: 'page: page number (minimum: 1, default: 1)', 'size: results per page (1-100, default: 100)'. This prevents invalid input and guides agent reasoning.
Expand search_fofa description from 49 chars to ~150 chars. Add: when to use it (e.g., 'Use to search for devices/services matching a FoFa query syntax'), expected output format hint, and pagination guidance.
Expand get_user_info description from 34 chars to ~120 chars. Add: what info is returned (account status, API quota, usage stats), when agents would call it (to check rate limits before bulk searches), and any prerequisites.
Add error recovery guidance. When FoFa API returns an error, return: 'FoFa API error: <error message>. Verify API credentials (FOFA_API_KEY, FOFA_EMAIL) are set and valid. If query syntax is invalid, try a simpler query or consult FoFa search syntax documentation.'

Score history

Overall score trend

↑ 48 points across a rubric change (v1 → v2)

48/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	F	48	2026-07-28+	v2
2026-03-09	F	0	-	v1