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>
{environment_description}
</environment>

<user>
{user_description}
</user>

<existing_components>
{existing_tools}
</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 {num_tools} 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: {description_detail}
   - 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>
