[LinuxDevil]

What

• currentDateTool, dayNameTool, createEmailTool(), createHttpTool(), createSlackTool() and createDelegateTool() are built with defineTool (names current_date, day_name, send_email, http_request, slack_alert, delegate_to_<sanitized agent name>). Descriptions, schemas, approval/sandbox behaviour and factory signatures are unchanged; none imports from ai.
• McpToolLoader builds descriptors with the new toolDescriptorFromSchema() helper in src/tools/toolContract.ts (canonical inputSchema/execute plus a hand-built legacy .tool). It is used instead of defineTool because MCP tool names and descriptions come from remote servers: defineTool rejects names outside [a-zA-Z0-9_-]{1,64} and empty descriptions, which would silently turn previously loadable tools into skipped ones.
• routeFetchThroughSandbox (sandboxFetch.ts, read path only) now reads the canonical execute via getToolExecute().
• New static test src/tools/noAiToolImport.test.ts asserts none of the converted files (plus sandboxFetch.ts) import from ai; one new unit test for toolDescriptorFromSchema.
• CHANGELOG entry under Changed (non-breaking).

Why

Step 3 of the ai v4 -> v6/v7 upgrade chain: D22 made inputSchema/execute canonical, D23 owns ToolExecutionContext; the remaining small built-ins still called ai.tool().

Hazards found and handled:

• examples/ops-pipeline/fixer.ts (createFixerDelegateTool) spread createDelegateTool() and replaced only tool.execute. Now that the base descriptor has a canonical execute (which wins), the patch-extraction wrapper was bypassed and examples/ops-pipeline tests failed. It now wraps the canonical execute too (and no longer imports ai). This is a file outside the listed scope, forced by the conversion.
• github.ts/jira.ts (D25) build raw descriptors with no canonical execute, so they are unaffected by this change; left untouched.

Remaining from 'ai' imports under src/ (non-comment)

• src/types/tool.ts (type-only Tool as AITool, legacy .tool, removed in D26)
• src/providers/OpenRouterProvider.ts, AnthropicProvider.ts, OpenAIProvider.ts, OllamaProvider.ts (LanguageModel)
• src/providers/aiSdkProvider.ts
• src/tools/built-in/jira.ts, src/tools/built-in/github.ts (tool, D25)
• src/execution/structuredOutput.ts (zodSchema)
• src/execution/errors.ts (APICallError, LoadAPIKeyError, RetryError)
• test-only: src/tools/defineTool.test-d.ts, and tests that mock/import ai (e.g. src/tools/toolContract.test.ts)
• (src/execution/generateStep.ts only mentions 'ai' in a comment.)

Acceptance criteria

• The seven files build descriptors with defineTool (MCP loader via toolDescriptorFromSchema()), names/descriptions/schemas/approval/sandbox/factory signatures kept, no ai imports
• Existing tests pass unchanged (no existing test assertion edited); added the static no-ai-import test and a toolDescriptorFromSchema test
• Remaining from 'ai' imports listed above
• CHANGELOG (Changed, non-breaking); no docs needed
• Scope respected except examples/ops-pipeline/fixer.ts (see Why)

How verified

• npx tsc --noEmit: clean
• npm run lint: 0 errors, 402 warnings (changed files: net -1 any warning in sandboxFetch.ts; none added)
• npm run test:types: no errors
• npx vitest run: all pass after the fixer fix (first run had 2 failures in examples/ops-pipeline, fixed here)
• npm run build && npm run build --workspace=packages/create-loushy-agent: success
• npm run test:coverage: 158 files passed, 2289 tests passed, 3 skipped
• npm run fallow: dead code 0 issues, exit 0 (one pre-existing duplicate group in Anthropic/OpenAI providers, unrelated)

🤖 Generated with Claude Code

https://claude.ai/code/session_016bY29ibQgv3MDdjAbUT4YR

---

Generated by Claude Code