Airtool exposes the running platform to AI agents through a native Model Context Protocol server : 244 registered tools, 69 prompts and 210 machine-readable references, served through four endpoints that each reach exactly what they are allowed to reach. Every tool carries a risk class, every category is granted by an administrator, every call passes five gates that are re-checked at execution, and every call and every command it ran is written to the audit. Six model providers, five vector stores and the platform's own query compiler sit underneath. The result is an AI programme that security, audit and procurement can sign — because the agent is a governed actor, not a trusted one.
244 registered tools, each one action the model may take — read a table, prove a routine, write an object, register a database, grant a role. Grouped in categories an administrator hands out as units, with a description of what the family governs and the rule to know before calling it.
Development, application, workspace and administration endpoints. The URL declares the agent's intent ; a provider that does not serve a world is not consulted there. Administration tools can never be loaded into a development session.
R0 reads, R1 recoverable writes, R2 security-sensitive, R3 destructive. A tool is the user's when a grant says so ; a role can never lift what a grant does not give. A granted tool never pulls in a dependency at a higher risk than it was granted at.
Who, when, from where, how long, with what outcome — ok, gated or refused — and the SQL it executed, the plan it applied, the backup a delete journalled. The user sees their own calls ; the administrator queries the fleet.
Read from the platform's own catalogue, generated at request time for the user who asks.
Each family is a category an administrator grants as a unit. The read and write halves of one family are two categories, because handing somebody the power to read is not handing them the power to change. Counts are the development and administration worlds as served today.
The tables, views, sequences, functions, procedures and triggers a database has, its live sessions, the size and usage of one table, and one SELECT at a time against it. Nothing here writes. A business user reaches it on the application endpoint through the same grant that opens the database in Apps ; the platform's row security is injected into every query exactly as it is for a form.
Table models, functions, procedures and triggers in XDBL ; native routines in an engine's own SQL ; server-side JavaScript functions, modules and includes ; REST contexts and endpoints ; the application objects themselves. Read one body, prove it before it is written, write it as a journalled change, deploy it to the engine. Sixty-plus tools in nine categories.
Explain plans, statement rules, column-width checks, review guides and schema scans ; test runs against an object or a whole dictionary, on TEST and DEV environments only. The agent proves its work with the same tooling the engineering team uses.
Every write is journalled with its before-image. The journal lists what changed, shows an object's history, and produces a restore plan that brings a deleted routine or object back. A deletion is dry by default and needs the delete grant on the dictionary.
One search across everything a dictionary holds as text, each hit naming the typed tool that reads it in full. Working notes the agent keeps for the next session. The reference documents the platform generates about itself — column oracle, text oracle, tool catalogue.
Database servers and their credential pairs, database registrations and dictionary stacks, connection pools and limits profiles, engine users, platform users and grants, per-database application roles, the security answers an auditor reads without being able to change anything, IP and CIDR access rules, mail and Redis services, observability, and the audit itself. Served only on the administration endpoint, to administrators only.
An agent connects to one endpoint. The endpoint decides which providers exist at all, who may open it, and how far a call reaches. The other worlds' tools are absent, not refused.
One dictionary, or a data database and every dictionary of its stack. Developers only ; never a production or unclassified target unless a root privilege is held. Where the application is authored, proved and tested.
One data database, production included, with the tools its dictionary stack defines. Any authenticated user, through their own grant on the database. Where business data lives and where a business user's assistant works.
Any non-production database, named per call. Needs its own role ; the unscoped door serves only the read family and platform news, never production. The general-purpose endpoint for exploration.
The studio catalogue : users, servers, databases, pools, grants, roles, audit. Administrators only, and a separate door, so administration tools are never loadable into a development or application session.
| R0 · read | R1 · write | R2 · security-sensitive | R3 · destructive | |
|---|---|---|---|---|
| Meaning | Reads — nothing is written | Writes something recoverable | Touches credentials, roles, grants, or what a fleet resolves through | ✓ Irreversible |
| Development world | 89 tools | 38 tools | 9 tools | ✓ 17 tools |
| Typical tools | db_query, db_table_get, dev_server_function_get, obj_get, adm_sys_user_security_get | dev_db_table_write, dev_server_module_edit, obj_apply, docs_write | dev_rest_api_write, dev_rest_context_write, adm_sys_user_grant_set, adm_ai_tool_grant | ✓ dev_db_table_delete, dev_rest_api_delete, adm_db_user_drop, adm_audit_mcp_purge |
| Grant unit | Category, pattern or single tool | Category, pattern or single tool ; dry-run by default, journalled | Explicit ; widening settings need consent on top | ✓ Explicit ; dry by default, before-image journalled, delete grant required |
A tool the agent was never shown can still be named by a client. That is why the world, the role, the allowance and the environment are all re-checked on the call, and a refusal names what is missing.
The endpoint decides which providers exist at all. A provider that does not serve this world is not consulted — not listed, not callable. Administration tools are absent from a development session rather than refused.
The endpoint decides who may open it : the developer role and a dictionary target for development ; a grant on the database for application ; the workspace role for the unscoped door ; administrator capability for administration. Production and unclassified environments are refused where the world does not serve them.
Roles decide which families are on the table — the developer role puts dev_*, obj_*, qa_* and test_* there ; administrator capability puts adm_* on the administration page ; the documentation level of a grant, not a role, opens the manual. A role is the door to a family, never the permission to a single tool.
Each tool declares the category it is granted in and what a call can cost. A tool is the user's when a grant row says so ; the role can never lift what a grant does not give. An administrator grants and revokes by tool, by pattern or by category, and the grant records why.
Every gate runs again on the call, plus the environment : the world, the allowance, the provider's own gate and the database's environment. Hiding a tool is not enforcement ; enforcement is the call.
The same discipline the engineering team works under applies to the agent — mechanically, on every write.
A table model, a routine, a trigger or a server script is checked as the runtime would run it — parsed, validated against the XDBL schema, its host-library members verified — and a body with errors is refused. A statement can be proved against the live schema before it is stored.
A write reports what it would do and writes nothing until the call is repeated without the dry flag. A deletion is dry by default. The plan names every database the change would be live on.
Every write is journalled in the changeset with a comment as its note ; a deleted body is kept as the before-image ; a restore plan brings it back. Writes are versioned with size, checksum and delta as a file saved over the network would be.
Tools that reach an engine refuse on the environment before they run : test tools run only on TEST or DEV ; REST changes are served only where every database that stacks the dictionary is TEST or DEV ; the development world never opens a production target without a root privilege.
A setting that widens who reaches an endpoint — a public REST context, parameters passed through unvalidated — is refused unless the call states the widening is meant. A change that would lock an administrator out is refused unless told the lockout is intended.
A write is refused while a Studio draft of the same body is in edition. The agent and the engineer work on the same record ; the platform arbitrates.
Nothing here is maintained by hand. The references are produced from the running server, so an agent reads the platform as it is, not as a document once described it.
The XML database language as this server implements it : an index, one outline per statement root, and the expression functions cross-checked against the grammar. The language the agent writes data access in, described by the compiler that will execute it.
Every Java class the server exposes to JavaScript, Python and Groovy scripts, introspected at runtime from the registry rather than written down. The agent cannot call a member that does not exist.
The document formats of every application object, the shape vocabularies an object chooses from, the authoring rules that name the mistakes left after every key is read correctly, and the capabilities catalogue with a live specimen for each.
The column oracle and the text oracle over the dictionary ; the QA statement rules, explain rules and review guide ; the server scripting languages with the engine versions this server runs ; the 4GL subset the engine executes.
Most AI-on-data systems use a service account with broader permissions than the human user, then rely on filtering. Here the agent operates under the user's own runtime identity, and the constraint is enforced at compilation.
The platform's XSD-described grammar is what the agent emits. It is small, complete and served to the agent as a reference ; a misspelled function or a missing argument is a compile error, not a runtime one. Seven engine dialects are never the agent's output.
Date arithmetic, string functions, isolation levels and sequence handling are resolved against the engine bound to the user's request context. The agent does not learn dialects ; it inherits ten engines.
At the same step, the row-level expressions for the user's roles, departments and ownership rules go into the WHERE clause and the column-level visibility rules shape the SELECT list. The statement that reaches the database is already narrowed to what that user may see.
The agent does not connect to the database. It emits XDBL ; the runtime calls the compiler ; the compiler returns engine-native SQL with the security layer applied ; the runtime executes it. Where an engineer chooses native SQL, that path is granted, executed as written and audited — it is a first-class path for people, and not one the agent is given.
MCP is the open standard through which AI assistants drive systems. The platform is MCP-native : the server is part of the runtime, not a wrapper in front of it.
A platform endpoint that speaks MCP Streamable HTTP. Stateful sessions and stateless one-shot or serverless clients are served on the same URL without load-balancer affinity ; the protocol version is negotiated per connection and an operator can restrict the versions accepted.
OAuth 2.1 with a mandatory PKCE challenge for interactive agents ; client credentials for machine agents ; a token is minted for one endpoint and opens no other. A personal token issued by the user and enabled by an administrator is the alternative path. Revoking the grant revokes the access.
The tool list an agent sees is resolved for the user who asks : granted, not granted, hidden by role, hidden by world, unusable here — each state visible, none inferred. Ten tools a role opens but a grant withholds are listed struck through, so what is missing is named, not silent.
Schema resources describe the data dictionary to the agent ; reference documents describe the object formats, the languages and the host library ; 69 reviewed prompts carry the procedures an agent follows for a schema conversion, a rename campaign or a security review.
Stored procedures, functions and triggers are listed and described by parameter signature and body, database chosen per call, under the same grants as everything else. Every place a table is referenced — keys, triggers, routines, dictionary — answered in one call before it is converted or dropped.
Every tool states how far a call goes on a dictionary stack : one dictionary, the resolved layer, the whole stack, or across to data. The agent knows before it calls whether a question about the application reads every layer or one.
Auditability is the property that turns an agent from a risk into an accountable actor. It is not a log of the conversation ; it is a log of what was executed.
Authenticated user, tool, full parameters, endpoint, target, duration, request and result sizes, tokens, and the outcome — ok, gated or refused — with the failure kind and the error text where a call was stopped. Written for every registered tool with no per-tool configuration.
The SQL a call executed, the plan a write applied, the backup a delete journalled. What the agent did is answerable in the same terms an engineer's work is.
Every user sees the calls agents have run on their account, newest first, filtered by tool, outcome and date. Supervision starts with the person whose identity the agent carried.
The audit is queried as SQL through the reporting surface and through administration tools that list, read and aggregate MCP calls, logins and raw attempts, and object executions. Purging the audit is the one write in that family, and it is classed apart.
Provider choice is configuration, not code. The model for a conversation is chosen when it starts, within the allow-list the company sets.
General-purpose generation when the operational context permits a public API call.
Instruction-following, code review and document analysis ; the platform's own agents are developed against it.
Open-weight models on customer hardware. Full data residency, no public-API dependency, no marginal cost per call.
Generation, embeddings and reranking for customers with Google Cloud workloads or Google-specific compliance requirements.
Governed workloads and data-residency configurations for enterprises with an IBM relationship ; IAM tokens refreshed transparently.
Generation and embedding for customers preferring Cohere's models, particularly under European data-residency configurations.
The same multi-engine philosophy that applies to relational databases applies to vector stores.
Qdrant, Milvus, PostgreSQL pgvector, Redis and Informix behind one retrieval interface. Ingestion, chunking, embedding, retrieval with maximum marginal relevance, multi-query merging, reranking and citation — all under the security perimeter the customer's data lives in.
Approximate-nearest-neighbour indexes on PostgreSQL and Informix keep the vector index on the same engine the application reads — same access controls, same backup policy, same connection pool. Bulk loads can drop and rebuild the index around ingestion.
Dense embeddings run in a dedicated microservice ; the embedding model is chosen per request, and each model declares the context limit that governs chunking.
Natural-language analysis of operational data, explanation of what changed and who changed it from the audit trail, drafting of customer communications and regulatory submissions from the same data the rest of the platform reads — with human review by default.
AI spend is governed at the point of use, not discovered on the invoice.
Central registration of providers and models with per-model pricing for request and response tokens. Adding a model is a configuration step ; the cost layer reflects it automatically.
Default models for chat, embeddings, reranking and speech cascade from the platform to the company to the department to the user ; a user overrides only where a role permits it.
Monthly spend caps per company, request quotas per user, maximum tokens per request, allow-listed models. A call that would exceed the cap is rejected cleanly, not reported later.
Every AI request logged with provider, model, tokens consumed, cost, execution time, user and outcome ; prompt-cache reads and writes reported beside ordinary usage. Cost attribution is a query against the platform's own data.
Screens from the running platform : the catalogue resolved for one user, the risk classes, the gates, a category with its tools, the worlds, and the record.
An enterprise adopting AI agents faces one question from its security office, its auditors and its procurement team : what, exactly, can the agent do, and who answers for it. Most AI integrations cannot answer it, because the agent holds a service credential and the application is asked to filter. Airtool answers it with a catalogue. Every tool an agent may call is registered with a category, a risk class and a description of what it governs ; every category is granted by an administrator who records why ; every call is written to the audit with the commands it ran. The contract between the organisation and its agents is a document the platform generates about itself, resolved for the person who asks.
The four worlds give the organisation a vocabulary for blast radius. A development agent authors and proves application code on a test dictionary and cannot see production. A business user's assistant works on one data database through that user's own grant, with the same row security a form applies. An administration agent operates the fleet through a separate door that a development session can never open. The risk classes give the same vocabulary for policy : an organisation can hand its agents every read tool on day one, grant recoverable writes by category as trust is earned, and keep destructive and security-sensitive tools under explicit, recorded grants.
The write discipline is what makes delegation safe. A change is proved before it is written, reported before it is applied, journalled with its before-image, restorable from the journal, refused on the wrong environment, and refused while a person is editing the same body. These are the rules an engineering team applies to itself ; the platform applies them to the agent mechanically, on every write. The engineer and the agent author the same governed record, and the platform does not care which of them produced the change — it governs both identically.
The structural advantage exists because applications on Airtool are metadata, not files. Forms, endpoints, roles, scheduled jobs, routines and audit trails are records in the metadata repository. The compiler owns every path to the data because there is no parallel path. A constrained metadata record is governable in a way arbitrary generated code is not — which is why the agentic era is an argument for this runtime, not a threat to it.
Whatever the tools it has been granted allow, and nothing else. The catalogue registers 244 tools across the four worlds : reading data under row security ; reading, proving, writing and deploying application code ; quality scans and tests ; the changeset journal and restore plans ; documentation ; and, on a separate endpoint for administrators only, the operation of the fleet — servers, databases, pools, users, grants, roles, access rules and the audit. An agent sees the tools resolved for the user it acts as, in the world it connected to.
By a system administrator, by tool, by pattern or by whole category, and the grant records why. A role is the door to a family — the developer role puts the development families on the table — but a tool is the user's only when a grant row says so. A granted tool pulls in the tools it cannot work without, never at a higher risk class than it was granted at. Grants can be listed, revoked and audited like any other configuration.
The call itself. Listing hides ; the call enforces. A client can send a name it never listed, so the world, the role, the allowance, the provider's own gate and the database's environment are all re-checked when the tool is invoked, and a refusal names what is missing.
Only where the organisation decides it should. The development endpoint refuses a production or unclassified target unless the user holds a root privilege ; the workspace endpoint never serves production ; the application endpoint serves production data through the user's own grant on that database, with the same row security a form applies, and with write verbs granted per database. Test tools run only on TEST and DEV environments.
It carries the R3 risk class, is granted explicitly, is dry by default, requires the delete grant on the dictionary, and keeps the deleted body as the before-image of a journal entry from which a restore plan can bring it back. A change that would lock an administrator out, or widen who can reach an endpoint, is refused unless the call states that this is meant.
Every call is written to the audit with user, tool, parameters, endpoint, target, duration, tokens and outcome — ok, gated or refused — together with the commands it ran : the SQL, the plan applied, the backup journalled. Users see their own calls in their preferences ; administrators query the fleet as SQL and through the audit tools. The audit is written for every registered tool with no per-tool configuration.
What the platform tells it about itself. The catalogue serves 210 generated references : the XDBL language as this server implements it, every host-library class exposed to scripts, the document format of every application object, the authoring rules, the QA rulebooks, and oracles over the dictionary's columns and text. Nothing is maintained by hand, so the agent reads the platform as it is.
Structurally. The agent operates under the user's own runtime identity, not a service account. For data access it emits XDBL, and the compiler injects the user's row-level and column-level security into the statement it generates. A finance agent for a user with accounts-payable access cannot read payroll data — not because it was asked to be careful, but because the compiler does not generate a query the user could not run.
Yes. Six providers sit behind one interface ; provider choice is configuration, and the model for a conversation is chosen when it starts within the company's allow-list. Customers commonly develop on a public-API provider and move production workloads to on-premises or region-resident models without re-authoring agents.
Yes, by construction. Each request runs inside a scoped context bound to the authenticated principal, the target database and the tenant identity ; the compiler emits SQL against that tenant's security model, database and connection pool. There is no shared service account and no shared data path. A new tenant applies the same model with no additional AI configuration.
Providers and models are registered with per-model pricing ; defaults cascade from platform to company to department to user ; monthly spend caps per company, request quotas per user, token limits per request and model allow-lists are enforced before a call reaches the provider. Every request is logged with tokens, cost and cache usage, and cost attribution is a query against the platform's own data.
Yes. Open-weight models run on customer hardware through the Ollama provider ; vector stores run on the operational engine or self-hosted ; the MCP server runs inside the customer perimeter. The abstraction that makes provider choice reversible is unchanged.