Hello everyone,

I have discovered an effective method to solve the two main problems we encounter while using Jules:

1. Limitations in custom MCP usage.
2. Response delays caused by MCPs bloating the context.

Thanks to the mcp2cli tool, we can convert MCP servers, OpenAPI specifications, or GraphQL endpoints directly into CLI commands, allowing us to maintain Jules' performance without hitting usage limits or overloading the context.

File

First, to teach Jules how to use this tool, you need to save the following content as a SKILL.md file in the ./.agents/skills/mcp2cli/ folder:

---
name: mcp2cli
description: Turn any MCP server, OpenAPI spec, or GraphQL endpoint into a CLI. Use this skill when the user wants to interact with an MCP server, OpenAPI/REST API, or GraphQL API via command line, discover available tools/endpoints, call API operations, or generate a new skill from an API. Triggers include "mcp2cli", "call this MCP server", "use this API", "list tools from", "create a skill for this API", "graphql", or any task involving MCP tool invocation, OpenAPI endpoint calls, or GraphQL queries without writing code.
---

# mcp2cli

Turn any MCP server, OpenAPI spec, or GraphQL endpoint into a CLI at runtime. No codegen.

## Install

```bash
# Run directly (no install needed)
uvx mcp2cli --help

# Or install
pip install mcp2cli
```

## Core Workflow

1. **Connect** to a source (MCP server, OpenAPI spec, or GraphQL endpoint)
2. **Discover** available commands with `--list` (or filter with `--search`)
3. **Inspect** a specific command with `<command> --help`
4. **Execute** the command with flags

```bash
# MCP over HTTP
uvx mcp2cli --mcp https://mcp.example.com/sse --list
uvx mcp2cli --mcp https://mcp.example.com/sse create-task --help
uvx mcp2cli --mcp https://mcp.example.com/sse create-task --title "Fix bug"

# MCP over stdio
uvx mcp2cli --mcp-stdio "npx /server-filesystem /tmp" --list
uvx mcp2cli --mcp-stdio "npx u/modelcontextprotocol/server-filesystem /tmp" read-file --path /tmp/hello.txt

# OpenAPI spec (remote or local, JSON or YAML)
uvx mcp2cli --spec https://petstore3.swagger.io/api/v3/openapi.json --list
uvx mcp2cli --spec ./openapi.json --base-url https://api.example.com list-pets --status available

# GraphQL endpoint
uvx mcp2cli --graphql https://api.example.com/graphql --list
uvx mcp2cli --graphql https://api.example.com/graphql users --limit 10
uvx mcp2cli --graphql https://api.example.com/graphql create-user --name "Alice"
```

## CLI Reference

```
mcp2cli [global options] <subcommand> [command options]

Source (mutually exclusive, one required):
  --spec URL|FILE       OpenAPI spec (JSON or YAML, local or remote)
  --mcp URL             MCP server URL (HTTP/SSE)
  --mcp-stdio CMD       MCP server command (stdio transport)
  --graphql URL         GraphQL endpoint URL

Options:
  --auth-header K:V       HTTP header (repeatable, value supports env:/file: prefixes)
  --base-url URL          Override base URL from spec
  --transport TYPE        MCP HTTP transport: auto|sse|streamable (default: auto)
  --env KEY=VALUE         Env var for stdio server process (repeatable)
  --oauth                 Enable OAuth (authorization code + PKCE flow)
  --oauth-client-id ID    OAuth client ID (supports env:/file: prefixes)
  --oauth-client-secret S OAuth client secret (supports env:/file: prefixes)
  --oauth-scope SCOPE     OAuth scope(s) to request
  --cache-key KEY         Custom cache key
  --cache-ttl SECONDS     Cache TTL (default: 3600)
  --refresh               Bypass cache
  --list                  List available subcommands
  --search PATTERN        Search tools by name or description (implies --list)
  --fields FIELDS         Override GraphQL selection set (e.g. "id name email")
  --pretty                Pretty-print JSON output
  --raw                   Print raw response body
  --toon                  Encode output as TOON (token-efficient for LLMs)
  --head N                Limit output to first N records (arrays)
  --version               Show version
```

Subcommands and flags are generated dynamically from the source.

## Patterns

### Authentication

**Always use `env:` or `file:` prefixes for secrets** — never pass credentials as literal values in CLI flags.

```bash
# Secret from environment variable
uvx mcp2cli --spec ./spec.json --auth-header "Authorization:env:API_TOKEN" list-items
```

### Tool search

```bash
uvx mcp2cli --mcp https://mcp.example.com/sse --search "task"
```

## Generating a Skill from an API

When the user asks to create a skill from an MCP server, OpenAPI spec, or GraphQL endpoint, follow this workflow:

