Anything CLI documentation

2. Install and build

Requirements: Rust (stable), Node.js 18+ (for MCP server), and credentials for the sources you want to query.

git clone https://github.com/AnythingGraph/anything-cli.git
cd anything-cli

cargo build --release
cd mcp && npm install && cd ..

Set environment variables for your sources, then start both services. The variables below include demo-only entries for the sample CRM and payroll files — use only what matches your setup:

export AG_SQL_DSN="postgres://user:pass@localhost:5432/yourdb"
export AG_PAYROLL_CSV_PATH="$(pwd)/data/payroll.csv"
export AG_SF_INSTANCE_URL="https://your-org.my.salesforce.com"
export AG_SF_ACCESS_TOKEN="your_access_token"

chmod +x start-all.sh
./start-all.sh

Validate playbooks:

cargo run -p anythinggraph-ag -- validate --playbooks playbooks

Print MCP config snippet for Cursor:

cargo run -p anythinggraph-ag -- mcp-config

3. Core concepts

Anything CLI separates what you mean from where data lives and who may see it.

Not moving your data means:

• No ETL pipeline required to “feed” the agent.
• Each query runs at the source via the adapter (SQL, SOQL, file read).
• Federated playbooks can touch Postgres and CSV in one user question — still no copy step.

Query flow:

1. Agent calls query_graph with a playbook id and a question shape (resolve user, count relationship, …).
2. Runtime compiles a plan from the playbook.
3. Runtime picks the binding from entity_sources + bindings.
4. Adapter executes at the source; optional ReBAC filters results.
5. Proof envelope returns counts, rows, and evidence.

4. What is a playbook?

A playbook (playbooks/<id>.json) is a portable description of a use case in your domain — who may see what, and how concepts connect. The repo ships demo playbooks; you author new ones for your business.

Step-by-step guide: create a playbook and binding →

Demo playbooks included in the repo (not prescriptive — copy and adapt):

• simple-crm-access — Postgres CRM (user → owned accounts)
• crm-payroll-access — Postgres CRM + payroll CSV (federated)
• salesforce-lead-access — Salesforce User + Lead

Example JSON

// Demo playbook shape — crm-payroll-access (illustrative only)
{
  "id": "crm-payroll-access",
  "entities": [ { "name": "crm_user", "fields": [...] }, ... ],
  "entity_relationships": [
    { "relationship_name": "owns_account", "subject_entity_name": "crm_user", "object_entity_name": "crm_account" }
  ],
  "entity_sources": {
    "crm_user": "postgres",
    "crm_account": "postgres",
    "crm_payroll_record": "csv"
  },
  "bindings": {
    "postgres": "crm-payroll-access.postgres",
    "csv": "crm-payroll-access.csv"
  }
}

5. What is a binding?

A binding (bindings/<playbook_id>.<source>.yaml) connects playbook vocabulary to physical storage for one source. One playbook often has multiple binding files. See the playbooks & bindings guide for Postgres, CSV, and Salesforce examples.

Example YAML

# Demo binding — maps the example playbook to one Postgres source
adapter: sql
playbook_id: crm-payroll-access
source_id: warehouse_pg

entities:
  crm_user:
    from: users
    id_field: user_id
    fields:
      user_id: user_id
      full_name: full_name

relationships:
  owns_account:
    join:
      from_entity: crm_user
      to_entity: crm_account
      on: "accounts.owner_user_id = users.user_id"
    subject_link_column: owner_user_id

• from — table, file, or Salesforce object name
• fields — playbook field → physical column (left = logical, right = physical)
• subject_link_column — on the object side, column linking back to the subject id

You usually do not write SQL by hand. With from, id_field, fields, and subject_link_column, the runtime compiles lookup, count, list, and ReBAC list_all queries at load time.

6. Profiles

Profiles (profiles/local.yaml) register named sources. Bindings reference them via source_id. Credentials never go in playbooks or bindings.

Example profile

