oauth:
  token_url: https://example.adb.us-chicago-1.oraclecloudapps.com/ords/demo/oauth/token
  scopes: ""

services:

id: jd_sb_entries
name: JD Second Brain Tasks, Notes, and Reminders
base_url: https://example.adb.us-chicago-1.oraclecloudapps.com/ords/demo/mcp/
description: "Manage second-brain entries from natural user requests. Use this service when the user wants to add, create, save, list, review, update, or delete notes, tasks, ideas, knowledge entries, or reminder-style entries with a due date. Create new entries at jd_sb_entries and update or delete existing entries at jd_sb_entries/{entry_id}. This stores reminders as second-brain tasks or notes; it does not create real Planner or calendar reminders. Infer the correct action from conversational requests whenever possible."
default_headers:
  Accept: application/json
timeout_seconds: 30
pagination:
  default_page_size: 100
  max_page_size: 250
  max_pages_per_call: 10
  max_items_per_call: 500
examples:

"Use rest_mcp_server to add a todo for tomorrow: clean car."
Add a new task reminding me to review the ORDS spec tomorrow.
Save a reminder for tomorrow to review the ORDS spec.
Create a note about MCP server pagination and save the full details.
"Add this to my second brain: review the ORDS spec tomorrow."
Show me my second-brain entries.
Update entry 123 to mark it high urgency.
Delete entry 456.
columns:
name: entry_id
data_type: NUMBER
nullable: false
writable: false
description: Primary key identity column.
name: subject
data_type: VARCHAR2(255)
nullable: false
writable: true
description: Short subject line.
name: entry_type
data_type: VARCHAR2(30)
nullable: false
writable: true
description: Entry classification.
enum_values:

IDEA
TASK
NOTE
KNOWLEDGE


name: ai_summary
data_type: VARCHAR2(32767)
nullable: false
writable: true
description: AI-generated summary.
name: user_content
data_type: CLOB
nullable: false
writable: true
description: Full entry body.
name: urgency
data_type: VARCHAR2(30)
nullable: true
writable: true
description: Optional urgency.
enum_values:

LOW
MEDIUM
HIGH


name: action_required
data_type: VARCHAR2(1)
nullable: false
writable: true
description: Whether action is required.
enum_values:

Y
N


name: due_date
data_type: DATE
nullable: true
writable: true
description: Optional due date in YYYY-MM-DD format.

---
name: "second-brain"
description: "Use when the user wants to add, update, list, or delete second-brain notes, tasks, ideas, knowledge items, or reminder-style entries through the local rest-mcp server. Prefer this skill when the user explicitly says $second-brain."
---

Second Brain
Use this skill for second-brain CRUD work through the local rest-mcp MCP server.
Core Rules

Use service_id: "jd_sb_entries".
Use path: "jd_sb_entries" for create and list. Use path: "jd_sb_entries/{entry_id}" for a specific row.
For filtered GET requests, use ORDS q filter syntax, not ad hoc column query params.
Preferred form: pass query as a native object and pass query.q as a native object. The MCP server will JSON-encode q.
Accepted alternate form: pass query as a raw query string such as q={"entry_type":{"$eq":"TASK"}}&limit=25.
Do not send second-brain filters as top-level keys like "entry_type": "TASK" unless the service explicitly documents that parameter.
For structured arguments, verify body and headers are native objects before calling the tool. For query, prefer a native object unless a raw query string is more direct.
Use page_limit and item_limit for pagination.
If fields, enum values, or filter keys are unclear, call rest-mcp.describe_service once. Do not retry blindly with alternate query formats.
Use ORDS operators inside q as needed: \(eq, \)ne, \(instr, \)like, \(gte, \)lte, \(or, \)and.
Keep list results compact and results-focused.
Never paste raw MCP response JSON into the user-facing reply. Extract the needed fields and summarize.

Fixed Playbooks

If the user asks to show, list, pull, or review active todos/tasks/reminders, make exactly one GET call with:

{
  "service_id": "jd_sb_entries",
  "method": "GET",
  "path": "jd_sb_entries",
  "query": {
    "q": {
      "entry_type": {
        "$eq": "TASK"
      },
      "action_required": {
        "$eq": "Y"
      }
    }
  },
  "page_limit": "1",
  "item_limit": "25"
}


For that active-task flow, do not probe with alternative query formats, do not call describe_service, and do not say "retrying" unless an unexpected runtime error actually occurred.
After fetching active tasks, sort by due_date ascending before replying unless the user asks for a different order.
Reply with only the compact task list: #entry_id subject — due YYYY-MM-DD.

Batch Rules

Default to single-item mode.
Enter batch mode only when the user clearly asks for multiple items or refers to a concrete earlier list.
For prior-thread items, restate a compact working list in the current turn before writing.
If the earlier items are missing or ambiguous, ask the user to narrow the scope or restate them.
Process at most 5 items per turn unless the user explicitly asks for more.
Create or update sequentially, one request_resource call per item.
If a batch partially succeeds, report completed items and the first failure clearly.

Field Mapping

todo, task, reminder -> entry_type: "TASK"
note -> entry_type: "NOTE"
idea -> entry_type: "IDEA"
knowledge -> entry_type: "KNOWLEDGE"
For todos/reminders, default action_required to "Y".
Default urgency to "LOW" unless the user says otherwise.
Use title case for subject unless the user specifies exact casing.
Use the raw user text or a slightly cleaned version for user_content.
Create a short ai_summary from the request.
Convert relative dates like tomorrow into an absolute YYYY-MM-DD date using the user's locale timezone.
Treat returned due_date values as ISO timestamps and present them back to the user as dates when only the date matters.

Request Patterns
Create:
{
  "service_id": "jd_sb_entries",
  "method": "POST",
  "path": "jd_sb_entries",
  "body": {
    "subject": "Clean car",
    "entry_type": "TASK",
    "ai_summary": "Reminder to clean the car tomorrow.",
    "user_content": "clean car",
    "urgency": "LOW",
    "action_required": "Y",
    "due_date": "2026-03-15"
  }
}

List active tasks:
{
  "service_id": "jd_sb_entries",
  "method": "GET",
  "path": "jd_sb_entries",
  "query": {
    "q": {
      "entry_type": {
        "$eq": "TASK"
      },
      "action_required": {
        "$eq": "Y"
      }
    }
  },
  "page_limit": "1",
  "item_limit": "25"
}

Search for entries containing a phrase:
{
  "service_id": "jd_sb_entries",
  "method": "GET",
  "path": "jd_sb_entries",
  "query": {
    "q": {
      "$or": [
        {
          "subject": {
            "$instr": "ORDS"
          }
        },
        {
          "user_content": {
            "$instr": "ORDS"
          }
        }
      ]
    }
  },
  "page_limit": "1",
  "item_limit": "25"
}

Read one row:
{
  "service_id": "jd_sb_entries",
  "method": "GET",
  "path": "jd_sb_entries/32"
}

Bad query examples:
"query": {
  "entry_type": "TASK",
  "action_required": "Y"
}

"query": "{\"entry_type\":{\"$eq\":\"TASK\"}}"

Good raw query-string example:
"query": "q={\"entry_type\":{\"\(eq\":\"TASK\"},\"action_required\":{\"\)eq\":\"Y\"}}&limit=25"

Response Style

For simple creates, reply with the created entry_id, subject, and due date.
For list/read requests, return the concise result only. Do not echo tool payloads, headers, links, or pagination blobs.
Keep the response short.
If the request is ambiguous, ask one concise clarifying question.