================================================================================
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 cryogenic materials testing facility measuring critical temperatures and magnetic levitation
</environment>

<user>
A physicist developing room-temperature superconductors
</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": "Quantum Design MultiVu",
  "component_id": "multivu",
  "resources": {
    "experiment": {
      "description": "An experimental run configured and managed by MultiVu (e.g., temperature/field sweeps, VSM measurements).",
      "fields": ["experiment_id", "name", "status", "sequence", "results_summary"]
    },
    "dataset": {
      "description": "A data artifact created by MultiVu from an experiment (e.g., R(T), M(H) data), containing the actual measured values.",
      "fields": ["dataset_id", "name", "content", "source_experiment_id"]
    },
    "instrument_state": {
      "description": "Current state of the PPMS/MPMS system as reported by MultiVu.",
      "fields": ["state_id", "status_report", "temperature_setpoint", "field_setpoint"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "multivu_get_instrument_state",
        "description": "Retrieves the current state of the instrument as reported by MultiVu. Returns a single instrument_state resource with a human-readable status_report (including present temperature, field, chamber state) and the active temperature_setpoint and field_setpoint. If the system is mid-ramp or executing a sequence, the status_report reflects transient conditions. Returns all instrument_state fields by default.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {},
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_list_experiments",
        "description": "Lists all experiments known to MultiVu, including queued, running, completed, and failed runs. Returns all fields for each experiment, including the full sequence text and results_summary if present. Useful for discovering experiment IDs, checking statuses, and reviewing prior sequences.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {},
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_get_dataset",
        "description": "Fetches a dataset by dataset_id and returns the complete dataset resource. The content field contains the actual measured data (e.g., delimited text or JSON with temperature, field, and measurement columns). If the dataset_id does not exist, returns an error; otherwise returns all fields including the source_experiment_id linkage.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "dataset_id": {
              "type": "string",
              "description": "Identifier of the dataset to retrieve."
            }
          },
          "required": ["dataset_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_queue_experiment",
        "description": "Creates a new experiment record in MultiVu and adds it to the queue. Provide a descriptive name and a valid MultiVu sequence (text) that defines temperature/field steps and measurement modules (e.g., VSM, transport). Returns the created experiment with all fields populated. If the sequence text is invalid or unparsable, returns an error and does not create the experiment.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "name": {
              "type": "string",
              "description": "Human-readable name for the experiment."
            },
            "sequence": {
              "type": "string",
              "description": "MultiVu sequence script text defining the procedure."
            }
          },
          "required": ["name", "sequence"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_update_setpoints",
        "description": "Updates the instrument's temperature and/or magnetic field setpoints in MultiVu. If one of the setpoints is omitted, the existing value remains unchanged. The command requests the controller to ramp to the new setpoints using current ramp settings; if the system is busy with a running experiment, this may be rejected. Returns the updated instrument_state including the new setpoints and a status_report reflecting any active ramps.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "temperature_setpoint": {
              "type": "number",
              "description": "Target temperature setpoint in kelvin."
            },
            "field_setpoint": {
              "type": "number",
              "description": "Target magnetic field setpoint in tesla."
            }
          },
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_run_experiment_and_fetch_data",
        "description": "Starts a queued experiment by experiment_id and, upon completion, returns the final experiment (all fields) and all produced datasets with full content. If the experiment is not in a runnable state (e.g., already running or completed), returns an error. If the instrument becomes busy or a safety interlock triggers, the experiment halts and the final status is 'failed' with a results_summary explaining the condition. This operation modifies state (starts the run) and also retrieves the resulting data, making it read-write.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "experiment_id": {
              "type": "string",
              "description": "Identifier of the queued experiment to start."
            }
          },
          "required": ["experiment_id"]
        }
      }
    }
  ]
}

================================================================================
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 cryogenic materials testing facility measuring critical temperatures and magnetic levitation
</environment>

