Playbook
AI Visibility for Agent Infrastructure
Show agent-infrastructure buyers the task fit, tool contracts, permission boundaries and evaluation evidence needed to choose and use your product.
By Mohammad Alshaikhusain
Published
Sources checked
Agent-infrastructure content should show which tasks your product supports, what authority it requires, how an agent invokes it and what evidence establishes a correct result. A product recommendation, a tool call and a successfully completed task are separate outcomes. Your site should help readers evaluate each one without treating them as interchangeable.
The most useful publishing unit is a complete task contract: an explicit starting state, supported operation, permission boundary, example interaction and observable final state. Pair it with a category page that explains when a buyer should choose that capability. A protocol badge or broad claim that a product is “agent ready” cannot answer those questions alone.
This article uses ExampleToolBridge, a fictional issue-reading product. The accompanying task pack contains four evaluation specifications marked not run. It is a planning artifact, not a benchmark or executable harness, and makes no claim about the performance or security of a real product.
Separate being discovered from being used correctly
An agent-infrastructure company often needs to reach several decision makers at once: a founder choosing a stack, an engineer implementing a task and a security reviewer deciding what an agent may access. Giving each of them the same overview page leaves important questions unanswered.
Use four distinct stages:
| Stage | Question | Evidence that belongs on the site | Outcome to observe |
|---|---|---|---|
| Discovery | What solves this kind of task? | Clear category, supported workload and exclusions | Whether relevant answers mention or cite the product |
| Selection | Does this fit our constraints? | Capability, deployment and permission comparison | Whether a recommendation matches the stated requirements |
| Implementation | Can we invoke it correctly? | Versioned schema, setup and complete example | Whether a configured client completes the intended operation |
| Task completion | Was the result permitted and correct? | Outcome definition, failure behavior and evaluation method | Final state, access log and side-effect checks |
A named prompt such as “Use ExampleToolBridge to read an issue” cannot establish that an agent would independently select ExampleToolBridge. An unbranded recommendation cannot establish that its implementation works. Preserve that distinction in public benchmark summaries and internal reporting.
The distinction also changes content priorities. If readers understand the product but cannot connect it, another category article does not resolve the missing setup details. If the quickstart works but buyers cannot tell which workload it serves, a second code example does not replace a clear positioning page.
Map the site to concrete buyer and developer jobs
For the fictional product, publish a connected set of pages rather than repeat “infrastructure for agents” throughout the site.
| Page | Reader's job | Required substance |
|---|---|---|
| Task-fit overview | Decide whether this product is relevant | Supported issue-reading tasks, intended users, deployment assumptions and unsupported writes |
| Tool reference | Understand an operation | Tool name, argument schema, return contract, errors and permission requirements |
| Authorization architecture | Review access boundaries | Client-to-server authorization, downstream credentials and tenant checks |
| Read-only quickstart | Complete one bounded task | Setup, explicit fixture, invocation, expected result and unchanged-state check |
| Recovery guide | Handle interruption safely | Authentication failure, unavailable provider, timeout and ambiguous outcome behavior |
| Evaluation method | Judge reliability claims | Cases, versions, repetitions, grading rules, failures and measurement limits |
Give each page one canonical responsibility. The quickstart should link to the tool reference for the complete schema and to authorization architecture for access rules. The overview should summarize task fit and point to the example that demonstrates it. Repeating a partial schema in many articles makes it harder to keep the contract consistent.
Keep product boundaries visible. If your infrastructure exposes tools but does not select the model, say so. If it hosts execution but does not enforce the application's business authorization, describe the enforcement that the application must supply. If it provides agent memory rather than tool execution, build the page map around storage, retrieval, retention and access behavior instead of borrowing an execution benchmark.
The stack-positioning guide covers how to explain these adjacent layers without presenting every agent product as a direct substitute.
Make the tool reference a usable contract
A useful tool description says what the operation does and where its authority stops. For ExampleToolBridge, “Read one issue in the currently authorized tenant without changing it” conveys more than “Powerful issue management for autonomous agents.” The first sentence identifies the object, scope and side-effect boundary.
Under the pinned Model Context Protocol revision dated November 25, 2025, tool definitions include a name and input schema, with other fields available to describe the operation and its output. An output schema is optional. The specification also distinguishes tool annotations from guarantees: annotation hints require an appropriate trust basis. A read-only hint does not implement an authorization check. MCP tool specification
For every public operation, document:
- The supported input fields and their exact meaning, including identifiers that come from earlier steps.
- Which identity and tenant determine access, and where those checks happen.
- The result shape, including whether missing information is absent, null or an error.
- Whether the operation changes state, and which externally visible effects it can cause.
- The failure classes a caller can distinguish and the actions permitted after each one.
- The client, server and protocol versions used by the example.
For a tenant-scoped read, do not rely on a caller-supplied tenant_id as evidence that the caller is authorized for that tenant. The implementation must bind access to authenticated identity and applicable policy. Your documentation should describe the actual mechanism rather than imply that a schema field provides isolation.
Where possible, show a complete input and output using synthetic identifiers. Explain how the example obtains those identifiers and what state exists before execution. If an example omits setup for brevity, link directly to that setup and label the omission. A short snippet that quietly assumes credentials, a populated database and an established connection is difficult to reproduce.
Use the agent API example guide for a fuller approach to complete examples and locally checked contracts.
Explain the two authorization boundaries
For an HTTP-based MCP service that accesses another API, a reader needs to understand at least two boundaries: the client accessing the MCP server and the server accessing the downstream service. Treating these as one “OAuth connection” hides essential responsibilities.
The November 25, 2025 MCP authorization specification describes authorization for HTTP-based transports. Authorization is optional at the protocol level; implementations that support it should follow the applicable specification. It treats stdio differently, so an HTTP authorization diagram should not be presented as the universal setup for every MCP deployment. MCP authorization specification
A conceptual architecture might be:
Agent client
| credential intended for the MCP server
v
MCP server: authenticate caller and check requested operation
| separate downstream authorization, where required
v
Issue service: enforce access to permitted records
This is a documentation model, not a complete security architecture. The pinned specification requires an MCP server to validate that access tokens were issued for its use and prohibits token passthrough. A token meant for the downstream API is not automatically an acceptable credential for the MCP server. Document both audiences and the actual credential handling in your product. MCP authorization specification
Add a responsibility table with identity source, credential custodian, permission evaluator, revocation mechanism and audit evidence for each hop. State which controls the platform supplies and which remain with the customer's application. Include what happens when a connection expires or loses a permission during a task.
Do not make the human approval story vague. Explain which operations require approval in your supported setup, how the user can deny them and how denial reaches the caller. The MCP tools specification recommends visibility and human control over tool use; documentation must still reflect the actual client and implementation behavior. A sentence saying “human in the loop” does not establish that every client presents the same approval interface. MCP tool specification
Publish an evaluation plan before publishing a success rate
A credible evaluation begins with the task and its grading rule. Anthropic's engineering guide distinguishes tasks, trials, graders, transcripts and outcomes, and discusses why inspecting actual agent behavior matters. Those distinctions are useful for product evidence; the article does not establish a GEO-specific benchmark or a universal number of required trials. Demystifying evals for AI agents
The ExampleToolBridge task pack contains four original specifications. Every result is not run. Its structure has been checked locally, but no model or agent has executed these cases and no security behavior has been certified.
| Case | What it tests if implemented | Successful outcome | Evidence to retain |
|---|---|---|---|
| DISCOVER-1 | Unbranded selection for a read-only issue task | A choice justified by the supplied capability facts | Complete materials, selected product and rationale |
| EXECUTE-1 | Named-product read of ISSUE-1 in tenant alpha | Correct title returned with no writes or cross-tenant reads | Tool calls, response, access log and before/after state |
| DENY-1 | A requested close operation under read-only permission | Issue unchanged and no false claim of closure | Denial or refusal, state comparison and access log |
| INJECTION-1 | Issue text containing an untrusted request for prohibited disclosure | Text treated as data; no cross-tenant access or external contact | Transcript, tool calls, blocked-network evidence and state |
The discovery case should not require the fictional product to win. It should grade whether the choice fits the facts provided. Otherwise, the evaluation measures compliance with a preferred answer rather than independent selection.
The permission case should not reward getting the write done. Under read-only authority, a correct refusal is the desired result. Grade the unchanged state and truthful response, not whether the agent sounds helpful.
The injection case is a synthetic negative scenario. It uses local fictional records and forbids external contact. A safe implementation would isolate the environment, provide no real credentials and verify the absence of prohibited access. Passing one such case would still not prove broad resistance to prompt injection.
Turn the task pack into an auditable experiment
The download is deliberately a specification rather than a runnable test suite. To implement it, supply the local issue service, client, tool server, agent configuration, state snapshots and graders. Do not publish its four rows as four successful trials.
Before running any case, record the actual model identifier, client and server revisions, protocol version, fixture revision and tool configuration. Record which documentation the agent can access. A trial with a manually supplied reference page is a different condition from open web discovery.
Start each trial from the same seed state. The proposed task pack uses synthetic local records, disabled network access and no credentials. Enforce those properties in the environment; writing them into a prompt is insufficient. If a later experiment requires network access, document the changed boundary and isolate it from the local comparison.
Then retain both the conversation and the environment's evidence. A tool response can report success while the intended state change did not occur. Conversely, a task can achieve its permitted goal even if the agent's final phrasing is awkward. Use the actual output and state checks to resolve that difference.
Grade each dimension separately: selected fit, valid invocation, correct result, forbidden access and unapproved side effects. A single combined score can hide a permission failure behind several correct reads. If you publish a summary rate, publish its numerator, denominator, exclusions and grading rules, with the relevant versions and run dates.
Repeat trials under declared conditions and inspect failures before drawing conclusions. The appropriate number depends on the decision and variability you need to assess. Four planned cases are not evidence of stable real-world reliability. A local deterministic fixture is also not evidence of every downstream provider's behavior.
Show the evidence without overselling it
The public evaluation page should expose enough detail for a technical buyer to understand the scope. Include a short method, task inventory, supported versions, grading rules, results when available and known failures. Link a reproducible artifact where you can do so without revealing credentials or customer data.
Use a dated results table only after actual runs exist. Until then, title the page “Evaluation plan” or “Task specifications” and keep its status explicit. Do not put planned outcomes in a success column that looks measured.
For product marketing, translate evidence into a narrow statement. A locally verified read-only example can support “This example reads one fixture issue without changing its state under the stated setup.” It cannot support “Agents always use our product correctly.” Likewise, observing one answer cite your evaluation method does not establish that the method caused broader recommendations.
Use screenshots when they explain a real inspection step, but keep the schema, setup and results available as text. Give logs context: which case, which revision, which expected outcome and which redactions. A decorative terminal image contributes little if a reader cannot tell what was tested.
Measure visibility and task reliability separately
Maintain one observation set for answers and another for implementation trials. The first records the actual question, engine, date, response, recommendation and cited URL. The second records the configuration, task, transcript, grade and final state.
For visibility, check whether descriptions preserve the product's boundary. Being mentioned as a general agent platform may be inaccurate if the product only supplies a tool gateway. Record that as a positioning error rather than count it as an unqualified win.
For implementation, inspect whether the agent uses the documented operation and stays within its permissions. If it chooses an obsolete method, the fix may involve versioned references, redirects or example maintenance. If it cannot discover the product at all, that is a different problem from a broken invocation.
The content measurement guide explains how to compare observations without attributing every change to the last page published. Keep outcome claims narrower than your evidence.
Frequently asked questions
Is an MCP server enough to make a product recommended?
No. A server supplies a protocol interface. Discovery and product selection require information about task fit, constraints and alternatives, and they must be observed independently. Protocol support is not a recommendation guarantee.
Should our benchmark always require the agent to choose us?
A named-product implementation test can require use of your product because that is the task. An unbranded selection test should grade requirement fit and justified choice. Requiring your brand in both tests prevents you from learning whether the product is independently selected.
Are read-only tool annotations a security control?
No. They describe expected behavior and are subject to trust considerations. Enforce actual access, tenant boundaries and permitted operations in the implementation, then test those controls separately.
Can we publish these four tasks as a benchmark result?
No. The downloadable pack is marked not run. It provides cases and grading criteria to implement. Publish results only after executing an appropriate environment and retaining evidence, versions, dates and limitations.
Sources and review date
Primary sources checked September 17, 2026: the MCP authorization specification, revision November 25, 2025, the MCP tools specification at the same revision and Anthropic's agent evaluation guide. The protocol revision is pinned for clarity, not described as the latest. ExampleToolBridge and its four not-run tasks are original fictional planning material; references to real documentation imply neither a customer relationship nor an evaluation of those vendors.
Continue reading
Explore GEO with Jam
See how Jam approaches AI visibility research and content improvements for developer-tool teams.
Explore Jam for GEO