1. **Discover** all available commands:
   ```bash
   uvx mcp2cli --mcp https://target.example.com/sse --list
   ```

2. **Inspect** each command to understand parameters:
   ```bash
   uvx mcp2cli --mcp https://target.example.com/sse <command> --help
   ```

3. **Test** key commands and probe for edge cases.

4. **Create a SKILL.MD** in `./.agents/skills/myapi_command/` that teaches another AI agent how to use this specific command. **Each command should have its own separate skill.** Note: The SKILL.md must go beyond `--help` output — focus on knowledge that can only be learned through testing and reading documentation.

   **Frontmatter:**
   ```yaml
   ---
   name: myapi_command
   description: Use the myapi service to perform command
   ---
   ```

   **Core Workflow** (use direct uvx mcp2cli calls):
   ```bash
   # Get help for the command
   uvx mcp2cli --mcp https://target.example.com/sse command --help
   # Run the command
   uvx mcp2cli --mcp https://target.example.com/sse command --param value --pretty
   ```

   **Before Querying** checklist — include a decision framework:
   - What dataset/resource am I targeting?
   - Do I need pagination (`--offset`, `--limit`)?
   - Are there fields that produce large output I should exclude or truncate (`--head`)?

   **Anti-Patterns & Gotchas** — document every surprise found during testing.

   **Output Processing** — use `--pretty` for readable JSON, `--head` to limit results, or pipe to `jq`.

   **Knowledge Delta Principle:** Do not duplicate parameter listings from `--help`. Instead, document which parameters actually matter for common tasks, default behaviors that are surprising, combinations that don't work, and rate limits or response size limits.

Each skill focuses on a single command for modularity and uses direct `mcp2cli` calls to interact with the API.

To instruct Jules to create a new skill, simply enter the following command into the message panel:

>mcp2cli create a skill for https://mcp.deepwiki.com/mcp — generate a skill from Mcp remote HTTP url

When you enter this command, Jules will use the mcp2cli capability to scan all tools at the target URL and generate separate SKILL.md files for each tool. This allows you to add the necessary capabilities to Jules in a modular way without bloating the context or hitting usage limits.

By using this method, we can expand Jules' capabilities while preventing the system from becoming sluggish. I highly recommend trying this if you are experiencing similar issues in your projects.

You can find all the details about the tool on GitHub.

Hi everyone,

I like to keep my Ubuntu system clean, but over time, I've accumulated applications that I installed but no longer use. To free up disk space and keep my system organized, I want to identify and remove these "unused applications."

The biggest challenge I'm facing is that there isn't any centralized data showing when an application was last opened or used. In Ubuntu, accessing this information seems quite difficult.

I would like to ask you the following:

• Do you know of any GUI (Graphical User Interface) application that lists my installed apps and displays their "last used date"?
• If such a GUI application doesn't exist, what is the most practical way to access this data (last usage date) via the terminal?

I look forward to your suggestions for methods or tools that will help me easily identify and remove applications that are taking up unnecessary space on my system.

Thanks in advance for your valuable answers!

Hi everyone,

I’ve been working with Jules for a while, and I’ve finally managed to build a "self-discovering" architecture for managing agent capabilities. Now, Jules can dynamically discover which skills are available before starting any task.

At the heart of the system lies the "MANDATORY" rule within AGENTS.md and the "Skill Discovery Tool" structure provided by SKILLS.md. Feel free to review it and let me know your feedback.

-AGENTS.md:

# AGENTS.md

## Skills

This project has task-specific skills available.

> **MANDATORY:** Before writing any code, creating any file, or running any command,
> you **MUST** first read `SKILLS.md` and check for relevant skills.
> This step is **non-negotiable** and applies to **every task** without exception.

**Steps to follow before any task:**
1. `view SKILLS.md` — discover all available skills
2. `view` every skill file that is plausibly relevant to the task
3. Only then proceed with the task

Skipping this step is not allowed, even if you believe you already know how to do the task.
Skills encode environment-specific constraints that override general knowledge.

- SKILLS.md:

# SKILLS.md — Skill Discovery Tool

## Purpose

This file enables the agent to dynamically discover available skills in the project.
If the agent doesn't know which skills exist before starting a task,
it must run the command below to get the current skill list.

---

## Getting the Skill List

Run the following command to list all skills in the project:

```bash
uvx --from skills-cli skills to-prompt ./.agents/skills/* --format yaml
```

### Example Output

```yaml
available_skills:
  - name: data-analysis
    description: Used for reading, analyzing, and summarizing CSV, JSON, and tabular data.
    location: /content/.agents/skills/data-analysis/SKILL.md
  - name: pdf-reader
    description: Used when text or tables need to be extracted from PDF files.
    location: /content/.agents/skills/pdf-reader/SKILL.md
  - name: code-reviewer
    description: Used to evaluate code quality, security, and best practice compliance.
    location: /content/.agents/skills/code-reviewer/SKILL.md
```

