OmniForce

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

Annotations only declare readOnlyHint=true; the description adds real context by disclosing the contents of the payload (plan tier, allotments, usage, upgrade tiers), which matters because there is no output schema. It stops short of noting auth or tenancy requirements, but for a zero-argument read-only call that is minor.

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?

A single front-loaded sentence with enumerated return contents and no filler. Every clause carries information the agent needs.

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?

For a simple, zero-parameter, read-only status tool with no output schema, the description covers what the agent will receive and the safety profile is already carried by annotations. Only the distinction from omniforce_upgrade as the acting counterpart is left unstated.

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 the standard baseline of 4 applies. There is nothing for the description to clarify or compensate for on the input side.

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 names a specific verb ('Return') and enumerates the exact resources retrieved: plan tier, included allotments, current usage, and available upgrade tiers. There is no explicit sibling differentiation, but the informational scope contrasts implicitly with the action-oriented omniforce_upgrade.

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 rather than stated: the agent can infer this is the read-only status check to run before deciding whether to call omniforce_upgrade. No explicit when-to-use, prerequisites, or named alternative is given, so routing rests on inference.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that: it discloses the return shape ('evidence-based score with per-dimension findings') and an auth fact ('No API key required'). It does not mention runtime, rate limits, or failure modes for unreachable URLs.

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 short sentences, zero waste, with the core purpose front-loaded and the output/auth notes kept to the tail. Nothing is padded or restated.

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 carries the burden of describing the return value and does so ('score with per-dimension findings'). A single required param is documented in the schema. Only minor gaps remain, such as expected latency of a scan and whether the score is deterministic.

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% and there is only one required parameter, so the schema fully documents 'url' including its absolute-URL format. The description adds no syntax, format, or constraint detail beyond the word 'website', so the baseline of 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?

States a specific verb and resource: 'Audit a website's AI-search (GEO/AEO) readiness'. This is clearly distinguishable from the sibling list_*/get_* tools, which enumerate stored resources rather than performing an analysis against an input URL.

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 verb ('audit a website') but there is no explicit when-to-use framing, no prerequisite conditions, and no named alternatives among the omniforce siblings. 'No API key required' hints at context but is not usage guidance.

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?

