================================================================================
EXPLORER 0
================================================================================

--- INPUT PROMPT ---

You are an environment design expert helping to build realistic tool ecosystems for AI agents.

We are building an environment for an AI agent that will assist a user with tasks in a specific domain. You need to propose a COMPONENT (a specific service or system) and then propose tools for that component.

<environment>
A dryland research facility monitoring soil moisture, ephemeral pools, and reptile populations
</environment>

<user>
A herpetologist tracking sidewinder rattlesnake movements
</user>

<existing_components>
None (this is the first component)
</existing_components>

<task>
1. Identify a REAL component/service that would exist in this environment
   - Must be an actual service, software, or system (e.g., "Microsoft Excel", "Gmail", "Salesforce CRM", "PostgreSQL Database", "Slack")
   - NOT generic categories like "email system" - use specific real services
   - Must be plausible for this specific environment and user role
   - Should NOT duplicate existing components

   STRONGLY PREFER DOMAIN-SPECIFIC COMPONENTS:
   - Prioritize specialized software/services relevant to this specific environment and user role
   - Generic system tools (Terminal, Bash, Text Editor, File System) should only be proposed occasionally when truly essential
   - Think: What specialized tools would this specific user actually use day-to-day?
   - Examples: Instead of "Text Editor", propose "LaTeX Editor" for a researcher, "Code Editor with Linter" for a developer, "Markdown Editor" for documentation

2. Propose 3-6 tools for this component
   - You may choose any number within this range based on what makes sense for the component
   - Each tool should do ONE specific thing (Single Responsibility Principle)
   - Tools should be diverse and cover different operations for this component
   - Avoid "mega-tools" that try to do everything at once
   - Consider what the user might ask the AI agent to do with this component

   ENSURE VARIETY IN READ/WRITE OPERATIONS:
   - Include a MIX of read-only, write-only, and read-write tools
   - Read tools: Query/retrieve data without modification (e.g., list_emails, get_job_status, search_records)
   - Write tools: Create/modify/delete data (e.g., send_email, cancel_job, update_record, delete_file)
   - Read-write tools: Operations that both retrieve and modify (e.g., archive_and_summarize, process_and_update)
   - Realistic components have BOTH read and write capabilities - don't create read-only or write-only components

3. Format requirements:
   - Tool names MUST follow Python method naming (lowercase_with_underscores)
   - Tool names should indicate which component they interact with
   - Naming can be diverse: "read_excel_cell", "send_gmail", "query_salesforce_leads", "postgres_execute_query", "create_slack_channel"
   - Each tool should have clear, specific parameters (not 10+ parameters)

   DESCRIPTION STYLE: DETAILED
   - If BRIEF: Write short 1-2 sentence descriptions for all tools (e.g., "Sends an email to specified recipient.")
   - If DETAILED: Write comprehensive 3-6 sentence descriptions with behavior details, constraints, edge cases, return values
     Example: "Cancels a running SLURM job by job ID. If the job is already completed or cancelled, returns an error. Requires the job to be owned by the current user or admin privileges. Returns cancellation confirmation and final job status."
</task>

<response_format>
Respond with a JSON object in this exact format:
{
  "component_name": "Specific Real Service Name (e.g., Microsoft Excel, Gmail, Salesforce CRM)",
  "component_id": "lowercase_identifier (e.g., excel, gmail, salesforce)",
  "resources": {
    "resource_type": {
      "description": "What this resource represents",
      "fields": ["field1", "field2", "field3"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "tool_name_indicating_component",
        "description": "Clear description of what this tool does.",
        "operation_type": "read|write|read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "param_name": {
              "type": "string",
              "description": "Parameter description."
            },
            "tags": {
              "type": "array",
              "items": {"type": "string"},
              "description": "List of tags (for array parameters, MUST include 'items' field)"
            }
          },
          "required": ["param_name"]
        }
      }
    }
  ]
}

IMPORTANT:
- Component must be a REAL service/software that would be used in this environment
- Tool names must be lowercase_with_underscores
- Tool names should make it clear which component they're for (naming convention can vary)
- Each tool should be focused and specific, not a mega-tool
- Each tool MUST specify operation_type: "read", "write", or "read-write"
  * "read" = retrieves/queries data without modification
  * "write" = creates/modifies/deletes data
  * "read-write" = both retrieves and modifies in a single operation
