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, Tr

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): 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): 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 supported soap calls / supported rest api http methods For "can this user query it?" / permission questions : load special access rules (present on both surfaces when the object documents access gates) For query ceilings / unsupported clauses (record caps, no ORDER BY / queryMore() / OFFSET ): load limitations — present only on objects that impose them Skip by default : wsdl segment , ispersonaccount fields Dual catalog rule (imperative — this is the one people get wrong): 1. A field can be in fields , in field reference , in both, or in neither. These are two DIFFERENT catalogs, not a superset relationship. 2. A miss in fields is NOT a "field doesn't exist" answer. Check field reference too before concluding anything — the atomic jq command above does both in one shot. 3. Filter/Sort/Group/Create/Update/Nillable properties come only from fields . A field found only in field reference has NO retrievable capability flags here — say so; don't guess. <details <summary <b Why the two catalogs differ (reference — optional reading)</b </summary fields comes from Salesforce's SOAP "Fields" table (query/DML properties: Create/Filter/Sort/Group/Update/Nillable). field reference comes from a different UI facing "Field List" table (label/length/precision/scale) that some objects document separately from the SOAP table — and it can include many fields fields never lists at all (e.g. objects with very large boolean flag catalogs, or assorted admin facing fields the SOAP table omits). Across the corpus, thousands of fields exist ONLY in field reference , and a smaller number exist only in fields . This is why a field existence answer requires checking both, and why capability questions can only be answered from fields . </details Which folder? Standard sObjects you query and modify at runtime (Account, Contact, Opportunity, Lead, Case, ...) → assets/enterprise api/ Developer / diagnostics records (ApexClass, ApexCodeCoverageAggregate, TraceFlag, EntityDefinition, MetadataComponentDependency, SymbolTable) → assets/tooling api/ Custom c objects and custom c fields → NOT in these assets. Describe the live org: sf sobject describe sobject <Name target org <alias . (A custom field like Region c on standard Account won't be in assets/enterprise api/Account.json either.) Example Queries (Section Specific) Do: "Show me only the 'fields' section from assets/enterprise api/Account.json" "What are the filterable fields on Opportunity?" "Which fields on Contact are relationships, and what do they refer to?" "What SOAP calls does ApexClass support in the Tooling API?" "Field X isn't in fields — check field reference before saying it doesn't exist" Don't: "Load Account.json" (pulls the huge wsdl segment ; load fields and field reference separately instead of the whole file) JSON File Structure Enterprise (data) sObjects live in assets/enterprise api/ ; Tooling records live in assets/tooling api/ . Both share a common core, with a few surface specific sections. fields is a dict keyed by field API name (e.g. fields["AnnualRevenue"] ), not a list — iterate with .items() / .keys() , don't index it positionally. How sections are derived (read this before assuming a section list) Each JSON file is generated from whatever Heading sections actually appear on that object's Salesforce docs page — the JSON schema is not a fixed, uniform template applied identically to every object. Two consequences follow directly from that: 1. No section is guaranteed present on every object, fields included. A section exists in a file only if the source docs page had a matching heading. Some Tooling docs pages have no fields table at all (thin/beta pages), so fields can be missing; a small number of SOAP header style pages label their field table singular ( field ) instead of plural. Always check the file's own sections array (or "fields" in sections ) before assuming a section exists — don't hard code an expectation from having looked at one or two example objects. 2. A page can carry extra sections beyond the common ones , one per additional heading Salesforce's docs used on that specific page (e.g. a nested complex type referenced by a field, like a picklist's value metadata description, or a record type info block). These are normalized into snake case keys and stored either as their own top level section, or — when the converter recognizes the heading as a distinct sub type rather than a plain content section — nested under a sub types dict keyed by the sub type's name. Treat the "Available Sections" list below as the common/frequent case, not an exhaustive enum — the authoritative list for any one object is that object's own sections array. Available Sections (common case — not exhaustive; see above) title , description , fields columns : present on essentially all objects fields : present on the large majority of objects, but see point 1 above — verify via sections rather than assuming Enterprise only : usage , associated objects , ispersonaccount fields , field reference , field reference columns Tooling only : supported soap calls , supported rest api http methods special access rules : who can query/access the object and any permission or license gate (e.g. "Customer Portal users can't access this object", "requires Omnistudio licenses"). Present on both surfaces. Read this before concluding a query will run for a given user — it's a query eligibility fact no field flag captures. limitations : query ceilings and unsupported SOQL clauses the object imposes (e.g. MetadataComponentDependency: max 2000 records via Tooling API / 100,000 via Bulk API 2.0; ORDER BY , OFFSET , queryMore() , and Name field filters are not supported). Read this before writing a query against an object that has it — these constraints are not derivable from the fields properties. wsdl segment : schema definition (verbose — skip unless you need the raw type) sub types and any other snake case named section not listed above: object specific nested schema description, present only when that object's docs page had a matching heading — inspect the file's sections array to discover them per object The fields columns array tells you which columns each object's fields entries carry — check it per object rather than assuming a fixed shape. Enterprise sObjects typically add relationship name , refers to , and relationship type ; Tooling records typically carry only type , properties , description — but a meaningful minority of Tooling objects also carry relationship type , so don't treat it as enterprise exclusive. relationship type values also have spelling variants in the source data (e.g. "Lookup" vs. "Look up" ) — compare loosely (e.g. .replace(" ", "").lower() ) rather than exact string equality. Type strings are case inconsistent across objects — do not assume a single casing. The same concept appears under multiple castings depending on the source doc page: string / String , boolean / Boolean , dateTime / DateTime / datetime . Compare type values case insensitively (e.g. .lower() ) rather than with == against one casing. Beyond the common string reference picklist types, real data also includes int , boolean , double , currency , date , dateTime , textarea , address , url , phone , email , time , anyType , base64 , and others — treat the type list as open ended. A field can lack structured type / properties even when the object otherwise has them — check description as a fallback before concluding the data is missing. Because each object's JSON is generated from

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