An API can now be called by a coding agent working alongside a developer—or by an outside agent acting for a user. That changes the practical question from “How do I connect an agent?” to “Which operations may it call, what can it control, and how will we review that permission?” Nikolas Dimitroulakis makes that case in “Your API’s newest users are agents…”. His proposed workflow reuses requests and tests a team already trusts instead of maintaining a separate, hand-written description of the same API. It is an engineering account, not evidence of a measured industry-wide increase in agent traffic.
Why an agent changes the API access question
Traditional API tools often assume a developer is manually composing requests, inspecting responses, and deciding what to try next. An agent can do those things too, but it may also act on a person’s behalf. Giving it an API credential or a broad set of operations therefore creates a permission decision, not merely a new integration task.
Dimitroulakis’s central point is that this is not solved just by adding an MCP server. If the team’s tested API requests live in one place while an MCP server contains its own schemas, authentication wiring, and operation definitions, the two descriptions can drift. The author summarizes the goal as “One description of the API, instead of three that slowly disagree.”
The right boundary depends on who the agent is and what it is allowed to do. Dimitroulakis distinguishes a developer’s own coding agent, an outside agent with limited access, and testing an MCP server. These cases have different trust assumptions and failure consequences.
#1 Best Overall
For a developer’s own coding agent: let it inspect real requests
In the article’s example, a checkout request returns HTTP 400. Without access to the project’s existing requests, a developer might paste an error or curl command into a chat and let the agent guess which headers are missing, then explain where a token belongs. Dimitroulakis describes using Voiden so the agent can list, run, and inspect requests already in the repository. The request reaches the real endpoint, and the agent can inspect the actual response to locate the missing header.
The author says this is enabled for the whole project by default in his workflow because the trust boundary is the developer, editor, and their own coding agent. That is a judgment about a local development setup, not a safe default for every repository. A project containing production credentials or sensitive data may need a different boundary. Consider which environments and secrets those requests can reach before granting an agent the ability to run them.
For an outside agent: expose only chosen operations and inputs
A support assistant that can issue refunds should not automatically gain access to every operation in the company’s API. A conventional integration may add an MCP server, SDK code, schemas, authentication handling, secret storage, and hosting. Besides the additional work, a separately maintained operation description can get out of sync with the API and its tests.
Rank #2
- Used Book in Good Condition
In Dimitroulakis’s described approach, a team starts from a written and tested request, explicitly marks it as a tool, and chooses which values the agent may provide. In the refund example, the agent can supply an order ID; secrets remain in the environment rather than becoming agent-controlled inputs. The author’s rule is “Nothing is exposed until you mark it.” That describes his workflow, not a substitute for deciding whether the operation itself is safe and properly authorized.
Tests can be used as a gate: in the author’s setup, a tool is available only while its tests pass. A failed test removes it from availability. This favors withholding an operation that has not been verified recently, but flaky tests can also interrupt legitimate access. The article does not specify how an agent is told that a tool is unavailable, so a team adopting this policy should make failure status understandable to both users and operators.
For MCP servers: make calls repeatable and testable
Dimitroulakis describes two testing needs: checking a team’s own MCP server before release and inspecting a vendor’s server before building against it. An ephemeral inspector session or one-off script can help during exploration, but a saved call with assertions can be rerun in CI. The article’s examples include checking that search_orders returns an expected shape and keeping a working reference for Notion’s server; these are examples from the author’s account, not independent claims about Notion’s current capabilities.
For a team’s own implementation, useful checks can cover whether a tool returns the expected structure and whether a change breaks an existing call. Passing tests do not, by themselves, establish that access is appropriately limited or that the operation is safe in every context. Keep permission review and authorization design as separate responsibilities.
Keep requests, tests, and permission changes reviewable
The author’s design principle is to keep the request used for testing, agent execution, tool publication, and MCP testing in one repository file. When a pull request changes which operation is exposed or what values an agent may set, maintainers can see that change in the diff. Dimitroulakis puts it this way: “Permission decisions deserve a review trail.”
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →A review trail helps people notice a widened permission; it does not itself enforce authorization or protect a secret. The article describes keeping secrets in the environment and reviewing changes through version control, but does not claim those measures replace authentication, access controls, or operational safeguards.
How to choose an access pattern
| Situation | Scope to consider | Source of truth | Key risk or trade-off |
|---|---|---|---|
| Developer’s own coding agent | Project requests the developer is comfortable letting the agent run | Existing repository requests and their real responses | Requests may reach sensitive environments or use powerful credentials. |
| Outside agent calling a business operation | Explicitly selected tools and only the inputs the agent needs | Reused, tested requests rather than a second hand-maintained description | Tests can gate availability, but flaky failures can temporarily remove a tool. |
| Testing an MCP server | Saved calls and assertions for the server or vendor tool being evaluated | Repeatable checks that can run again, including in CI | Passing a shape check does not prove that permissions are appropriate. |
These are distinctions in Dimitroulakis’s account, not a universal ranking of architectures. A team should choose the boundary that matches its agent, data, environment, and consequences of a mistaken call.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check protocol requirements separately from the implementation pattern
MCP protocol details evolve, so an older implementation should not be assumed to meet current requirements. The MCP project’s 2026-07-28 specification announcement describes a stateless protocol core and authorization changes, including validating the iss parameter in authorization responses and binding credentials to the issuer that minted them. It also describes changes to discovery and caching. These are protocol-level developments; the article does not establish that Voiden or the described workflow implements this revision. Check the current normative specification for requirements before building or deploying an MCP integration.
The MCP server overview is explicitly draft material. It characterizes tools as executable functions that can let models take actions or retrieve information, including through API requests; treat that overview as explanatory rather than a stable, final requirement. A separate developer tutorial on machine-consumer-friendly APIs discusses discoverability, structured responses, safety, and idempotency, but its simplified schema validation and in-memory store are not production implementations. Its /actions endpoint pattern is an example, not a requirement for every API.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Best Value
What the evidence does—and does not—show
Dimitroulakis writes that “more and more often an agent” is an API caller, but the article and supporting sources do not supply a named statistic measuring the growth or share of agent API calls. Treat the trend as the author’s qualitative observation, not a market-wide figure.
The article describes ApyHub as a catalog of utility APIs and says it funds Voiden, an open-source API tool the author works on. Those are descriptions attributed to the author, not an independent evaluation of either product’s current capabilities. The article’s useful engineering question remains: how are you deciding what agents can touch in your APIs today?
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