- ARRAY PARAMETERS: If a parameter has "type": "array", you MUST include an "items" field specifying the array element type
  * Example: {"type": "array", "items": {"type": "string"}}
  * Valid item types: "string", "number", "boolean", or object schemas

RESOURCES - Keep them SIMPLE:
- Define what data/entities this component manages (e.g., for SLURM: jobs, queue; for Gmail: emails, folders)
- Use 2-5 fields per resource (MAXIMUM 5 fields, only if absolutely necessary)
- Only include ESSENTIAL fields that tools actually need to read/modify
- DO NOT include: authentication details, permissions, access levels, audit logs, metadata timestamps
- DO NOT include any date or time fields (no created_at, updated_at, timestamp, submit_time, date fields). This is critical for evaluation purposes.
- Good example: job: [job_id, status, user, partition, priority]
- Bad example: job with 20+ fields including detailed permissions, logging, authentication, etc.

CRITICAL - RESOURCES MUST CONTAIN ACTUAL READABLE CONTENT:
- Resources MUST contain a field with ACTUAL READABLE CONTENT, not just references
- Path/URL fields are allowed as OPTIONAL METADATA, but only if a content field is also present
- Good: document: [doc_id, title, content, author] where "content" is the actual text
- Good: document: [doc_id, title, file_path, content, author] where both path AND content exist
- Bad: document: [doc_id, title, file_path, author] where "file_path" is the only data (no actual content)
- Good: email: [email_id, subject, body, sender] where "body" is the actual email text
- Bad: email: [email_id, subject, attachment_url, sender] where URL is the only data (no actual content)
- Good: dataset: [dataset_id, name, data, owner] where "data" is actual data content
- Bad: dataset: [dataset_id, name, root_path, owner] where "root_path" is the only data (no actual content)
- If representing file systems or data collections, define resources as the ACTUAL FILES/ITEMS with content

TOOLS - Return FULL data by default:
- Tools should return ALL fields for ALL matching resources (e.g., list_jobs returns jobs from ALL users, not just current user)
- DO NOT implement access controls or filtering in tool descriptions
- The agent should have full read access to all resource data
- Example: "list_slurm_jobs" should return all jobs in the queue, not just the user's jobs
- Example: "search_emails" should return all matching emails, not filtered by sender/recipient

Only respond with the JSON object, nothing else.
</response_format>

--- OUTPUT ---