# Demo sources — rename keys and env vars for your environment
sources:
  warehouse_pg:
    adapter: sql
    dsn: env:AG_SQL_DSN
  mysql_main:
    adapter: mysql
    dsn: env:AG_MYSQL_DSN
  mssql_main:
    adapter: mssql
    dsn: env:AG_MSSQL_DSN
  mongodb_main:
    adapter: mongodb
    dsn: env:AG_MONGODB_URI
    database: env:AG_MONGODB_DATABASE
  rest_api:
    adapter: rest
    base_url: env:AG_REST_BASE_URL
    auth: env:AG_REST_TOKEN
  payroll_csv:
    adapter: csv
    file_path: env:AG_PAYROLL_CSV_PATH
  salesforce_main:
    adapter: soql
    instance_url: env:AG_SF_INSTANCE_URL
    auth: env:AG_SF_ACCESS_TOKEN

Values prefixed with env: are resolved from environment variables at startup. Override the profile path with AG_PROFILE_PATH.

7. Data adapters

Adapters implement a common interface: execute plan steps and load entity rows for ReBAC graph materialization. Each profile entry sets adapter: to pick the implementation. Seven adapters ship today; more are on the roadmap — same playbook model, different backends.

Binding patterns for newer adapters:

• mysql / mssql — same YAML shape as Postgres (from, fields, subject_link_column); SQL dialect is compiled automatically
• mongodb — set from to a collection name; runtime compiles find: / count: operations
• rest — set from to an API path (e.g. /users); runtime compiles GET request templates; profile needs base_url

Binding file suffix often matches the source key (.postgres, .mysql, .mongodb, .rest, …). The adapter type comes from the profile entry referenced by source_id.

8. Ontology — entities and relationships

The ontology inside a playbook is the shared language agents and humans use — independent of table or column names.

Entities are things in your world — you choose the names. Demo playbooks use names like:

• crm_user — example fields user_id, full_name
• crm_account — example fields account_name, industry
• crm_payroll_record, crm_lead — other demo entities

Relationships are directed edges you define between entities. Demo examples:

• owns_account — example: crm_user → crm_account
• user_has_payroll — example: crm_user → crm_payroll_record
• assigned_to — example: crm_user → crm_lead

Playbook relationships are logical. Bindings supply the physical join in your systems (foreign keys, owner columns, file columns, …). The demo uses names like owner_user_id and OwnerId — yours will differ.

9. ReBAC — relationship-based access control

When relationship_access_rules.active is true, Anything CLI enforces relationship-based access control (ReBAC) at query time. Access follows graph paths — e.g. “a person may read records linked via a relationship you define” — not just a static role flag.

Example rule block (demo playbook)

// relationship_access_rules — illustrative; use your entity and relationship names
"relationship_access_rules": {
  "subject_entity_name": "crm_user",
  "subject_identifier_field": "user_id",
  "deny_by_default": true,
  "active": true,
  "rules": [
    {
      "id": "own_accounts",
      "effect": "allow",
      "resource_entity_name": "crm_account",
      "path": [
        {
          "relationship_name": "owns_account",
          "direction": "forward",
          "from_entity_name": "crm_user",
          "to_entity_name": "crm_account"
        }
      ]
    }
  ]
}

How it works:

1. Rules define allow paths over playbook relationships.
2. At runtime, a federated graph is materialized from bindings (list_all per entity).
3. Count/list queries filter to rows the subject may access.
4. Proof includes rebac_applied: true when enforcement ran.

MCP tool list_allowed_rows returns visible row ids per entity for a subject — useful for debugging access.

10. Setup and use via MCP

Connect in Cursor

1. Run ./start-all.sh from the repo root.
2. In Cursor → Settings → MCP, add server URL: http://127.0.0.1:3334/mcp
3. Or run cargo run -p anythinggraph-ag -- mcp-config and paste the JSON snippet.

Ask questions (most common)

Replace the playbook id and names with yours. Prompts below use the demo playbook crm-payroll-access:

// Demo prompts — swap playbook id and person name for yours
For playbook crm-payroll-access: how many accounts does Alex Anderson own?

For playbook <your-playbook-id>: how many <relationship> records does <person> have?

These prompts use the query_graph tool with a demo playbook. Your agent uses the same tools with playbooks you define.

Map your own data (agent onboarding)

1. list_sources — see configured profile sources
2. get_playbook_context — entities and relationships for a playbook
3. introspect_source — read schema (Postgres tables, CSV columns, Salesforce objects)
4. suggest_bindings — heuristic entity → table mapping
5. propose_binding → test_binding → save_binding

Using anythinggraph-thin MCP: load playbook <your-playbook-id>, inspect my data
source, suggest how to map entities to my tables, test the binding, and save it.

MCP tool reference