<user>
A physicist developing room-temperature superconductors
</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": "Quantum Design MultiVu",
  "component_id": "multivu",
  "resources": {
    "dataset": {
      "description": "Measured data files produced by PPMS/MultiVu runs.",
      "fields": ["dataset_id", "name", "data", "sample_label"]
    },
    "sequence": {
      "description": "Automated MultiVu experiment sequences (temperature/field steps).",
      "fields": ["sequence_id", "name", "steps", "notes"]
    },
    "instrument_state": {
      "description": "Current PPMS subsystem status and setpoints as reported by MultiVu.",
      "fields": ["state_id", "mode", "status_text", "setpoints"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "multivu_get_instrument_state",
        "description": "Retrieves current PPMS/MultiVu status including mode, status text, and setpoints.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {},
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_list_datasets",
        "description": "Lists all recorded datasets with full data content and sample labels.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "name_contains": {
              "type": "string",
              "description": "Optional substring to filter dataset names."
            },
            "sample_label": {
              "type": "string",
              "description": "Optional exact sample label to filter datasets."
            }
          },
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_create_sequence",
        "description": "Creates a new MultiVu sequence with ordered steps for temperature/field control.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "name": {
              "type": "string",
              "description": "Human-readable sequence name."
            },
            "steps": {
              "type": "array",
              "items": { "type": "string" },
              "description": "Ordered step definitions (e.g., 'SET T=20K RATE=1', 'FIELD 1T')."
            },
            "notes": {
              "type": "string",
              "description": "Optional notes describing the purpose or sample."
            }
          },
          "required": ["name", "steps"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_start_sequence",
        "description": "Starts an existing MultiVu sequence and returns any datasets produced upon completion.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "sequence_id": {
              "type": "string",
              "description": "Identifier of the sequence to run."
            },
            "save_name": {
              "type": "string",
              "description": "Optional base name for saved datasets."
            }
          },
          "required": ["sequence_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_set_temperature_setpoint",
        "description": "Sets the PPMS temperature setpoint with an optional ramp rate and control mode.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "temperature_k": {
              "type": "number",
              "description": "Target temperature in kelvin."
            },
            "ramp_rate_k_per_min": {
              "type": "number",
              "description": "Optional ramp rate in K/min."
            },
            "control_mode": {
              "type": "string",
              "description": "Optional control mode (e.g., 'fast', 'no_overshoot')."
            }
          },
          "required": ["temperature_k"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_run_temperature_sweep_and_save",
        "description": "Performs a temperature sweep (optional fixed field) and saves the resulting dataset.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "start_k": {
              "type": "number",
              "description": "Starting temperature in kelvin."
            },
            "end_k": {
              "type": "number",
              "description": "Ending temperature in kelvin."
            },
            "rate_k_per_min": {
              "type": "number",
              "description": "Ramp rate in K/min."
            },
            "field_t": {
              "type": "number",
              "description": "Optional magnetic field in tesla to hold during the sweep."
            },
            "dataset_name": {
              "type": "string",
              "description": "Name to store the resulting dataset under."
            }
          },
          "required": ["start_k", "end_k", "rate_k_per_min", "dataset_name"]
        }
      }
    }
  ]
}

================================================================================
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 cryogenic materials testing facility measuring critical temperatures and magnetic levitation
</environment>