{
  "component_name": "Movebank",
  "component_id": "movebank",
  "resources": {
    "study": {
      "description": "A Movebank study that groups animals, deployments, and tracks under a research project.",
      "fields": ["study_id", "title", "description"]
    },
    "animal": {
      "description": "An individual tracked organism within a study.",
      "fields": ["animal_id", "name", "species", "notes"]
    },
    "deployment": {
      "description": "An association of a device with an animal, representing a period during which locations are collected.",
      "fields": ["deployment_id", "animal_id", "device_id", "notes"]
    },
    "track": {
      "description": "A collection of ordered locations associated with an animal (e.g., GPS fixes, VHF triangulations) and a textual summary.",
      "fields": ["track_id", "animal_id", "coordinates", "summary"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "movebank_list_studies",
        "description": "Lists all studies visible in the Movebank account, returning complete study records. Supports lightweight filtering by title text or species mention within the description, but returns all matching studies with full fields by default. If no filters are provided, returns every study with title and description. Results include the study_id needed for downstream operations.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "title_contains": {
              "type": "string",
              "description": "Optional substring to filter study titles."
            },
            "description_contains": {
              "type": "string",
              "description": "Optional substring to filter study descriptions (e.g., species name)."
            }
          },
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_get_tracks",
        "description": "Retrieves track resources (coordinates and summaries) for one or more animals within a study. Supports optional spatial filtering via a bounding box or polygon and can restrict to a subset of animal IDs; if unspecified, returns all tracks in the study. Coordinates are returned in full for each matching track, and the summary includes an overview of points and basic path characteristics. If no tracks match, returns an empty list without error.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "study_id": {
              "type": "string",
              "description": "Identifier of the Movebank study from which to retrieve tracks."
            },
            "animal_ids": {
              "type": "array",
              "items": {"type": "string"},
              "description": "Optional list of animal IDs to restrict results."
            },
            "bbox": {
              "type": "array",
              "items": {"type": "number"},
              "description": "Optional bounding box [min_lon, min_lat, max_lon, max_lat] to spatially filter coordinates."
            },
            "polygon": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "lat": {"type": "number"},
                  "lon": {"type": "number"}
                },
                "required": ["lat", "lon"]
              },
              "description": "Optional polygon as an array of lat/lon vertices to clip tracks to the interior."
            }
          },
          "required": ["study_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_create_deployment",
        "description": "Creates a new device deployment linking a device to an animal within a study. The deployment record stores a notes field for contextual details such as capture method, transmitter placement, or health observations. If the device is already linked to another active deployment, the operation returns an error advising to end or replace that deployment first. Returns the complete deployment resource including deployment_id.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "study_id": {
              "type": "string",
              "description": "Study in which to create the deployment."
            },
            "animal_id": {
              "type": "string",
              "description": "Animal to which the device is being deployed."
            },
            "device_id": {
              "type": "string",
              "description": "Identifier of the device (e.g., GPS collar, VHF logger)."
            },
            "notes": {
              "type": "string",
              "description": "Free-text notes about the deployment (e.g., morphometrics, attachment method, site conditions)."
            }
          },
          "required": ["study_id", "animal_id", "device_id", "notes"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_update_animal_metadata",
        "description": "Updates an animal's metadata fields such as name, species, and notes. Only provided fields are modified; unspecified fields remain unchanged. Useful for correcting taxonomic labels, adding field observation context, or renaming individuals. Returns the full updated animal record.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "study_id": {
              "type": "string",
              "description": "Study containing the animal record."
            },
            "animal_id": {
              "type": "string",
              "description": "Identifier of the animal to update."
            },
            "name": {
              "type": "string",
              "description": "New animal name or code (e.g., SW-07)."
            },
            "species": {
              "type": "string",
              "description": "Species designation (e.g., Crotalus cerastes)."
            },
            "notes": {
              "type": "string",
              "description": "Free-text notes to append or replace existing notes."
            }
          },
          "required": ["study_id", "animal_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_import_vhf_fixes",
        "description": "Uploads manual VHF/triangulated fixes as a new or appended track for an animal and returns the resulting full track resource. The fixes array contains latitude/longitude pairs; if a track exists, points are appended in the provided order, and duplicates at the exact same coordinate are ignored. A summary is automatically updated to reflect point count and spatial extent. If the animal has no prior track, a new track resource is created.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "study_id": {
              "type": "string",
              "description": "Study that contains the animal."
            },
            "animal_id": {
              "type": "string",
              "description": "Animal to which fixes will be added."
            },
            "fixes": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "lat": {"type": "number"},
                  "lon": {"type": "number"}
                },
                "required": ["lat", "lon"]
              },
              "description": "Array of VHF fix coordinates in order of collection."
            },
            "append_to_track_id": {
              "type": "string",
              "description": "Optional existing track_id to append fixes to; if omitted, a new track is created."
            },
            "note": {
              "type": "string",
              "description": "Optional note to add into the resulting track summary (e.g., conditions, observers)."
            }
          },
          "required": ["study_id", "animal_id", "fixes"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_clip_tracks_to_polygon",
        "description": "Clips existing tracks to a provided polygon (e.g., an ephemeral pool or dune habitat extent) and saves the clipped segments as new track resources. The tool returns all newly created track records with full coordinates and summaries, and leaves original tracks unmodified. If no points fall inside the polygon, returns an empty list. This is useful for isolating movements within specific microhabitats used by sidewinders.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "study_id": {
              "type": "string",
              "description": "Study containing the source tracks."
            },
            "animal_ids": {
              "type": "array",
              "items": {"type": "string"},
              "description": "Optional list of animals whose tracks should be clipped; if omitted, all animals in the study are considered."
            },
            "polygon": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "lat": {"type": "number"},
                  "lon": {"type": "number"}
                },
                "required": ["lat", "lon"]
              },
              "description": "Polygon vertices (lat/lon) defining the clip region; first and last vertex are auto-closed if not identical."
            },
            "source_track_ids": {
              "type": "array",
              "items": {"type": "string"},
              "description": "Optional explicit list of track_ids to clip; if provided, overrides animal_ids."
            }
          },
          "required": ["study_id", "polygon"]
        }
      }
    }
  ]
}