readOnlyHint=true already tells the agent this is a safe read operation, lowering the bar. The description adds the tenancy scoping detail (returns only the authenticated tenant's brand), but says nothing about return shape, permissions, or rate limits.

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?

A single front-loaded sentence with no wasted words. Nothing could be trimmed without losing meaning.

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 carries the burden of conveying what comes back, and it does not describe the brand profile's fields or structure. Adequate for a simple zero-arg read, but a gap remains.

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 zero parameters, so per calibration the baseline is 4. There are no parameters for the description to clarify.

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 ("Return") and resource ("brand profile"), and scopes it to the authenticated tenant. However, it does not distinguish itself from siblings like omniforce_list_competitors or omniforce_list_prompts beyond the noun, and it does not say what the brand profile contains.

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 statement of when to call this versus alternatives, nor any prerequisites. The phrase "authenticated tenant's" weakly implies no arguments are needed, but no usage context is 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?

The readOnlyHint=true annotation already establishes this is a safe, non-mutating read. The description adds one piece of real context beyond the annotation – the results are scoped to the authenticated tenant – but says nothing about result volume or paging behavior, and it does not contradict the annotations.

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?

A single front-loaded sentence with the resource and its scope, and no filler. Nothing in it is redundant or padded, and it can be read in one pass.

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?

For a simple zero-parameter list tool this covers the essentials, and the tenant scoping is useful. However, with no output schema in play, the description leaves the shape and size of the returned competitor list entirely unexplained, which is a gap for an agent deciding how to consume the result.

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 zero parameters, which is the baseline-4 case; there is no parameter syntax or meaning for the description to add. Schema coverage reports 100% of a parameter set that is empty, so nothing is missing here.

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 gives a specific verb ('List') and resource ('competitors') plus scope ('tracked for the authenticated tenant'), which clearly separates it from siblings like omniforce_list_prompts, omniforce_list_reports and omniforce_list_snapshots. It doesn't explicitly name those alternatives, but the resource noun is unambiguous.

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 when-to-use or when-not-to-use guidance, and no alternative tool is named. Usage is only inferable from the noun 'competitors' – an agent must guess the context in which this list is the right call versus, say, omniforce_get_brand or omniforce_geo_scan.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful domain scope by naming the answer engines covered (ChatGPT, Perplexity, Gemini, Google AI Overviews), but says nothing about result volume, ordering, or pagination for a list operation.

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 sentence, front-loaded with the verb and resource, with the engine list appended as useful scoping detail. No filler and nothing to trim.

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?

For a parameterless read-only listing tool, the description covers what is being listed and where the data comes from. With no output schema present, it does not describe what a returned prompt record contains, which is a minor residual gap.

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 zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are needed or missing.

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 verb (list) and resource (queries/prompts OmniForce monitors) and names the scope (across answer engines). It reconciles the tool name 'prompts' with the concrete noun 'queries', and is clearly distinct from siblings like list_competitors, list_reports, and list_snapshots.

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 gives no when-to-use guidance, no prerequisites, and does not name any alternative tool or condition. An agent must infer that this is the entry point for enumerating monitored prompts.

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?

readOnlyHint=true already declares this as a safe read, so the safety burden is lifted. The description adds two pieces of genuine context beyond the annotations: results are scoped to the caller's tenant and only "shareable" (i.e., a filtered subset) reports are returned. It does not disclose ordering, pagination, or emptiness behavior.

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?

A single front-loaded sentence with no filler; the scope qualifier ("for the tenant") is embedded rather than appended as an afterthought. Nothing in it is redundant.

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?

For a zero-parameter read-only list tool the description covers the essentials, but with no output schema it could say more about what a "report" object contains or how the list is ordered/bounded. Adequate but with a visible gap around return shape.

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 zero parameters, which is the baseline-4 case: there is nothing for the description to clarify about inputs, and no ambiguity is introduced.

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 gives a specific verb ("List") and resource ("shareable visibility reports for the tenant"), so the agent knows exactly what it retrieves. It does not explicitly differentiate itself from the other list siblings (competitors, prompts, snapshots), though the resource noun is distinct enough to separate them in practice.

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 statement of when to use this tool versus the sibling list tools (list_snapshots, list_prompts, list_competitors), nor any prerequisite or exclusion. Usage is only implied by the verb "List".

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?

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds only scope ('recent') and temporal context ('over time'), with no details on ordering, pagination, or auth requirements.

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?

A single front-loaded sentence with no wasted words. It is appropriately terse for a simple list tool, though the dash phrase partially restates the resource rather than adding new information.

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?

For a low-complexity list tool with one fully documented optional parameter and readOnlyHint, the description gives the resource, temporal scope, and clarifying phrase. Missing minor details like default ordering are not critical here.

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% and the single 'limit' parameter is fully documented in the schema. The description adds no additional meaning beyond what the schema already provides, so 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?

States a specific verb ('List') and resource ('radar runs'), clarified as 'AI citation/visibility snapshots over time.' It distinguishes by resource from siblings like list_reports or list_prompts, but does not explicitly differentiate or name alternatives.

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?

No when-to-use guidance, prerequisites, or alternatives are provided. 'Recent radar runs' implies a listing use case, but nothing tells an agent when to choose this over list_reports or other sibling tools.

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?

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds the crucial behavioral detail that this does not flip a plan switch but mints a hosted checkout URL the user must open and pay through. It leaves open whether repeated calls create duplicate links or what happens on an already-maxed plan.

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 short sentences: action, return value, trigger — in that order. Every sentence carries information and nothing is padded.

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 covers the missing return-value contract ('Returns a URL the user can open to pay'), plus the trigger and valid tiers. Combined with annotations covering the write/open-world profile, an agent has everything needed to invoke it correctly.

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%: the tier enum and the conditional 'required only if the account has no owner email on file' rule are already in the schema. The description's tier list repeats structured data rather than adding new meaning, 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?

States a specific verb+resource ('Create a hosted checkout link to upgrade the OmniForce plan') and enumerates the valid tiers. It is unmistakably different from the read/list siblings (account, geo_scan, list_*), so an agent can pick it without opening the schema.

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?

'Use when a requested feature is blocked by the current plan' gives an explicit trigger condition, which is stronger than implied usage. It stops short of naming when *not* to use it (e.g., already on the target tier) or pointing at an alternative.

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