<user>
A physicist developing room-temperature superconductors
</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": "Quantum Design MultiVu",
  "component_id": "multivu",
  "resources": {
    "measurement": {
      "description": "Individual PPMS/MPMS measurement records controlled by MultiVu, including configuration and acquired data.",
      "fields": ["measurement_id", "status", "mode", "configuration", "data"]
    },
    "sequence": {
      "description": "Saved MultiVu sequence definitions containing ordered instrument commands and parameters.",
      "fields": ["sequence_id", "name", "steps"]
    },
    "sample": {
      "description": "Cataloged material samples associated with measurements and notes.",
      "fields": ["sample_id", "label", "composition", "notes"]
    }
  },
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "multivu_list_measurements",
        "description": "Lists MultiVu measurements currently known to the system. Returns all fields for all measurements that match optional filters. If no filters are provided, it returns every measurement record, regardless of user ownership. Status may include queued, running, completed, or aborted; mode may include resistivity, magnetization, or levitation_height. This call does not modify any records and is safe to use for broad overviews.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "status": {
              "type": "string",
              "description": "Optional status filter (e.g., queued, running, completed, aborted)."
            },
            "mode": {
              "type": "string",
              "description": "Optional mode filter (e.g., resistivity, magnetization, levitation_height)."
            }
          },
          "required": []
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_get_measurement_data",
        "description": "Retrieves a single measurement by ID, including configuration and full data content. Useful for fetching raw curves (e.g., resistivity vs. temperature, levitation height vs. temperature) for analysis. If the measurement is still running or queued, the current data buffer is returned as-is; no lock is taken and the data may be incomplete. Returns an error if the ID does not correspond to any known measurement.",
        "operation_type": "read",
        "parameters": {
          "type": "object",
          "properties": {
            "measurement_id": {
              "type": "string",
              "description": "The unique identifier of the measurement to retrieve."
            }
          },
          "required": ["measurement_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_submit_temperature_sweep",
        "description": "Submits a new temperature sweep measurement to MultiVu with specified bounds and field. Creates a measurement record and queues it immediately; the configuration text summarizes the sweep range, magnetic field, mode, and step size. Mode accepts resistivity, magnetization, or levitation_height; values outside instrument limits are clamped to safe ranges and reflected in the returned configuration. If start and end temperatures are identical, or step_size is non-positive, the submission is rejected. Returns the full created measurement with status queued and empty or initial data content.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "sample_id": {
              "type": "string",
              "description": "Associated sample identifier to link the run with a specific material."
            },
            "start_temp": {
              "type": "number",
              "description": "Starting temperature in Kelvin."
            },
            "end_temp": {
              "type": "number",
              "description": "Ending temperature in Kelvin."
            },
            "field_tesla": {
              "type": "number",
              "description": "Applied magnetic field in Tesla (will be clamped to magnet limits if needed)."
            },
            "mode": {
              "type": "string",
              "description": "Measurement mode: resistivity, magnetization, or levitation_height."
            },
            "step_size": {
              "type": "number",
              "description": "Temperature step size in Kelvin for the sweep (must be > 0)."
            },
            "excitation_current_ma": {
              "type": "number",
              "description": "Optional excitation current in mA (used for resistivity mode only)."
            }
          },
          "required": ["sample_id", "start_temp", "end_temp", "field_tesla", "mode", "step_size"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_update_sequence_steps",
        "description": "Replaces the step content of an existing MultiVu sequence. Use this to revise command order, setpoints, dwell times, or field ramps prior to execution. The provided steps string completely overwrites the existing steps; partial edits are not supported by this call. Returns the updated sequence with all fields so you can verify the changes. If the sequence_id does not exist, the operation fails without creating a new sequence.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "sequence_id": {
              "type": "string",
              "description": "Identifier of the sequence to update."
            },
            "steps": {
              "type": "string",
              "description": "Full replacement step content in MultiVu sequence format."
            }
          },
          "required": ["sequence_id", "steps"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_abort_measurement",
        "description": "Attempts to abort a running or queued MultiVu measurement by ID. If the measurement is already completed or previously aborted, no changes are made and the final status is returned. Hardware will be brought to a safe state per MultiVu's built-in interlocks. Returns the measurement with updated status (typically aborted) and any data collected up to the abort point.",
        "operation_type": "write",
        "parameters": {
          "type": "object",
          "properties": {
            "measurement_id": {
              "type": "string",
              "description": "The unique identifier of the measurement to abort."
            },
            "reason": {
              "type": "string",
              "description": "Optional human-readable reason for aborting, appended to configuration text."
            }
          },
          "required": ["measurement_id"]
        }
      }
    },
    {
      "type": "function",
      "function": {
        "name": "multivu_analyze_tc_and_update_sample_notes",
        "description": "Reads a measurement's data to estimate a critical temperature (Tc) and appends the result to the associated sample notes. For resistivity, the method resistivity_drop estimates Tc from a chosen onset/offset criterion; for levitation_height, levitation_onset estimates Tc at the first nonzero stable height. If data are insufficient (e.g., too few points or flat/noisy signal), the call returns a diagnostic and does not modify notes. On success, returns the full updated sample and the original measurement; the sample notes gain a new entry summarizing Tc, mode, and method used. This operation both reads measurement content and writes to sample notes.",
        "operation_type": "read-write",
        "parameters": {
          "type": "object",
          "properties": {
            "measurement_id": {
              "type": "string",
              "description": "Measurement whose data will be analyzed for Tc."
            },
            "sample_id": {
              "type": "string",
              "description": "Sample to annotate with Tc results."
            },
            "method": {
              "type": "string",
              "description": "Tc estimation method: resistivity_drop or levitation_onset."
            },
            "smoothing": {
              "type": "boolean",
              "description": "Optional: apply light smoothing to reduce noise before detection."
            },
            "annotate_prefix": {
              "type": "string",
              "description": "Optional prefix to include in the sample notes before the Tc summary."
            }
          },
          "required": ["measurement_id", "sample_id", "method"]
        }
      }
    }
  ]
}