================================================================================
EXPLORER 1
================================================================================

--- INPUT PROMPT ---

You are an environment design expert helping to build realistic tool ecosystems for AI agents.

We are building an environment for an AI agent that will assist a user with tasks in a specific domain. You need to propose a COMPONENT (a specific service or system) and then propose tools for that component.

<environment>
A dryland research facility monitoring soil moisture, ephemeral pools, and reptile populations
</environment>

<user>
A herpetologist tracking sidewinder rattlesnake movements
</user>

<existing_components>
None (this is the first component)
</existing_components>

<task>
1. Identify a REAL component/service that would exist in this environment
   - Must be an actual service, software, or system (e.g., "Microsoft Excel", "Gmail", "Salesforce CRM", "PostgreSQL Database", "Slack")
   - NOT generic categories like "email system" - use specific real services
   - Must be plausible for this specific environment and user role
   - Should NOT duplicate existing components

   STRONGLY PREFER DOMAIN-SPECIFIC COMPONENTS:
   - Prioritize specialized software/services relevant to this specific environment and user role
   - Generic system tools (Terminal, Bash, Text Editor, File System) should only be proposed occasionally when truly essential
   - Think: What specialized tools would this specific user actually use day-to-day?
   - Examples: Instead of "Text Editor", propose "LaTeX Editor" for a researcher, "Code Editor with Linter" for a developer, "Markdown Editor" for documentation

2. Propose 3-6 tools for this component
   - You may choose any number within this range based on what makes sense for the component
   - Each tool should do ONE specific thing (Single Responsibility Principle)
   - Tools should be diverse and cover different operations for this component
   - Avoid "mega-tools" that try to do everything at once
   - Consider what the user might ask the AI agent to do with this component

   ENSURE VARIETY IN READ/WRITE OPERATIONS:
   - Include a MIX of read-only, write-only, and read-write tools
   - Read tools: Query/retrieve data without modification (e.g., list_emails, get_job_status, search_records)
   - Write tools: Create/modify/delete data (e.g., send_email, cancel_job, update_record, delete_file)
   - Read-write tools: Operations that both retrieve and modify (e.g., archive_and_summarize, process_and_update)
   - Realistic components have BOTH read and write capabilities - don't create read-only or write-only components

3. Format requirements:
   - Tool names MUST follow Python method naming (lowercase_with_underscores)
   - Tool names should indicate which component they interact with
   - Naming can be diverse: "read_excel_cell", "send_gmail", "query_salesforce_leads", "postgres_execute_query", "create_slack_channel"
   - Each tool should have clear, specific parameters (not 10+ parameters)

   DESCRIPTION STYLE: BRIEF
   - If BRIEF: Write short 1-2 sentence descriptions for all tools (e.g., "Sends an email to specified recipient.")
   - If DETAILED: Write comprehensive 3-6 sentence descriptions with behavior details, constraints, edge cases, return values
     Example: "Cancels a running SLURM job by job ID. If the job is already completed or cancelled, returns an error. Requires the job to be owned by the current user or admin privileges. Returns cancellation confirmation and final job status."
</task>

<response_format>
Respond with a JSON object in this exact format:
{
  "component_name": "Specific Real Service Name (e.g., Microsoft Excel, Gmail, Salesforce CRM)",
  "component_id": "lowercase_identifier (e.g., excel, gmail, salesforce)",
  "resources": {
    "resource_type": {
      "description": "What this resource represents",
      "fields": ["field1", "field2", "field3"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "tool_name_indicating_component",
        "description": "Clear description of what this tool does.",
        "operation_type": "read|write|read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "param_name": {
              "type": "string",
              "description": "Parameter description."
            },
            "tags": {
              "type": "array",
              "items": {"type": "string"},
              "description": "List of tags (for array parameters, MUST include 'items' field)"
            }
          },
          "required": ["param_name"]
        }
      }
    }
  ]
}

