What a publisher owes someone else's agent

2026-11-02

The Australian Signals Directorate published Agentic AI Harnesses in September 2026. It is written for organizations adopting agents. An MCP server appears in it as a part of somebody else's system, a row in the connector layer or the tool registry, and a site that agents read appears as content a model processes. ASD gives publishers no instructions, so the question of what they owe that system is my reading of the guide. The duties I can point to come from the MCP specification, and I measured them on one server, my own. ASD has no connection with turva.dev and has not endorsed this post.

Key figures

• 11 components in ASD's list. The connector layer row names MCP-enabled tools, and the tool registry row warns about poorly defined tools.
• 4 things the MCP tools page says a server must do: validate inputs, implement access controls, rate limit invocations and sanitize outputs.
• 15 427 bytes for the tool list of my own server, read on 2 November 2026, for five tools that take no arguments.
• 64 characters is where that server cuts an unknown tool name in an error. An unknown argument key of 2 000 characters came back whole in version 1.7.1.

What the guide asks of the operator

The audience is named at the start of the guide: executives, security chiefs and IT leaders in organizations adopting or considering agentic AI. Its subtitle calls the subject the layer above the model, and I use that phrase here. The guide's argument is that this layer is what an organization can govern, so the controls belong there.

Three passages describe a publisher from the outside. Each tool, data source or connector the operator adds is a new path into the system. Content a model processes can read to it as an instruction, web pages and documents included, and ASD says no fully reliable technical mitigation for that exists yet. The good practice list then tells the operator to validate tool parameters and outputs and to keep context focused on the task.

What MCP asks of the server

The tools page of the 2026-07-28 revision has a security section with a list for each side. Servers must do the four things in the figures above. Clients should ask for confirmation on sensitive operations, validate results before they reach the model and log tool use.

The same page rules out the easy answer. On annotations it says "clients MUST consider tool annotations to be untrusted unless they come from trusted servers". The schema reference adds that they are hints with no guarantee of describing the tool faithfully.

That narrows my question. A publisher cannot make somebody else's agent safe, and a flag proves nothing to the client that reads it. What a publisher can owe is accuracy and few surprises, so that the operator's controls have something true to work on.

The material, item by item

Tool names

MCP recommends names of 1 to 128 characters, drawn from ASCII letters and digits plus a few punctuation marks. Uniqueness covers one server only. The page's own example of a collision is two servers that each expose a tool called search, and clients that aggregate servers should disambiguate.

A publisher owes a name that says what the tool acts on, because the name will sit next to tools from servers it has never seen.

Schemas

ASD tells the operator to validate tool parameters and outputs, and an operator can validate only against what you publish. outputSchema is optional in MCP, and a tool without one leaves the operator nothing to check a result against.

A publisher owes an input schema that refuses what the tool does not read, an output schema where the result has a stable shape, and a server that enforces both.

Descriptions

MCP calls a description human-readable. The same page also asks servers for a deterministic tool order, because that helps prompt caching when tools are included in model context. I read that as the specification allowing for these sentences to reach a model. A description is then text from you to a model you will never see.

Say what the tool does and when it fits, and stop there. Nothing about other servers' tools, the operator's policy or what the user wants belongs in a description. Length is a cost charged to someone else's context, and my own five descriptions total 3 174 bytes.

Read-only signals

The defaults in the schema reference are cautious. A tool with no annotations reads as modifying its environment, possibly destructive, not idempotent and open to outside systems.

A publisher owes flags only where they are true, and a way to check them, such as public source or a published test. The operator still owes itself the assumption that a flag can be wrong.

Errors

MCP separates protocol errors from tool execution errors, and it says clients should give tool execution errors to the model so that it can correct itself. That makes the text of an error model context.

A publisher owes an error that says what to change, with a limit on anything in it that the caller or a third party wrote.

Outputs

The requirement to sanitize tool outputs is one line, and the tools page gives no method. ASD's statement about mitigation applies here too. A tool that returns a customer review, a ticket body or a fetched page returns text a stranger wrote, and I know of no filter that makes such text safe.

My suggestion, which neither ASD nor MCP makes, is to keep third-party text in named fields and to say in the output schema which fields those are, so that the operator can route them differently.

Changes

ASD lists the path through updates and the supply chain as a component of its own. As I read it, a reworded description can reach the operator's model with nobody on their side approving it, unless they compare the list themselves. MCP gives servers ttlMs and cacheScope for caching and listChanged for notifications, and none of them says what changed.

Give a definition a new version whenever it changes, and keep a record of the change that a person can read. An operator can then hash the tool list and notice a difference.

A site, when there is no server

I have no measurement for this section, so it is reasoning only.

Web pages come first in ASD's list of content that can read as an instruction. A site owes its agent-facing version the same text a person sees, because a person can review only what they can read. Text aimed at agents and hidden from people is the opposite of that. A page that republishes comments or reviews has the problem from the outputs section above.

One sample: my own server

I read turva-mcp at mcp.turva.dev/mcp, version 1.7.1, on 2 November 2026. It is one sample and it is mine, so it compares with nothing. The case is also an easy one: five tools, no arguments and data compiled into the server. With no write tool, no login and no third-party text passing through, the server cannot show the hardest items above.

Four of these readings count against version 1.7.1 or limit what it can prove.

First, the echo. The server cut the unknown tool name at 64 characters and returned the unknown argument key whole, and the whole key came back in a tool execution error, the kind MCP says clients should give to the model. The risk was small, since the caller got its own text back. I found the gap while measuring for this post.

Updated 2026-11-02. Version 1.7.2 cuts an unknown argument key at 64 characters and lists at most five keys. The table above keeps the 1.7.1 reading.

Second, size. Fifteen kilobytes is more than I want an operator to pay for five tools with no arguments. How much of it reaches a model depends on the client, and I measured no client.

Third, all five descriptions carry a sentence telling a model when to use the tool, and the instructions field adds more. Those are my sentences addressed to your model. I think they are honest, and you have the public source to go on and little else.

Fourth, the flags. All five tools say read-only, in the annotations and again in the description text. The specification tells you not to rely on that, and reading the source still leaves you to accept that the deployed code matches it.

turva.dev scored 100/100 Level 5 with the isitagentready.com scanner, and both runs on 2 November 2026 passed every scored check. The scanner's MCP row reads the fields of the server card. That is a discovery check, and it says nothing about any reading in this section.

What this does not say

ASD does not state any of the duties above. They are my reading, and the MCP lines are the only normative text behind them.

It does not say that a server meeting them is safe to connect. The operator's controls stay where ASD puts them.

It does not rank anyone. I read one server and no client, and I tested neither rate limiting nor access control.

Method

The ASD guide comes from text extracted from its PDF, and the publication date of 11 September 2026 from ASD's news page. The MCP tools page and schema reference of revision 2026-07-28 come from the extracted pages.

For the server I made my own requests, one at a time, with every raw response saved. I listed the tools three times within five minutes, called each tool with no arguments, then sent an unknown argument key and an unknown tool name at short and long lengths. A first round of tool calls failed on a header that my own script left out, and I do not count it. Byte figures are UTF-8 bytes of the raw response or field. I ran the scanner twice with its default profile on 2 November 2026 and both runs read Level 5.

Related

• MCP server cards and discovery
• Define what an agent may do with your data