### Output Fields

| Field         | Description                                                        |
|---------------|--------------------------------------------------------------------|
| `name`        | Short identifier for the skill                                     |
| `description` | What the skill does and when it should be used                     |
| `location`    | Full path to the skill's SKILL.md — read this file before using it |

---

## Skill Usage Flow

```
1. Agent doesn't know which skills are needed for the task
         ↓
2. Run the command above to get the available_skills list
         ↓
3. Read the description fields to identify the right skill
         ↓
4. Read the SKILL.md file at the skill's location path
         ↓
5. Complete the task following the instructions in SKILL.md
```

---

## Rules

- **Always discover first:** If you don't know the available skills, run the command — don't assume.
- **Read description carefully:** The `description` field determines which skill to use.
- **Read from location:** Always read the SKILL.md at the `location` path before using a skill.
- **Multiple skills:** If the task requires more than one skill, read all relevant SKILL.md files.
- **No skill found:** If no suitable skill exists, proceed with your general knowledge and note it.Hi everyone,I’ve been working with Jules for a while, and I’ve finally managed to build a "self-discovering" architecture for managing agent capabilities. Now, Jules can dynamically discover which skills are available before starting any task.At the heart of the system lies the "MANDATORY" rule within AGENTS.md and the "Skill Discovery Tool" structure provided by SKILLS.md. Feel free to review it and let me know your feedback.# AGENTS.md

## Skills

This project has task-specific skills available.

> **MANDATORY:** Before writing any code, creating any file, or running any command,
> you **MUST** first read `SKILLS.md` and check for relevant skills.
> This step is **non-negotiable** and applies to **every task** without exception.

**Steps to follow before any task:**
1. `view SKILLS.md` — discover all available skills
2. `view` every skill file that is plausibly relevant to the task
3. Only then proceed with the task

Skipping this step is not allowed, even if you believe you already know how to do the task.
Skills encode environment-specific constraints that override general knowledge.
# SKILLS.md — Skill Discovery Tool

## Purpose

This file enables the agent to dynamically discover available skills in the project.
If the agent doesn't know which skills exist before starting a task,
it must run the command below to get the current skill list.

---

## Getting the Skill List

Run the following command to list all skills in the project:

```bash
uvx --from skills-cli skills to-prompt ./.agents/skills/* --format yaml
```

### Example Output

```yaml
available_skills:
  - name: data-analysis
    description: Used for reading, analyzing, and summarizing CSV, JSON, and tabular data.
    location: /content/.agents/skills/data-analysis/SKILL.md
  - name: pdf-reader
    description: Used when text or tables need to be extracted from PDF files.
    location: /content/.agents/skills/pdf-reader/SKILL.md
  - name: code-reviewer
    description: Used to evaluate code quality, security, and best practice compliance.
    location: /content/.agents/skills/code-reviewer/SKILL.md
```

### Output Fields

| Field         | Description                                                        |
|---------------|--------------------------------------------------------------------|
| `name`        | Short identifier for the skill                                     |
| `description` | What the skill does and when it should be used                     |
| `location`    | Full path to the skill's SKILL.md — read this file before using it |

---

## Skill Usage Flow

```
1. Agent doesn't know which skills are needed for the task
         ↓
2. Run the command above to get the available_skills list
         ↓
3. Read the description fields to identify the right skill
         ↓
4. Read the SKILL.md file at the skill's location path
         ↓
5. Complete the task following the instructions in SKILL.md
```

---

## Rules

- **Always discover first:** If you don't know the available skills, run the command — don't assume.
- **Read description carefully:** The `description` field determines which skill to use.
- **Read from location:** Always read the SKILL.md at the `location` path before using a skill.
- **Multiple skills:** If the task requires more than one skill, read all relevant SKILL.md files.
- **No skill found:** If no suitable skill exists, proceed with your general knowledge and note it.

Hello,

I have a few questions regarding the most efficient way to structure my work while using Jules Agent. I would appreciate any insights from experienced users or developers on the following:

1. Can a "Skills" folder be defined?

Is it possible to create a separate folder named Skills to group all my skills together while using Jules Agent? Or must each Skill definition be specified individually within knowledge?

2. Using AGENTS.md within the Repo

Can we define a file like AGENTS.md within the repository to ensure the agent follows specific rules or definitions during prompt execution?

• Scenario A: Does the agent automatically read this specific file in the repository and process prompts accordingly?
• Scenario B: Or should this configuration also be specified within knowledge?
• Scenario C: Or do we need to manually specify these rules during every prompt execution?

If there is support for repository-based configuration files, or if using knowledge is the best practice for such definitions, please let me know.

Thank you in advance!