IMPORTANT:
- Component must be a REAL service/software that would be used in this environment
- Tool names must be lowercase_with_underscores
- Tool names should make it clear which component they're for (naming convention can vary)
- Each tool should be focused and specific, not a mega-tool
- Each tool MUST specify operation_type: "read", "write", or "read-write"
  * "read" = retrieves/queries data without modification
  * "write" = creates/modifies/deletes data
  * "read-write" = both retrieves and modifies in a single operation
- ARRAY PARAMETERS: If a parameter has "type": "array", you MUST include an "items" field specifying the array element type
  * Example: {"type": "array", "items": {"type": "string"}}
  * Valid item types: "string", "number", "boolean", or object schemas

RESOURCES - Keep them SIMPLE:
- Define what data/entities this component manages (e.g., for SLURM: jobs, queue; for Gmail: emails, folders)
- Use 2-5 fields per resource (MAXIMUM 5 fields, only if absolutely necessary)
- Only include ESSENTIAL fields that tools actually need to read/modify
- DO NOT include: authentication details, permissions, access levels, audit logs, metadata timestamps
- DO NOT include any date or time fields (no created_at, updated_at, timestamp, submit_time, date fields). This is critical for evaluation purposes.
- Good example: job: [job_id, status, user, partition, priority]
- Bad example: job with 20+ fields including detailed permissions, logging, authentication, etc.

CRITICAL - RESOURCES MUST CONTAIN ACTUAL READABLE CONTENT:
- Resources MUST contain a field with ACTUAL READABLE CONTENT, not just references
- Path/URL fields are allowed as OPTIONAL METADATA, but only if a content field is also present
- Good: document: [doc_id, title, content, author] where "content" is the actual text
- Good: document: [doc_id, title, file_path, content, author] where both path AND content exist
- Bad: document: [doc_id, title, file_path, author] where "file_path" is the only data (no actual content)
- Good: email: [email_id, subject, body, sender] where "body" is the actual email text
- Bad: email: [email_id, subject, attachment_url, sender] where URL is the only data (no actual content)
- Good: dataset: [dataset_id, name, data, owner] where "data" is actual data content
- Bad: dataset: [dataset_id, name, root_path, owner] where "root_path" is the only data (no actual content)
- If representing file systems or data collections, define resources as the ACTUAL FILES/ITEMS with content

TOOLS - Return FULL data by default:
- Tools should return ALL fields for ALL matching resources (e.g., list_jobs returns jobs from ALL users, not just current user)
- DO NOT implement access controls or filtering in tool descriptions
- The agent should have full read access to all resource data
- Example: "list_slurm_jobs" should return all jobs in the queue, not just the user's jobs
- Example: "search_emails" should return all matching emails, not filtered by sender/recipient

Only respond with the JSON object, nothing else.
</response_format>

--- OUTPUT ---

{
  "component_name": "Movebank",
  "component_id": "movebank",
  "resources": {
    "animal": {
      "description": "Tracked individual reptiles within a Movebank study.",
      "fields": ["animal_id", "name", "species", "notes"]
    },
    "track": {
      "description": "Movement tracks associated with an animal.",
      "fields": ["track_id", "animal_id", "geojson", "tags"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "movebank_search_animals",
        "description": "Searches Movebank for animals by name or species and returns matching animal records.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "Free-text match on animal name or ID (use '*' to list all)."
            },
            "species": {
              "type": "string",
              "description": "Optional species filter (e.g., 'Crotalus cerastes')."
            }
          },
          "required": ["query"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_download_tracks",
        "description": "Retrieves full track records for the specified animal IDs, returning geojson content for each track.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "animal_ids": {
              "type": "array",
              "items": {"type": "string"},
              "description": "List of animal IDs to retrieve tracks for."
            },
            "format": {
              "type": "string",
              "description": "Optional output format hint (e.g., 'geojson' or 'csv'); defaults to geojson."
            }
          },
          "required": ["animal_ids"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_update_animal_notes",
        "description": "Overwrites or appends to the notes field for a specific animal.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "animal_id": {
              "type": "string",
              "description": "Target animal ID."
            },
            "notes": {
              "type": "string",
              "description": "Text to write into the animal's notes."
            },
            "mode": {
              "type": "string",
              "description": "Either 'replace' to overwrite or 'append' to add to existing notes; defaults to 'replace'."
            }
          },
          "required": ["animal_id", "notes"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_upload_track",
        "description": "Uploads a new track for an animal using GeoJSON content and registers it in the study.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "animal_id": {
              "type": "string",
              "description": "Animal ID to associate with the uploaded track."
            },
            "geojson": {
              "type": "string",
              "description": "GeoJSON FeatureCollection string of track points/segments."
            },
            "source": {
              "type": "string",
              "description": "Optional source label (e.g., 'VHF triangulation', 'GPS collar export')."
            }
          },
          "required": ["animal_id", "geojson"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_clip_and_tag_track",
        "description": "Clips a track to a provided polygon and adds a tag to the track; returns the clipped geojson and updated tags.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "track_id": {
              "type": "string",
              "description": "Track ID to modify."
            },
            "polygon_geojson": {
              "type": "string",
              "description": "GeoJSON Polygon or MultiPolygon defining the clip area."
            },
            "tag": {
              "type": "string",
              "description": "Tag to add to the track's tags list (e.g., 'pool_proximity', 'burrow_use')."
            }
          },
          "required": ["track_id", "polygon_geojson", "tag"]
        }
      }
    }
  ]
}

