[Feature] Introduce built-in tools

[RadCod3]

Description

Today the only tool type in the AFM tool schema is MCP, tools accepts an mcp list and nothing else. This request proposes built-in (native) tools: capabilities the interpreter provides directly, with no MCP server to stand up. Two concrete instances motivate this:

1. Generic built-in tools: platform-agnostic capabilities such as file read/write.
2. Platform reply tools: tools auto-exposed by a platformchat interface so an agent can reply back on the same platform it was triggered from.

Use Case

File read/write

Many agents need to read and write local files (load a document to summarize, persist a generated report, append to a log). Today the only option is to wire up a filesystem MCP over stdio, e.g.:

tools:
  mcp:
    - name: "filesystem_server"
      transport:
        type: "stdio"
        command: "npx"
        args:
          - "-y"
          - "@modelcontextprotocol/server-filesystem"
          - "/path/to/desktop"

This requires an external process (npx/Node) and makes a portable AFM file depend on the host having that MCP available. A built-in file tool would be zero-setup and portable.

Platform specific tools

If a user wanted to write a Chat Bot agent using a platform like telegram, with the upcoming chat trigger support #34 , they would be able to easily define that like,

interfaces:
  - type: platformchat
    platform: telegram
    mode: polling
    polling:
      interval: 2
      timeout: 30
    platform_config:
      bot_token: "${env:TELEGRAM_BOT_TOKEN}"
    prompt: "Message from ${http:payload.message.from.first_name}: ${http:payload.message.text}"

The problem: platformchat in polling and notification modes is input/trigger-only. The interface defines how a message enters the agent (the prompt template + payload), but there is no output path back to the platform. The agent runs on each incoming message, but its reply is discarded.

Today the workaround is to find and configure a third-party MCP that can send messages on the platform, and plug it in as a tool. That is extra setup and it duplicates the bot_token / connection config the interface already holds.

Instead, when an agent declares a platformchat interface, the interpreter could automatically expose the matching reply tool (e.g. send_telegram_message), reusing the credentials and routing the interface already has.

Proposed design (draft)

A new tools.builtin list alongside tools.mcp:

tools:
  builtin:
    - file_read
    - file_write
  mcp:
    - name: "github_api"
      transport:
        type: "http"
        url: "https://api.githubcopilot.com/mcp/"

Open design questions

1. Auto-expose vs. opt-in for platform tools. Auto-exposing reply tools from the interface is convenient but implicit, and it couples the interfaces section to the tools section, which the schema currently keeps separate. Should the user be able to disable the auto tools? Should tool_filter-style controls apply to them?