/platform-data-and-tooling-api-context-get

name: platform-data-and-tooling-api-context-get
description: "Authoritative field/schema reference for 2130 STANDARD Salesforce objects — use to look up standard sObject and Tooling field API names, types, properties (filterable/sortable/groupable/updateable), and relationship names for Account, Contact, Opportunity, Lead, Case, ApexClass, ApexCodeCoverage, TraceFlag, and more. Load this alongside a SOQL/query/Apex skill when the field names, types, or Filter/Sort/Group capabilities are unverified — not when the fields are already known and only query syntax or optimization is needed. TRIGGER when verifying, validating, or debugging fields in a SOQL/SOSL query or DML against a standard object — capabilities, relationship/subquery paths, or what fields an object has — so the query runs instead of guessing. Custom __c objects and __c fields are NOT in these assets; describe the live org for those (sf sobject describe). DO NOT TRIGGER for authoring/deploying *-meta.xml or sfdx source (use the Metadata API skill)."
metadata:
  version: "1.0"
  domains: ["Platform"]
  minApiVersion: "67.0"
  relatedSkills:
    - "platform-metadata-api-context-get"
  cliTools:
    - tool: ["jq"]
      semver: ">=1.6"
    - tool: ["node"]
      semver: ">=18.0.0"
    - tool: ["python3"]
      semver: ">=3.8"
    - tool: ["sf"]
      semver: ">=2.0.0"

Salesforce Data + Tooling API Skill

This skill provides field-level reference for **2130 standard Salesforce objects** across two runtime API surfaces: the **Enterprise/Data API** (standard sObjects you query with SOQL and modify with DML) and the **Tooling API** (developer/metadata-adjacent records like `ApexClass`, `ApexCodeCoverage`, `TraceFlag`, and `EntityDefinition`).

Use it to look up authoritative field names, types, and properties **before** writing SOQL/SOSL, building DML, or reading records at runtime — so queries and writes don't fail with `INVALID_FIELD` / "No such column" errors.

> **Standard objects only.** These assets cover standard sObjects and > Tooling records. Custom `__c` objects, and custom `__c` fields on standard > objects, are **not** in this corpus — they don't exist as static docs pages. > For those, describe the live org instead (`sf sobject describe --sobject <Name>`).

Overview

Each object is documented as a JSON file with:

• Field definitions: name, type, and properties (Createable, Filterable, Groupable, Nillable, Sortable, Updateable)
• Relationship metadata (relationship name, referenced object, relationship type) for enterprise sObjects
• Supported SOAP calls and REST HTTP methods for Tooling records
• WSDL schema segment
• Usage notes and associated objects (enterprise sObjects)

> **This skill is for runtime data, not deployment.** For authoring `*-meta.xml` > source files (CustomObject, Flow, Profile, ...) use the **Metadata API** skill > (`platform-metadata-api-context-get`). The two are companions, not substitutes.

How to Use This Skill

CRITICAL: Field-Existence Gate (do this BEFORE answering)

**NEVER answer a field question — "does field X exist?", "is X filterable/sortable/groupable?", "what's X's API name/type?" — from memory or training data. This includes obvious system fields like `Id`, `Name`, `CreatedDate`, `LastModifiedDate`, `OwnerId`, `IsDeleted`. ALWAYS run the lookup first.** You know these fields from training, but this skill exists precisely because your recollection of their *properties* (Filter/Sort/Group) and of which catalog documents them is unreliable. Confidence is not verification.

**Run ONE atomic command that checks BOTH catalogs at once** (a field can live in `fields`, in `field_reference`, or neither — see the dual-catalog note below):

jq '{fields: .fields["<FieldName>"], field_reference: .field_reference["<FieldName>"]}' assets/enterprise_api/<Object>.json
# e.g. checking CreatedDate on Account:
jq '{fields: .fields["CreatedDate"], field_reference: .field_reference["CreatedDate"]}' assets/enterprise_api/Account.json

Interpret the result: found in `fields` → use its `properties` for capability answers. Found only in `field_reference` → it exists, but Filter/Sort/Group **cannot** be determined from this skill (that catalog carries no property flags). `null` in both → not in this corpus (may still be a real live-org/custom field — describe the org).

**MANDATORY VERIFICATION GATE.** Before you state any field fact, you MUST first print this line verbatim in your reply to the user (like the metadata skill's status line):

field_lookup: object=<Object> field=<FieldName> checked_fields=<yes|no> checked_field_reference=<yes|no> result=<in_fields|in_field_reference|not_found>

If you cannot print this line truthfully with both checks = `yes`, you have not done the lookup — stop and run the jq command. Do not fabricate a citation like "based on the skill's data" without having run it.

This gate line is a self-verification marker for your conversational response **only** — do NOT write it into files you generate for the user (`.soql`, `.md`, `.json`, query comment headers, etc.). Deliverables should contain just the answer/query the user asked for; keep the `field_lookup:` line out of them.

CRITICAL: Section-Specific Consumption

**ALWAYS consume only the specific sections you need from JSON files, NOT entire files.**

**For `assets/enterprise_api/*.json` and `assets/tooling_api/*.json` files, always use `jq` or programmatic JSON parsing to extract only the sections you need.** Do not load these files whole via `Read`, `cat`, or `read_file` — they contain verbose `wsdl_segment` and `field_reference` sections that waste 60-80% of tokens on large sObjects like Account.

Each JSON file contains multiple sections. Most use cases only need 1-2:

• **For query/DML field lists**: load only the `fields` section
• **For relationship traversal**: load `fields` (the `relationship_name` / `refers_to` columns are inline)
• **For Tooling call support**: load `