================================================================================
EXPLORER 2
================================================================================

--- INPUT PROMPT ---

You are an environment design expert helping to build realistic tool ecosystems for AI agents.

We are building an environment for an AI agent that will assist a user with tasks in a specific domain. You need to propose a COMPONENT (a specific service or system) and then propose tools for that component.

<environment>
A dryland research facility monitoring soil moisture, ephemeral pools, and reptile populations
</environment>

<user>
A herpetologist tracking sidewinder rattlesnake movements
</user>

<existing_components>
None (this is the first component)
</existing_components>

<task>
1. Identify a REAL component/service that would exist in this environment
   - Must be an actual service, software, or system (e.g., "Microsoft Excel", "Gmail", "Salesforce CRM", "PostgreSQL Database", "Slack")
   - NOT generic categories like "email system" - use specific real services
   - Must be plausible for this specific environment and user role
   - Should NOT duplicate existing components

   STRONGLY PREFER DOMAIN-SPECIFIC COMPONENTS:
   - Prioritize specialized software/services relevant to this specific environment and user role
   - Generic system tools (Terminal, Bash, Text Editor, File System) should only be proposed occasionally when truly essential
   - Think: What specialized tools would this specific user actually use day-to-day?
   - Examples: Instead of "Text Editor", propose "LaTeX Editor" for a researcher, "Code Editor with Linter" for a developer, "Markdown Editor" for documentation

2. Propose 3-6 tools for this component
   - You may choose any number within this range based on what makes sense for the component
   - Each tool should do ONE specific thing (Single Responsibility Principle)
   - Tools should be diverse and cover different operations for this component
   - Avoid "mega-tools" that try to do everything at once
   - Consider what the user might ask the AI agent to do with this component

   ENSURE VARIETY IN READ/WRITE OPERATIONS:
   - Include a MIX of read-only, write-only, and read-write tools
   - Read tools: Query/retrieve data without modification (e.g., list_emails, get_job_status, search_records)
   - Write tools: Create/modify/delete data (e.g., send_email, cancel_job, update_record, delete_file)
   - Read-write tools: Operations that both retrieve and modify (e.g., archive_and_summarize, process_and_update)
   - Realistic components have BOTH read and write capabilities - don't create read-only or write-only components

3. Format requirements:
   - Tool names MUST follow Python method naming (lowercase_with_underscores)
   - Tool names should indicate which component they interact with
   - Naming can be diverse: "read_excel_cell", "send_gmail", "query_salesforce_leads", "postgres_execute_query", "create_slack_channel"
   - Each tool should have clear, specific parameters (not 10+ parameters)

   DESCRIPTION STYLE: DETAILED
   - If BRIEF: Write short 1-2 sentence descriptions for all tools (e.g., "Sends an email to specified recipient.")
   - If DETAILED: Write comprehensive 3-6 sentence descriptions with behavior details, constraints, edge cases, return values
     Example: "Cancels a running SLURM job by job ID. If the job is already completed or cancelled, returns an error. Requires the job to be owned by the current user or admin privileges. Returns cancellation confirmation and final job status."
