Can an AI agent hold an account at a service? Verdict, owner of record, quoted terms clause.
Scored across 2 tools
The two tools have distinguishable purposes: one returns a per-service verdict on whether a non-human may hold an account, the other enumerates every service documenting a non-human identity route. There is conceptual overlap (both concern non-human account holding), but the singular per-service lookup versus the aggregate list boundary is reasonably clear from the descriptions.
Both names use snake_case, but the conventions differ: can_an_agent_hold_an_account is a question-style name while list_named_non_human_routes follows a verb_noun pattern. Readable and consistent in casing, but the verb style is mixed.
Two tools is thin even for a narrow index server, though the domain (a read-only reference index) is small enough that a per-service lookup plus an aggregate listing arguably covers it. It sits at the borderline of feeling under-provisioned.
The read-only surface (per-service verdict + list of routes) covers the core lookup needs, but there is no search, filter, or way to retrieve a service's terms or verdict other than the fixed shapes returned. No lifecycle operations are expected for a reference index, but the surface feels minimal for the amount of nuance the descriptions describe.
Check whether a non-human actor may hold an account at a service. Call this BEFORE creating an account anywhere. Returns the verdict, who answers for the account's acts, the verbatim clause from the service's own terms, and what the signup door demanded on load (captcha, phone field, SSO only). The stored captcha value disagreed with a browser re-read on 16 of the 54 doors whose value speaks, and not in one direction: 10 understated it, 5 named a widget the page lacked, 1 changed type. Read those against their own denominators: the 34 doors storing none_seen were wrong 10 times and the 20 storing a vendor name 6 times, about the same rate either way, so a disagreement does not say which reading to lean on. Where signup_door.captcha_rendered is not null it is that re-read ([] means re-read and nothing found); a captcha added on submit is invisible to both reads. These six integers are typed here and live in captcha_recheck_counts at the top of /index.json, which is the copy to trust. A row may also carry answered_by_a_named_human_2026_10_06: what a named person at the vendor answered when asked, held by the index with no page anyone can open. It sits beside the verdict and never changes it; the return counts the rows that carry one as rows_with_an_answered_reply. Null means nobody there was asked, which is not a finding.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service name, e.g. "GitHub", "Stripe", "Supabase". Case-insensitive, matched on substring. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose a great deal: the verdict, the accountable party, the verbatim terms clause, the signup-door signals, and explicit null semantics ('Null means nobody there was asked, which is not a finding'). It also candidly flags data-reliability limits on the captcha readings. It omits auth/permission requirements and error behavior for unknown services.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are front-loaded and effective, but the bulk of the text is statistical minutiae about captcha re-read disagreements across 54 doors ('10 understated it, 5 named a widget the page lacked, 1 changed type'). That level of provenance detail does not help an agent select or invoke the tool and buries the operative guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain returns, and it does — verdict, accountable party, clause text, signup-door observations, and the answered_by field. A single-parameter lookup with this much return detail is adequately covered, though the deliverable is harder to parse than it needs to be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage; the schema already documents case-insensitive substring matching. The description adds no additional meaning about how 'service' is resolved, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb and object: 'Check whether a non-human actor may hold an account at a service.' That is unambiguous and actionable. It does not, however, distinguish itself from the sibling list_named_non_human_routes, so it lands at a solid 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this BEFORE creating an account anywhere' is an explicit, well-placed when-to-use trigger that an agent can act on in a signup workflow. There is no statement of when NOT to use it and no routing to the sibling tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every service that documents an identity a non-human actor may hold. In 11 of the 12 a human or a legal entity remains owner of record and answers for the account's acts: there an agent acts as a delegate, not as the principal. 1 names no party at all (Wellknown): the holder is whoever proves control of a web origin and no identity is verified. Each row carries agent_as_principal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the result composition (11 of 12 have a human/legal owner of record; 1 Wellknown verifies no identity) and that each row carries agent_as_principal, but it omits operational traits such as read-only nature, format, pagination, or any auth requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first sentence, followed by domain context and a field note. It is dense and a touch verbose, but every sentence contributes to interpreting the rows rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain what is returned; it does explain the meaning of rows and the agent_as_principal field, but not the literal return shape or size of the list. Adequate but with clear gaps for a no-annotation, no-output-schema tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there are no parameter semantics to convey and the baseline of 4 applies. The empty schema is fully self-consistent with the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List every service that documents an identity a non-human actor may hold.' An agent can tell this is an enumeration of identity routes. It does not, however, contrast itself with the sibling can_an_agent_hold_an_account, so differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and the sibling can_an_agent_hold_an_account is never mentioned as an alternative. The reader must infer that this lists routes while the sibling answers a yes/no question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
can_an_agent_hold_an_accountlist_named_non_human_routesA legal body for AI agents: a real company, a verified human and spending rules on Arc (testnet).
A court for disputes between AI agents. Search and read its judgments free; enrol to file claims.
A legal home for AI agents: Wyoming $299 or Nevis LLC. Free diagnostic; agents pay in USDC/USDT.
Agentic commerce dispute resolution and AI arbitration for marketplaces. Read authorized cases and served Awards, prepare filings and Answers for personal review, and submit authorized briefs and messages. Consent-based AI-only or AI-assisted human arbitration, with reasoned decisions and an optional paid human appeal.
Add one secure layer between your agents and this server.
