Monospace scored 27 out of 100 on Cloudflare's isitagentready.com, which checks how readable a website is for AI agents. That's a low score for a product whose tagline is "The Governed API Layer for Every App, Person, and Agent".
Monospace is a new governed API layer from Monospace Inc., the company behind Directus, with a built-in MCP server for agents.
Four days after launch, we put Monospace through our agent experience (AX) audit, following our AX audit method, to see whether an AI coding agent can:
- know about it without searching
- find it when it's looking for a tool like it
- recommend it once it's found
- install it and build a working integration
All testing used Claude Opus 5.5 (claude-opus-5-5) in Claude Code 2.1.285, on 6 October 2026. Every session started in a fresh, empty folder with no project files, memory, MCP servers, skills or plugins. Awareness questions ran with no tools at all, and discoverability and reputation questions with web search and web fetch only. We ran each prompt once, so treat these results as one developer's experience rather than a benchmark.
What is Monospace from Directus?
Monospace is a governed API layer that connects to your existing databases and gives apps, people and AI agents live read-write access through one permissions model. It's made by Monospace Inc., the company behind the open-source Directus data platform. Monospace's launch article (2 October 2026) calls it a public preview, while the Directus community announcement calls it generally available. Here's what we confirmed on Monospace's own site and docs on 6 October 2026:
- Deployment. Self-hosted with Docker. There's no self-serve hosted version, and the "Get Started" button leads to a contact form.
- Connectors. PostgreSQL, MySQL and MariaDB are available, with SingleStore and TiDB in beta. HubSpot, Stripe, Salesforce, Zendesk, Jira and others are listed as coming soon, and other systems need custom connectors on the Enterprise plan.
- Agent access. Each workspace has an MCP server with seven tools (
list_items,create_items,update_item,delete_item,read_schema,read_data_sourcesandmutate_schema), authenticated with an API key. There's also a REST API, a TypeScript SDK, a CLI and an agent skills plugin for Claude Code. - Pricing. The Starter plan is free (1 workspace, 3 users). Row/column-level security, audit logs, SSO, service accounts and custom roles and policies are on the custom-priced Business and Enterprise plans.
Scores at a glance
Agents don't know Monospace, and only find it when they search for its own tagline. Once they do find it, they like the design but hedge every recommendation, and often fill gaps with facts about Directus. The integration went well. The agent installed Monospace, loaded our data and answered questions over MCP with a few short human steps, but the free plan blocks the governance features Monospace leads with.
See our AX audit rubric for how we score each stage.
Does the model know Monospace?
Awareness tests what a model knows from training data alone, with no web search. For a product launched four days earlier, we expected the answer to be no. What matters is how the model fails, whether it admits it doesn't know, makes something up, or confuses Monospace with something else.
We first described Monospace's pitch without naming it:
I want a single API layer in front of our Postgres database, a few internal REST APIs and some SaaS tools, with row- and field-level permissions and an audit log for every caller, including AI agents. What would you use? Answer from your own knowledge.
The agent confidently picked one product, Hasura DDN, with OPA for complex policies. A broader question about governed agent access to company data got a stack of five or more products instead, opening with:
"No single product covers all of this. What works is a stack of layers..."
That's the gap Monospace says it fills. Then we named it:
What is Monospace (monospace.io)?
What do you know about Monospace, the "governed API layer"? What does it do, and who is it for? Say clearly if you don't know.
Tap any screenshot to zoom in and read it, tap again to close.
Given the domain, the agent answered "To my knowledge, Monospace (monospace.io) is the company behind Directus, the open-source headless CMS / data platform." and said nothing about the governed API layer. Given the tagline instead, it said it didn't know, and treated "governed API layer" as a generic category phrase ("That describes the category, not this specific product.").
Asked whether Monospace was a good choice for giving agents database access, it refused to vouch either way and listed what to look for in any such tool, including read-only access, row-level permissions, per-agent credentials, audit logs, self-hosting and MCP support. Monospace claims almost every item on that list.
The model never invented features, which is good behaviour. But a developer asking their agent about Monospace today either hears about Directus or gets "I don't know". The agent also raised two name clashes, monospace fonts and Google's old internal "Monospace" codename for what became Project IDX.
What Monospace can do about it
Training data catches up slowly, so there's no quick fix here. The useful work is making sure the next training cut sees Monospace as a product in its own right. That means launch posts, guides and comparisons that pair the name with what it does ("Monospace, the governed API layer from Directus") rather than using the name on its own.
Can an agent find Monospace?
Discoverability tests whether an agent with web search finds the product when it's looking for something like it. We ran three six-question "funnels" in a single session each. Each funnel starts with a broad problem and narrows towards Monospace one question at a time, then names it at question 6. We recorded the first question where Monospace appeared.
Each funnel asks from a different angle, because different people describe the same problem differently.
| Funnel | Who's asking | Starts with | First mention of Monospace |
|---|---|---|---|
| A | A team wanting agents to use company data | "My company wants to let AI agents work with our internal data" | Question 5, by searching for "governed API layer" |
| B | A backend developer | "One API in front of several databases" | Question 6, only when named |
| C | Someone building agents | "I'm ending up with a separate MCP server for every system" | Question 5, by searching for "governed API layer" |
Questions 3 and 4 described Monospace's features closely, then asked the agent to search online for newer tools, including anything launched in the last few months. It never found Monospace from either. In funnel A, the hunt for new launches turned up a two-week-old AWS project but missed Monospace, which had launched four days earlier. In funnels A and C, the agent said the product didn't exist:
"No single product does all three across Postgres, your REST APIs and your SaaS systems."
"No product does this as a drop-in layer, and a gateway can't do it reliably."
Monospace only appeared when question 5 used its own wording, "governed API layer", and the agent searched for that phrase in quotes.
Funnel B, the developer's angle, went worse in two ways:
- The agent recommended Directus for Monospace's job. At question 3 it said, "Directus if you want one product that does introspection, a TS SDK and MCP with identical permissions, and you only have SQL databases."
- Searching for the tagline didn't work either. At question 5 the agent searched for the exact phrase "every app, person and agent", got CData, DreamFactory and a young startup called Valv, and concluded, "I couldn't find a product that uses exactly "a governed API layer for every app, person and agent"."
Once found, Monospace became the agent's top pick every time. It called Monospace "the closest match to your requirements of anything I've found" in funnel A, "the best fit so far" in B, and "the best conceptual fit of everything we've looked at" in C. Each time it added the same caveat, that Monospace was days old and unproven.
What Monospace can do about it
Publish pages built around the problems agents are asked about
Agents ran searches like MCP gateway agent identity fine-grained authorization audit log Postgres SaaS 2026 and AI agent data access control plane field-level permissions MCP new product 2026, and none of them surfaced Monospace. Guides and docs titled around those problems, in a developer's words, would give agents something to find.
Get into the comparison articles agents already read
The recommendations agents made instead came from vendor comparison posts and round-ups, Bytebase and Cerbos blog posts, Product Hunt, and MCP directories like Glama. That's where Hasura, WunderGraph Cosmo, DreamFactory and Cerbos got their mentions.
Separate Monospace from Directus on purpose
In funnel B the agent recommended Directus for Monospace's use case. A clear "Monospace vs Directus: which should I use?" page on both sites would teach agents when to send developers to which product.
Do agents recommend Monospace?
Reputation tests what the agent thinks once Monospace is named, including whether it recommends it over competitors and whether it gets the facts right. We ran eight questions, each in a fresh session with web search. Hasura and WunderGraph Cosmo were among the competitors the agent named most often before it found Monospace. We added Directus on purpose, because of funnel B.
| Question | Verdict |
|---|---|
| What do you think of Monospace for governed agent access? | "Worth a proof of concept, but I wouldn't put it in production yet." |
| Monospace over Hasura? | No: "use Hasura for production now, and run a small trial of Monospace alongside it" |
| Monospace over WunderGraph Cosmo? | Yes, conditionally: "I'd lean towards Monospace for what you described" |
| Monospace over Directus? | Yes, conditionally: "mainly because you need internal APIs as well as Postgres" |
| 20-person startup on Postgres, Stripe and HubSpot | "Not yet. It's aimed at your exact problem, but two of your three systems aren't supported today." |
| Regulated company needing self-hosting, SSO and a full audit trail | "Yes, it's worth shortlisting, but don't approve it yet." |
| Main risks of adopting Monospace (name only) | Couldn't identify it; answered about a font |
| Pricing and licensing vs Hasura and Cosmo (name only) | Priced Directus instead, "fairly confident (~75%)" |
The agent liked the design every time. For a regulated company, it called it "the right design for a regulated environment: agents never hold database credentials directly." But it never recommended Monospace without conditions, and most verdicts came back to how new it is.
The answers' quality depended on which pages the agent reached. The most accurate answer, the startup "Not yet", came from Monospace's own homepage, pricing page and connectors page. It found that Stripe and HubSpot are listed as "Coming Soon", and that row/column-level security and audit logs aren't on the free plan. When the agent read less, it filled the gaps with outdated or borrowed information:
| What the agent said | What's true |
|---|---|
| Monospace's pricing isn't on the site | It's at monospace.io/pricing |
| Monospace has a GraphQL API | No GraphQL API is documented; it offers REST, an SDK and MCP |
| Directus's licence is "BSL" | Directus moved to its own MSCL licence in 2026, and that licence is Directus's, not Monospace's |
| Monospace costs $499/month on a Team plan | That's Directus Cloud pricing. Monospace has a free Starter plan, then custom-priced Business and Enterprise plans |
| "The product page never names Postgres" | True. Postgres support is only listed on the connectors page and in the docs |
Asked about Hasura, the agent also spotted Monospace's own mixed messaging ("Their own posts disagree on whether it's "GA" or "public preview"."). It was right, since Monospace's launch article says "Monospace is in public preview", while the Directus community announcement says it's GA.
The two questions that named Monospace without its domain went worst:
Searches for "Monospace developer tool" and "Monospace launch 2026" found nothing, so the agent answered about GitHub's Monaspace coding font instead. In the pricing comparison, it never reached monospace.io, and confidently priced Directus as if it were Monospace.
Monospace vs Directus
Directus is Monospace Inc.'s older product, and it has its own MCP server. When we asked directly whether to choose Monospace over Directus for exposing Postgres and internal APIs to apps and agents, it leaned towards Monospace, "mainly because you need internal APIs as well as Postgres". Its reasoning was that Directus is built around a single SQL database, while Monospace applies one permissions model across several sources. It described the two as "a sibling product, not an unknown vendor", and still pointed teams that only need Postgres towards Directus, for its proven field-level permissions and its admin UI.
What Monospace can do about it
Put the key facts on the pages agents read first
The homepage was the page agents read most, and it doesn't name Postgres or state a licence. Agents that stopped there guessed both. A line on the homepage naming the supported databases, the licence and where pricing lives would have fixed several wrong answers.
Settle "public preview" or "GA"
Agents picked up both, and used "preview" as a reason not to recommend Monospace for production. Use one status everywhere.
Publish what agents told our test user to ask sales
For the regulated company, the agent listed five questions to ask Monospace's sales team. They covered whether audit logs record the full query, whether the log is tamper-evident and can stream to a SIEM, whether SAML or OIDC work self-hosted, what licence covers self-hosting, and what compliance reports exist. Docs pages that answer those would give agents what they need to move past "don't approve it yet".
Can an agent set up Monospace and build with it?
Integration tests whether an agent can install the product and build a "hello world" with as little human help as possible. We gave it three spreadsheets for a fictional business (50 customers, 30 products, 300 orders with 741 line items) and asked it to:
- Set up Monospace and give us a localhost link.
- Get the spreadsheet data into Monospace and connect itself to it.
- Answer a question using Monospace: which region had the most revenue in the last three months, and who were its top three customers?
- Create a restricted key for an "analyst" agent that can't see customer emails, and prove it.
- Mark one order as refunded through Monospace.
We ran it in Claude Code's default permission mode, approving each command, so we could stop the agent from reading anything outside its folder. Monospace has no hosted signup ("Get Started" leads to a contact form), so the agent had to self-host it with Docker.
Installing: one hint, then four minutes
The agent's first search, "Monospace self-hosted open source app github", found only fonts, so it stopped and asked which Monospace we meant.
We replied "It's the one at monospace.io.", and the agent then read the installation page, downloaded the official Docker Compose file, and had Monospace v1.0.0 running with Postgres, RabbitMQ and Redis in 4 minutes 12 seconds, with no errors.
Creating the admin account, accepting the licence agreement and creating a workspace took us 7 and a half minutes in the browser. There's no email verification. The last onboarding screen shows how to connect Claude Code (a claude mcp add command) and how to install Monospace's agent skills plugin. That's more agent guidance than we usually see in onboarding.
Loading the data and connecting over MCP
Monospace's homepage illustrates its data sources as files like customers.xlsx and inventory.xlsx, but its connectors are PostgreSQL, MySQL and MariaDB, with no spreadsheet connector. The agent worked this out from the docs and took a sensible route. It converted the spreadsheets to SQL, loaded them into a new database inside Monospace's own Postgres container, and registered that database as a data source through Monospace's API. Monospace detected the relationships between the tables on its own, and the agent checked that every table's row count matched the spreadsheets.
The agent leaned heavily on Monospace's agent-friendly docs, including llms.txt, the 1.4 MB llms-full.txt, and raw Markdown versions of each docs page. The agent said the OpenAPI spec served by the running instance "mattered most". The docs have no request examples for creating a data source, so it worked out the format from that spec, by trial and error.
It then needed one thing it couldn't do itself, an API key. It asked us to create one in the UI and write it to a file with a ! pbpaste command, so the key never appeared in the chat. Here the UI tripped us up. The prominent API Keys settings page creates service account keys, and service accounts aren't on the free plan:
The agent's instructions were right, since personal keys live under Account → Access, and they work on the free plan. With a key in place, the agent tested Monospace's MCP server by hand with curl and found 7 tools. It then wrote a project-level .mcp.json that reads the key from the file at runtime, so the key isn't stored in the config either. Claude Code needed a restart to load the new MCP server.
The hello world: a correct answer
The answer matched the figures we calculated from the spreadsheets. North had $126,664.06 from paid and shipped orders, and its top three customers were Omar Patel, Mateo Patel and Sipho Dube. The agent stated its date window and which order statuses it counted, showed how the ranking changes if pending orders are included, and cross-checked the result in Postgres.
Monospace can't calculate totals itself (its docs have a page called "No Aggregates"), so the agent pulled the rows through MCP and added them up in a Python script. That's fine for 300 orders, but a bigger dataset would mean moving a lot of rows through the agent's context.
Field-level permissions: blocked by the free plan
Asked for a restricted "analyst" key that can't see customer emails, the agent read the access control docs, built a policy, and tried to create it. Monospace refused:
402 "The requested operation would exceed licensed hard limits" custom_policies: usage 1, hard_limit 0
The agent then queried Monospace's licence API to confirm why. The free Starter plan allows no custom policies, no custom roles and no service accounts. It confirmed nothing had been half-created, and declined to fake the result by hiding the column in Postgres instead, saying that "isn't what you asked for".
This matches Monospace's pricing page, which lists row/column-level security, service accounts and custom roles and policies as Business-plan features. But it means the features Monospace leads with, per-agent identities and field-level rules, can't be tried on the free self-hosted version without contacting sales. The agent also noted that the licence limits weren't on any docs page it read. It only found them through the API, after being refused.
A live write: done
Marking order 1001 as refunded worked first time, through the MCP server's update_item tool. The agent read the order back through Monospace, confirmed the change in Postgres, and recalculated the earlier revenue figures to account for it.
What it took
| Human step | Why |
|---|---|
| "It's the one at monospace.io." | The agent's search for Monospace found only fonts |
| Admin account, licence agreement, workspace (7m 27s) | Expected; a person has to accept the licence |
| Create an API key in the UI | Agents can't create their own key |
| Restart Claude Code | Needed to load a newly added MCP server |
The whole session took about an hour and a half, including our steps. The agent never used Monospace's agent skills plugin, SDK or CLI. It skipped the skills plugin because "it wasn't needed for this".
What Monospace can do about it
Let people try governance without a sales call
Per-agent identities and field-level rules are Monospace's main selling point. A trial licence that a developer can get without contacting sales, or a small allowance of custom policies and service accounts on the free plan, would let agents demonstrate them.
Document the free plan's limits where agents look
Put the Starter limits (0 custom policies, roles and service accounts) in the docs next to the access control and API key pages, so an agent can tell a user before it builds a policy that can't be saved.
Add request examples for the API calls agents need
Creating a data source and writing a policy were the two places the agent had to guess. One complete example request for each would remove most of the trial and error.
Make the API keys page point to personal keys
On the free plan, the prominent API Keys page leads to a paywall, while the working option is under Account → Access. A link from one to the other would save the confusion.
What this means for Monospace
Monospace has done more agent-specific work than most products we audit. It has an MCP server, llms.txt and llms-full.txt, Markdown docs, an OpenAPI spec on every instance, an agent skills plugin, and an onboarding screen that tells you how to connect Claude Code. Once an agent was connected, it loaded data, answered questions correctly and made live writes, all through MCP.
The problems come before and around that:
- Agents can't find it. It never came up from a description of the problem, only when searched by its own tagline, and the agent recommended Directus for its job in one test.
- Agents mix it up with Directus and fonts. Without the domain in the prompt, the agent either couldn't identify it or priced Directus instead.
- Its main features are paywalled. Field-level permissions and agent identities can't be tried on the free plan.
The first two are fixable with content, such as pages built around the problems agents get asked about, clear "Monospace from Directus" naming, and the key facts on the homepage. The third is a pricing decision, but documenting the limits would at least stop agents and developers from running into them by surprise.
Want help understanding and fixing the AX of your own technical product or platform? At Ritza our Engineering Writers work at agent speed with human-expert verification (no slop) to win at GTM.