</task>

<response_format>
Respond with a JSON object in this exact format:
{
  "component_name": "Specific Real Service Name (e.g., Microsoft Excel, Gmail, Salesforce CRM)",
  "component_id": "lowercase_identifier (e.g., excel, gmail, salesforce)",
  "resources": {
    "resource_type": {
      "description": "What this resource represents",
      "fields": ["field1", "field2", "field3"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "tool_name_indicating_component",
        "description": "Clear description of what this tool does.",
        "operation_type": "read|write|read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "param_name": {
              "type": "string",
              "description": "Parameter description."
            },
            "tags": {
              "type": "array",
              "items": {"type": "string"},
              "description": "List of tags (for array parameters, MUST include 'items' field)"
            }
          },
          "required": ["param_name"]
        }
      }
    }
  ]
}

IMPORTANT:
- Component must be a REAL service/software that would be used in this environment
- Tool names must be lowercase_with_underscores
- Tool names should make it clear which component they're for (naming convention can vary)
- Each tool should be focused and specific, not a mega-tool
- Each tool MUST specify operation_type: "read", "write", or "read-write"
  * "read" = retrieves/queries data without modification
  * "write" = creates/modifies/deletes data
  * "read-write" = both retrieves and modifies in a single operation
- ARRAY PARAMETERS: If a parameter has "type": "array", you MUST include an "items" field specifying the array element type
  * Example: {"type": "array", "items": {"type": "string"}}
  * Valid item types: "string", "number", "boolean", or object schemas

RESOURCES - Keep them SIMPLE:
- Define what data/entities this component manages (e.g., for SLURM: jobs, queue; for Gmail: emails, folders)
- Use 2-5 fields per resource (MAXIMUM 5 fields, only if absolutely necessary)
- Only include ESSENTIAL fields that tools actually need to read/modify
- DO NOT include: authentication details, permissions, access levels, audit logs, metadata timestamps
- DO NOT include any date or time fields (no created_at, updated_at, timestamp, submit_time, date fields). This is critical for evaluation purposes.
- Good example: job: [job_id, status, user, partition, priority]
- Bad example: job with 20+ fields including detailed permissions, logging, authentication, etc.

CRITICAL - RESOURCES MUST CONTAIN ACTUAL READABLE CONTENT:
- Resources MUST contain a field with ACTUAL READABLE CONTENT, not just references
- Path/URL fields are allowed as OPTIONAL METADATA, but only if a content field is also present
- Good: document: [doc_id, title, content, author] where "content" is the actual text
- Good: document: [doc_id, title, file_path, content, author] where both path AND content exist
- Bad: document: [doc_id, title, file_path, author] where "file_path" is the only data (no actual content)
- Good: email: [email_id, subject, body, sender] where "body" is the actual email text
- Bad: email: [email_id, subject, attachment_url, sender] where URL is the only data (no actual content)
- Good: dataset: [dataset_id, name, data, owner] where "data" is actual data content
- Bad: dataset: [dataset_id, name, root_path, owner] where "root_path" is the only data (no actual content)
- If representing file systems or data collections, define resources as the ACTUAL FILES/ITEMS with content

TOOLS - Return FULL data by default:
- Tools should return ALL fields for ALL matching resources (e.g., list_jobs returns jobs from ALL users, not just current user)
- DO NOT implement access controls or filtering in tool descriptions
- The agent should have full read access to all resource data
- Example: "list_slurm_jobs" should return all jobs in the queue, not just the user's jobs
- Example: "search_emails" should return all matching emails, not filtered by sender/recipient

Only respond with the JSON object, nothing else.
</response_format>

--- OUTPUT ---

