refactor(mdcode)!: remove entity lookup tools from agent tool derivation

toolbox/mdcode/demo/semantic-model/skill/README.md

@@ -274,7 +274,7 @@ gcloud spanner databases execute-sql "$DATABASE" \
 
 That leaves order 12345 at $165.85 over four line items — including a $30
 shipping fee, which is what the first request below is about — 12346 at $18.00,
-and 12347 at $200.00. The two extra orders give the lookups something to tell
+and 12347 at $200.00. The two extra orders give a query something to tell
 12345 apart from.
 
 Every number quoted in this README came from a run against exactly this seed. To

toolbox/mdcode/demo/semantic-model/skill/catalog/EntryGroups/commerce_demo/commerce.yaml

@@ -50,10 +50,10 @@ semantic_model:
     # keeps privately is a rule that can be changed without the people who own
     # the model finding out. Agents come and go; the model stays.
     #
-    # Only what is specific to this business belongs here. How to use a lookup
-    # tool, and what to do when a write is refused, are properties of the tools
-    # rather than of commerce, so the derivation supplies those and this does
-    # not repeat them.
+    # Only what is specific to this business belongs here. Where a key has to
+    # come from, and what to do when a write is refused, are properties of the
+    # tools rather than of commerce, so the derivation supplies those and this
+    # does not repeat them.
     ai_context:
       instructions: >-
         You are working an internal operations desk for this business, fixing
@@ -153,13 +153,12 @@ semantic_model:
         ai_context:
           instructions: >-
             Give the order as its number, the amount in dollars, and a memo
-            saying why. Look the order up first if you were given a customer
-            name rather than a number: an Order is identified by its key alone.
-            Say in the memo what actually went wrong on the order -- a late
-            delivery, a damaged item, a shipping charge applied in error --
-            and, if this credit is part of a larger amount owed, say that and
-            give the total. A rule reads the memo, so a fact left out of it is
-            a fact the rule cannot weigh.
+            saying why: an Order is identified by its key alone. Say in the
+            memo what actually went wrong on the order -- a late delivery, a
+            damaged item, a shipping charge applied in error -- and, if this
+            credit is part of a larger amount owed, say that and give the
+            total. A rule reads the memo, so a fact left out of it is a fact
+            the rule cannot weigh.
 
     # The rules, settled by a judge reading the attempted call and, where the
     # rule is about something on record, the record. All four are what

toolbox/mdcode/docs/semantic-model/profiles.md

@@ -7,10 +7,10 @@
 > names — BigQuery Graph or Spanner Graph — and the logical model to Knowledge
 > Catalog, which takes it under any profile.
 >
-> An action's statements and an agent's lookups run, against an operational
-> store: **Spanner or AlloyDB**. An AlloyDB target runs and does not push, because
-> AlloyDB has no property-graph DDL for a push to deploy; a BigQuery target
-> pushes and does not run. A Spanner target does both.
+> An action's statements run against an operational store: **Spanner or
+> AlloyDB**. An AlloyDB target runs and does not push, because AlloyDB has no
+> property-graph DDL for a push to deploy; a BigQuery target pushes and does
+> not run. A Spanner target does both.
 >
 > A profile may still bind an entity to any other store (a lake table, a
 > partner's schema). `kcmd` merges it and reports its availability, and neither

toolbox/mdcode/docs/semantic-model/reference.md

@@ -94,11 +94,11 @@ IFS=/ read -r PROJECT INSTANCE DATABASE <<<"$(kcmd profiles --print-store)"
 kcmd agent-tools
 ```
 
-Prints what an agent would be handed for the models in the scope: one lookup
-tool per entity, and one tool per action. Each carries its description, the
-calling guidance the model wrote, and one line per parameter giving that field's
-own description. Reading the model is all this does — it touches no store and
-runs nothing.
+Prints what an agent would be handed for the models in the scope: one write
+tool per action, and the model's instruction. Each tool carries its description,
+the calling guidance the model wrote, and one line per parameter giving that
+parameter's own description. Reading the model is all this does — it touches no
+store and runs nothing.
 
 A tool the runtime cannot call is listed and marked `[NOT RUNNABLE]` rather than
 dropped, with the reason in its description, so a refusal is visible before any

toolbox/mdcode/docs/semantic-model/skills.md

@@ -284,13 +284,11 @@ when it cannot settle one the model requires.
 
 ## What it doesn't generate yet
 
-* **Reads.** A skill describes the writes. The lookups a model derives are a
-  read path nothing on the command line calls, so rather than pointing an agent
-  at a tool that isn't there, the skill says where the key has to come from and,
-  for a Spanner store, gives the `gcloud` line that reads it and the schema to
-  write against. A model bound to AlloyDB gets neither, so an agent handed a
-  name under that profile has nothing in the skill telling it how to reach a
-  key.
+* **Reads.** A skill describes the writes. Rather than generating read tools,
+  the skill says where a key has to come from and, for a Spanner store, gives
+  the `gcloud` line that reads it and the schema to write against. A model bound
+  to AlloyDB gets neither, so an agent handed a name under that profile has
+  nothing in the skill telling it how to reach a key.
 * **Metrics.** A metric reaches BigQuery as a `MEASURE`; nothing lowers one into
   a skill.
 * **A plugin.** An [Agent Plugin](https://agent-plugins.org/) bundles skills with