Skip to main content
Glama
upamune
by upamune

human_eye_tool

Request human visual assistance to describe environments, identify objects, or locate specific items through a human-operated interface.

Instructions

人間が目で見て状況を説明したり、特定のものを探したりします。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
promptYes

Implementation Reference

  • The primary handler function for the 'human_eye_tool' MCP tool. Decorated with @mcp.tool(), it generates a unique task ID, stores the observation prompt in the database via db_utils, polls asynchronously for human-provided result using wait_for_task_completion, and returns the observation as a dictionary.
    async def human_eye_tool(prompt: str, ctx: Context) -> Dict[str, str]:
        """人間が目で見て状況を説明したり、特定のものを探したりします。"""
        task_id = str(uuid.uuid4())
        instruction = f"👁️ 目を使って観察: {prompt}"
    
        # タスクをデータベースに追加
        db_utils.add_task(task_id, instruction)
    
        # ログ出力
        sys.stderr.write(f"Human task created: {task_id}. Waiting for completion...\n")
    
        # 結果を待機(非同期ポーリング)
        result = await wait_for_task_completion(task_id)
    
        # ログ出力
        sys.stderr.write(f"Human task {task_id} completed.\n")
    
        return {"observation": result}
  • Explicit JSON schema definition for the human_eye_tool, detailing input (prompt string) and output (observation string) structures, descriptions, and requirements. Defined in the HUMAN_TOOLS list.
    {
        "name": "human_eye_tool",
        "description": "人間が目で見て状況を説明したり、特定のものを探したりします。",
        "input_schema": {
            "type": "object",
            "properties": {
                "prompt": {"type": "string", "description": "観察するための指示"}
            },
            "required": ["prompt"]
        },
        "output_schema": {
            "type": "object",
            "properties": {
                "observation": {"type": "string", "description": "人間による観察結果"}
            },
            "required": ["observation"]
        }
    },
  • The FastMCP server instantiation and @mcp.tool() decorator on the handler function, which registers the human_eye_tool in the MCP server.
    mcp = FastMCP("human-mcp")
    
    @mcp.tool()
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool 'explains situations or searches for specific things,' but doesn't describe how it operates (e.g., real-time observation, image analysis), what inputs it expects beyond the prompt, or any constraints like rate limits or permissions. This is inadequate for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence in Japanese that conveys the core idea without unnecessary words. It's appropriately sized and front-loaded, though it could be more structured for clarity. Every sentence earns its place, but it's slightly vague.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a sensory-based tool with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't explain return values, error conditions, or how the tool interacts with the environment. For a tool that likely involves real-world observation, more context is needed to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description doesn't add any meaning about the single parameter 'prompt.' It doesn't explain what the prompt should contain, its format, or examples of usage. With low schema coverage and no parameter details in the description, it fails to compensate for the documentation gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'explains situations or searches for specific things using human vision,' which provides a general purpose but lacks specificity about what resources it accesses or what exactly it does. It distinguishes from siblings by mentioning 'human eye' but doesn't clearly differentiate functionality from tools like human_hand_tool or human_weather_tool beyond the sensory modality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for visual tasks but doesn't specify contexts, exclusions, or comparisons to sibling tools like human_ear_tool for auditory tasks. This leaves the agent without clear decision-making criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/upamune/human-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server