{
  "component_name": "Movebank",
  "component_id": "movebank",
  "resources": {
    "animal": {
      "description": "Individual animals registered in a Movebank study that can have tracks and attached sensor tags.",
      "fields": ["animal_id", "name", "species", "description"]
    },
    "track": {
      "description": "Movement track associated with an animal, represented as a GeoJSON LineString plus free-text notes.",
      "fields": ["track_id", "animal_id", "geometry", "notes"]
    },
    "sensor_tag": {
      "description": "Telemetry sensor tags that can be attached to animals for location or activity data collection.",
      "fields": ["tag_id", "animal_id", "sensor_type", "metadata"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "movebank_list_animals",
        "description": "Lists animals registered in Movebank. Optionally filters by species or a substring match on the animal name. Returns all animals that match the criteria and includes all fields for each animal. If no filters are provided, returns all animals. If no animals match, returns an empty list. Does not modify data.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "species": {
              "type": "string",
              "description": "Exact species name or code to filter animals (e.g., 'Crotalus cerastes')."
            },
            "name_query": {
              "type": "string",
              "description": "Case-insensitive substring to match in animal names."
            }
          },
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_get_tracks",
        "description": "Retrieves movement tracks from Movebank. You can filter by specific track IDs, by animal IDs, and/or by a geographic bounding box defined as [min_lon, min_lat, max_lon, max_lat]. If multiple filters are supplied, only tracks that satisfy all filters are returned. If no filters are provided, returns all tracks. Returns full records (track_id, animal_id, geometry, notes) for every matching track; does not modify data.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "track_ids": {
              "type": "array",
              "items": { "type": "string" },
              "description": "List of Movebank track IDs to retrieve."
            },
            "animal_ids": {
              "type": "array",
              "items": { "type": "string" },
              "description": "List of animal IDs to retrieve tracks for."
            },
            "bbox": {
              "type": "array",
              "items": { "type": "number" },
              "description": "Geographic bounding box [min_lon, min_lat, max_lon, max_lat] to select tracks that intersect this area."
            }
          },
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_upload_track",
        "description": "Creates a new track or updates an existing one for an animal in Movebank. If track_id is provided and exists, the geometry (GeoJSON LineString) and notes are overwritten; otherwise a new track is created and a new track_id is returned. Requires a valid animal_id and a well-formed GeoJSON LineString string for geometry. Notes can include field observations or context, and will be stored as free text. Returns the full saved track record (track_id, animal_id, geometry, notes).",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "track_id": {
              "type": "string",
              "description": "Existing track ID to update; if omitted, a new track will be created."
            },
            "animal_id": {
              "type": "string",
              "description": "Animal ID this track belongs to."
            },
            "geometry": {
              "type": "string",
              "description": "GeoJSON LineString representing the track path."
            },
            "notes": {
              "type": "string",
              "description": "Free-text notes to associate with the track."
            }
          },
          "required": ["animal_id", "geometry"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_attach_tag_to_animal",
        "description": "Attaches or reassigns a sensor tag to an animal. If the tag is currently assigned to a different animal, it will be reassigned to the provided animal_id. Metadata text is appended (not replaced) when metadata_append is provided, preserving existing content and adding the new information separated clearly. Sensor_type is not altered by this operation. Returns the full updated sensor_tag record (tag_id, animal_id, sensor_type, metadata).",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "tag_id": {
              "type": "string",
              "description": "Identifier of the sensor tag to attach."
            },
            "animal_id": {
              "type": "string",
              "description": "Animal ID to attach the tag to."
            },
            "metadata_append": {
              "type": "string",
              "description": "Additional metadata text to append to the tag record (e.g., harness type, placement notes)."
            }
          },
          "required": ["tag_id", "animal_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "movebank_summarize_and_flag_outliers",
        "description": "Analyzes a single track's geometry to flag likely spatial outliers and appends a summary to the track's notes. Outliers are identified using geometric heuristics such as segments exceeding a maximum step length and/or sharp turns below a minimum turn angle threshold. The tool reads the existing track, computes a summary (e.g., total path length, number of vertices, number of flagged segments), appends this summary and any flagged observations to notes, and saves the updated track. If thresholds are not provided, sensible defaults are used. Returns the full updated track record (track_id, animal_id, geometry, notes).",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "track_id": {
              "type": "string",
              "description": "The track to analyze and annotate."
            },
            "max_step_length": {
              "type": "number",
              "description": "Maximum allowed segment length (in meters) before a segment is flagged as a potential outlier."
            },
            "min_turn_angle": {
              "type": "number",
              "description": "Minimum turn angle (in degrees) to flag acute directional changes as potential outliers."
            }
          },
          "required": ["track_id"]
        }
      }
    }
  ]
}

