SelfOperate Tools

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 so well: it discloses that only public facts are checked, no registrant or personal data is returned, billing occurs only when the domain resolves, and the cost is $0.05 per call via x402. It also explains what the response contains, including signals, sources, fetch times, and warnings.

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 description is front-loaded with the core action and then succinctly covers checks, output, privacy, billing, and cost. Every sentence adds operational value, and the dense formatting is appropriate for a verification tool.

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?

There is no output schema or annotations, so the description must carry the full context, and it does: it explains what is checked, what is returned, privacy boundaries, charging conditions, and cost. An agent has enough information to decide whether and how to call it.

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?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description mentions giving a domain and optionally a name, and that the name is checked on the site, but this largely repeats the schema rather than adding new parameter semantics.

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 description states a specific verification action and enumerates the checked resources: domain age, email setup, HTTPS/certificate, and name presence. It also clarifies the output is a trust score, so the tool's purpose is clear. It does not explicitly differentiate itself from siblings such as site_check or page_brief, which keeps it from 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?

The description implies the tool is for verifying a business domain and optionally its name, but it does not explicitly say when to use it versus alternatives or when not to use it. The usage context is inferable from the checks and trust score, but there are no exclusions or sibling comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full burden and does so well: it discloses x402 billing at $0.15 per call, that charging only occurs when a business or domain is found, that hours appear only if published, that unknown fields return honest 'not found', and that no personal data is included. These are exactly the operational facts an agent needs before spending money.

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?

Front-loaded with the purpose, then a dense but purposeful enumeration of returned fields and the billing caveat. Every clause carries information; the long return list could be tightened but nothing is filler.

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?

There is no output schema, and the description compensates by enumerating the return payload, including provenance (source, date, confidence) and the 'not found' behavior. Cost, payment mechanism, and privacy scope are all covered, leaving little an agent would need to guess.

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?

Schema coverage is 100% with clear per-field descriptions, so the baseline is 3. The description adds real value beyond the schema by stating the parameters are combined ('name and city/state and/or a website'), which clarifies that this is an identifier-resolution input even though required is empty.

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 resource (a dossier on a US business) and enumerates exactly what comes back, so an agent knows this is an enrichment/lookup tool rather than a bare lookup. It never names a sibling like business_verify or local_business_profile, so the differentiation from those is left to inference.

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?

'from a name and city/state and/or a website' tells the agent what inputs to combine but not when to prefer this over business_verify or local_business_profile. Usage is implied by the input shapes rather than stated as a when-to-use rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses US-only scope, per-call pricing of $0.03 via x402, and that billing only occurs on a match — all behavior an agent cannot get from the two-property schema. It omits rate limits and the exact failure shape when nothing matches, which keeps it short of a 5.

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?

One front-loaded sentence that puts purpose first, then output inventory, then verification behavior, then pricing — a sensible order with almost no filler. The clause listing returned fields is long but each element is a distinct output the caller would want to know about.

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?

There is no output schema, so the description responsibly enumerates the returned fields, the cross-check/conflict/confidence verification block, and cost. The main remaining gap is what is returned when no match is found, given that billing depends on a match.

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?

Schema coverage is 100%, so both parameters are already documented, and the description largely restates them. It adds marginal value by clarifying that 'place' accepts a city/state or ZIP and that matching is 'best match' fuzzy rather than exact, but that is a small increment over the schema.

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: a US business enrichment lookup that takes a name plus city/ZIP and returns a best match with contact, category, health score, and a verification block. That output inventory implicitly separates it from business_verify and nearby_businesses, but no sibling is named so the differentiation is inferred rather than explicit.

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?

The description tells the agent how to invoke it ('give a business name and a city or ZIP') and limits scope to the US, which implies the use case. It never says when to prefer this over business_verify or nearby_businesses, or what to do if no match is plausible, so the routing guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden well: it discloses ordering (nearest first), result cap (up to 50), radius cap (10 km), billing behavior (“charged only when at least one is found”), and cost ($0.03 per call, x402). It could add more about auth/rate limits or error behavior, but the key behavioral traits are transparent.

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 description is a dense, front-loaded paragraph that states purpose, return fields, ordering, limits, category examples, and billing in minimal space. Every sentence earns its place with no filler.

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?

There is no output schema and no annotations, so the description appropriately explains return fields, ordering, limits, and billing. It does not clarify that all parameters are optional or what happens for invalid categories/locations, which is a minor gap for a discovery 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?

Schema description coverage is 100%, so the schema already documents all six parameters. The description adds useful category examples and clarifies location formats, but it does not add much beyond what the schema provides.

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 description states a specific resource and scope: businesses of one category near a US city, ZIP, or coordinates, with a clear list of returned fields. It is distinguishable from siblings like business_verify or site_check, but it does not explicitly name or differentiate against those siblings.

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?

Usage is implied by the description (find nearby businesses by category and location), but it never states when to use this versus alternatives such as local_business_profile or business_verify. No exclusions or prerequisites are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 it well: it discloses that fetching is live, robots.txt is respected, login-walled pages are skipped, billing occurs only when the page could be read, and cost is $0.03 per call via x402. Those cost and failure-mode details are exactly what an agent needs before invoking a paid external fetch.

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?

Two sentences, front-loaded with the core action and then the return payload, with no filler. The second sentence packs several clauses (billing, pricing, robots.txt) into a dense run-on, which slightly hurts scanability but not comprehension.

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 describe returns, and it enumerates every component of the payload plus the health-score structure. Combined with the fetch behavior and pricing disclosures, an agent has enough to decide, call, and predict cost.

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 and the schema already documents it at 100% coverage ('Public http(s) URL of the page'), so the baseline is 3. The description's only additional signal is the implicit constraint that login-walled pages are skipped, which reinforces rather than extends the schema.

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 precise verb+resource ('give a public URL; get the page as clean markdown') and enumerates the returned artifacts: markdown, title, description, language, word count, health score with top issues, and security headers. That is far clearer than a name restatement, but it never names or contrasts with the overlapping sibling site_check, so it falls short of full sibling differentiation.

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?

The 'give a public URL' framing implies usage, and constraints (live fetch, robots.txt respected, login-walled pages skipped) effectively define when the tool will not work. However, there is no explicit guidance on when to choose this over site_check or business_verify, which an agent would need given the health-score overlap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well: it discloses the enumerated check set, the return shape, and notably the cost model ($0.02 per call, x402) an agent needs before invoking. It stops short of stating error behavior or rate limits, and never explicitly says it is read-only.

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?

Three tight sentences: purpose first, then return value, then the check inventory and cost. No filler, and the cost notice is placed where it will be read before invocation.

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, yet the description explains the return value precisely (score plus ranked issues with finding, rationale and fix) and warns of per-call cost. Nothing essential for a correct call is missing.

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?

Only one parameter and the schema documents it at 100% coverage ('Public http(s) URL of the site to check'), so the description's 'any public URL' adds little beyond it. Baseline 3 is appropriate given the schema does the work.

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?

Names a specific resource and purpose (website health, search-visibility and conversion check) plus a concrete scope ('any public URL') and describes the deliverable (0-100 score, ranked issues). This is clearly distinguishable from siblings like business_verify or page_brief, which address different resources.

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?

The phrase 'for any public URL' sets scope and the check list implies when the tool is relevant, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative. Usage is inferable rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.