Quiet Stance Productive Opportunity Intake

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds genuine value beyond them by explicitly stating the tool is falsification-only and does not 'authorize, block, execute, price, or submit' — an important clarification that a read-only flag alone does not convey for a decision tool. It omits rate/pagination/output behavior, but for a purely advisory tool 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?

Three sentences, front-loaded with the tool's nature and scope, then the capability, then the exclusion. No filler. The density of domain jargon ('T0 evidence state', 'separation of later evidence') is intentional but slightly heavy, keeping it off a 5.

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 an 11-parameter, enum-heavy evaluation tool with no output schema, the description should explain what the assessment returns (a verdict? a gap classification?) and how the enum states combine into a conclusion. It describes inputs conceptually but never the result, so an agent cannot anticipate the response shape or how to act on 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 only 18% (11 params, only action_summary and economic_consequence documented), so the description is expected to compensate. It does partially: the enumerated evidence dimensions (source versions, timestamps, authority, contradictions, unresolved dependencies, separation of later evidence) map onto six of the enum parameters. But the meaning of individual enum values (e.g., mixed_timestamps, resolved_without_trace, partial_versions) is left entirely to inference, so compensation is incomplete.

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 action (falsification check) and a specific resource (an agent transaction's T0 decision-state replay gap), plus the applicable domain (agentic purchases, procurement, paid API calls). It clearly bounds what the tool is not, which makes it identifiable against the submit_*/assess_* siblings. It stops short of naming an alternative sibling by name, so a 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?

Applicability is implied through the enumerated domains (agentic purchases, paid API calls, irreversible machine actions) and the 'read-only falsification' framing. However, there is no explicit when-to-use/when-not-to-use rule and no named alternative among siblings, so the agent must infer the routing condition. This is minimum-viable 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?

Annotations already cover readOnly/idempotent/non-destructive, yet the description adds real behavioral value: it enumerates the returned fields (status, missing_inputs, rights assessment, next_step, submission_tool only when ready) and sets negative boundaries (no ROI estimate, no bankability claim, no financing/grant authority, evaluates user-supplied facts only). This is exactly the extra context annotations cannot carry.

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 trigger condition and the outcome, and every clause carries meaning. Slightly dense/run-on as a single long sentence, but 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?

For a 9-param, zero-required, no-output-schema tool, the description compensates by describing the return shape and the readiness-gating behavior. Combined with full schema coverage and safety annotations, an agent has everything needed to invoke and interpret 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% with well-documented fields and enums, so the schema does the heavy lifting. The description adds no parameter-level syntax or format guidance beyond what the schema provides, 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 (assess) and resource (productive/controlled-opportunity fit for Quiet Stance), and distinguishes itself from the submit_* siblings by explicitly declaring 'does not submit data'. An agent can tell what it returns and what it is not.

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?

Explicitly says when to use it ('before a controlled-opportunity submission when... readiness or rights need checking') and states the condition that triggers it. It implies the alternative is the submit tools via the 'does not submit' clause, but never names submit_project_opportunity or submit_authorized_opportunity directly.

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, idempotentHint, openWorldHint=false and non-destructive, so safety is covered structurally. The description adds meaningful context beyond that: no-login, no project data collected, no title/feasibility/financing/advice delivered. That is real added behavioral disclosure.

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 usage trigger and then the boundary list. Dense but every clause earns its place; only the long negative enumeration slightly taxes readability.

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 compensates by describing the return ('public links and seven evidence-gate names') and enumerating the non-capabilities. That is sufficient for a zero-parameter read tool, though it does not detail the seven gate names.

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 are no input parameters, so the schema baseline is 4. The description correctly adds no parameter semantics, and its discussion of returns is output-side rather than input-side, which is appropriate.

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 and resource ('Get ... project readiness checklist / evidence matrix / decision register') and states what is returned ('public links and seven evidence-gate names'). This is clearly distinguishable from siblings like assess_project_opportunity_fit or submit_project_opportunity.

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?

It gives an explicit trigger context ('when an owner or sponsor asks for ... before commissioning feasibility, procurement or investment') and a clear when-not list. It stops short of naming a specific alternative sibling tool, so it is strong but not fully routing.

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 readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful disclosure beyond that by enumerating what is never exposed (internal notes, protected leads, conflict evidence, economics, other submissions), which is important field-level boundary information. It stops short of describing error behavior for an invalid or expired token.

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, both front-loaded with the essential information (what is returned, then what is withheld). No redundant restatement of the name or title.

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 single-parameter read tool with no output schema, the description covers purpose and data boundaries well. It could say more about the shape of the returned state or token-invalid failure modes, but nothing essential to correct invocation 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?

Schema description coverage is 0%, so the single status_token parameter is undocumented in the schema. The description partially compensates by characterizing it as a 'private capability token', which conveys the secret/opaque nature of the value, but gives no hint about format, where to obtain it, or the 32-256 length constraint.

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 (bounded external state of a Quiet Stance submission) and can be told apart at a glance from the six submit_* siblings, which create records rather than read state. The scoping phrase 'bounded external state' further narrows what is returned.

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?

Mentions that a private capability token is required, which implies the calling context, but never says when to use this versus the sibling submission tools or when it should not be used. Usage is only inferable from the name and the token reference.

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 disclose the safety profile (not read-only, open-world, non-idempotent, non-destructive), so the description's burden is reduced. It adds the meaningful semantic disclaimer that registration is not an endorsement, but says nothing about what record is created, authentication/consent enforcement, or what an agent should expect back from this open-world submission.

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 tight sentences with the trigger condition front-loaded and zero filler. It is efficient, though the brevity comes at the cost of the detail this 15-parameter tool 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 high-arity, open-world, non-idempotent submission tool with no output schema and 13% parameter coverage, the description is far too thin. It omits required-field meaning, the consent requirement, idempotency/retry expectations, and any indication of what happens after submission.

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?

With 15 parameters at 13% schema coverage, the description must carry the load, and it contributes nothing: required fields like signal_name, current_state, summary, consent, and country_location are unexplained in both schema and description. The capability-category list does not map to any parameter name, so an agent gets no help populating the form.

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 title supplies the verb+resource ('Register a qualified capability') and the description enumerates the capability categories that qualify. However, it never states what a 'capability registration' produces, and it does nothing to distinguish this tool from siblings like submit_demand_requirement, submit_bottleneck_signal, or submit_project_opportunity, which all appear to be submissions of structured records.

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 the submitter provides a technical, operating, development, capital, software, or specialist capability' gives a genuine trigger condition, which is more than nothing. But the categories are broad and overlapping with the sibling submit_* tools, and there is no guidance on when NOT to use this tool or which sibling to prefer instead.

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 this is a mutation (readOnlyHint=false) that is non-destructive and open-world. The description adds a real content requirement beyond structured data: 'Control and economic use must be stated explicitly.' But it says nothing about the review/acceptance flow, visibility, or what happens after submission, leaving significant behavioral gaps.

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 tight sentences with no filler, and the qualification condition is front-loaded. It is efficient, though the brevity contributes to the under-specification rather than reflecting genuine concision of a complete idea.

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 17-parameter, 10-required mutation tool with no output schema, 12% schema coverage, and uint8 annotations covering only safety, the description is far too thin. An agent cannot determine field expectations, submission lifecycle, or how it differs operationally from submit_project_opportunity.

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?

With 17 parameters, 10 required, and only 12% schema description coverage, the description must carry parameter meaning and does not. Only the loose requirement to state 'control and economic use' hints at rights_status/economic_consequence; the other ~15 fields (authority_access_state, current_state, signal_name, etc.) get no explanatory help.

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 never states what the tool does; it only states an eligibility condition ('Use when the submitter owns, hosts, sponsors, procures...'). The verb+resource must be inferred from the name and title 'Submit a controlled opportunity'. It gestures at the distinction from submit_project_opportunity via the authorization gate, but does not articulate it.

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?

It gives a clear eligibility context enumerating the qualifying relationships (owns, hosts, sponsors, procures, legitimate route to originate). However, it never names the alternative sibling (submit_project_opportunity) or states when NOT to use this tool, leaving the routing decision partly to 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 the operation is non-read-only, non-destructive, non-idempotent, and open-world, so the safety profile is covered. The description adds the useful framing that submissions are treated as research/validation signals, but says nothing about required consent/rights handling, data sensitivity, or what happens after submission.

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 tight sentences, front-loaded with the use directive. The phrase 'unless control and demand are separately established' is slightly cryptic but carries real qualification, so little waste overall.

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 14-parameter, 9-required submission tool with no output schema and near-zero schema description coverage, the description is far too thin. It should at minimum explain the consent requirement, rights_status enumeration, and the meaning of the key content fields.

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?

With 14 parameters, 9 required, and only 7% schema description coverage (just idempotency_key documented), the description must compensate and does not — it mentions no field, not consent, rights_status, economic_consequence, or country_location. An agent gets essentially no help on what to populate.

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 defines what qualifies as a bottleneck signal ('a recurring constraint or missing capability that may not yet be a formed project'), which implicitly distinguishes it from the sibling submit_project_opportunity. The verb is carried by the name/title rather than the description, and no sibling is named outright, so it falls short of 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?

It opens with 'Use for...' and adds a qualifier that this is a research/validation signal absent established control and demand, giving implied context. However, it never states when NOT to use it or names an explicit alternative among the six sibling submission tools, leaving the routing decision to 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=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no execution behavior beyond that: it does not say where the submission goes, that consent=true is mandatory, that idempotency_key doubles as a status token, or that a get_submission_status sibling exists. 'Without claiming control of supply' is a content-norm constraint, not disclosure of tool 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?

Two sentences, front-loaded with the usage condition and then the required content, with no padding. The density of domain jargon ('off-taker', 'productive-capacity', 'control of supply') makes it slower to parse than its length suggests, but nothing is wasted.

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 19-parameter, 10-required submission tool with 21% schema coverage and no output schema, the description is thin: it omits what happens after submission, how status is tracked, and the meaning of most required fields. A submitting agent would have to guess at several mandatory inputs.

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?

With only 21% schema description coverage across 19 parameters, the description carries real weight here and does map several fields ('buying or operating authority', 'economic consequence', 'current workaround', 'location'). But it leaves most required fields (name, work_email, signal_name, consent, summary, current_state, rights_status) unexplained and never clarifies the rights_status or commercial_intent enums.

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 never states what the tool actually does; it opens with a usage trigger ('Use when a buyer, operator, user, or off-taker has a real requirement') and lists content to provide. The verb+resource must be inferred from the name and title ('submit_demand_requirement'), and nothing distinguishes it from submit_bottleneck_signal, submit_authorized_opportunity, or submit_project_opportunity.

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?

It gives an explicit trigger and enumerates the qualifying actors (buyer, operator, user, off-taker with 'a real requirement'), so the agent knows what qualifies. It stops short of naming alternatives or a when-not condition, which matters given three sibling 'submit_*' 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 already disclose write (readOnlyHint=false), openWorld, and non-idempotent behavior, and the description adds real value beyond that: submission 'records the declared state only and does not create a mandate, financing commitment, endorsement, or authority to act,' plus the sanitization instruction for first contact. This clarifies the effects of the write, which is exactly what annotations cannot convey; it still says nothing about rate limits or follow-up processing.

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 sentences, front-loaded with the tool's identity, then the selection rule, then the effect disclaimer. No filler, though the type enumeration is doing double duty and the constraints are terse.

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 with 18 parameters at 11% schema coverage the description should carry more of the semantic load. The no-mandate disclaimer covers the most important behavioral question for a submission tool, but required fields like rights_status and consent, and the private status-token behavior of idempotency_key (documented only in schema), leave an agent without full context.

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 only 11% across 18 parameters, so the description must compensate heavily and it does not. It enumerates the inquiry_type enum values, but rights_status (11 values), consent, project_stage, commercial_intent, and other required/optional fields get no explanation in the description beyond what the bare schema types show. Large undocumented surface remains.

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 the verb and resource ('generic submission tool' for a productive signal) and names the four inquiry_type values, which lets an agent see this overlaps the narrower sibling tools submit_bottleneck_signal / submit_demand_requirement. It stops short of explicitly contrasting itself with submit_authorized_opportunity or register_partner_capability, so sibling differentiation is only partial.

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?

'Choose the inquiry_type that is true now' gives selection guidance among the type values, and 'backward-compatible generic' hints at its role, but there is no explicit statement of when to prefer this tool over the specialized sibling submission tools or when submission is inappropriate. Usage is implied rather than spelled out.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description nonetheless adds real value by stating it 'does not submit data, create rights, infer authority, or treat public information as a mandate,' which sets accurate expectations about side effects beyond what annotations convey.

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 tightly written sentences with zero filler, and the primary usage cue ('use this first') is front-loaded. The second sentence efficiently bundles four negative side-effect claims into one line.

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 an 11-param triage tool with only one required field, full schema coverage, and no output schema, the description supplies the purpose, the routing intent, and the non-authoritative boundary. Nothing critical for correct invocation is missing, though return behavior 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?

Schema description coverage is 100% and 5 of 11 params carry enums with their own descriptions, so the schema fully documents the parameters. The description adds no syntax or format detail beyond the schema, making the baseline 3 appropriate.

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 verb-object is clear (triage an economic signal) and the description carves out its distinct role as the 'use this first' routing step, naming the four downstream categories that map to the submit_* siblings. This lets an agent distinguish it from submit_project_opportunity, submit_demand_requirement, submit_bottleneck_signal, and register_partner_capability without opening schemas.

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 this first when a user or agent... is not yet sure whether..." gives a clear triggering condition, and the four alternatives named map directly to sibling tools, implicitly routing the agent. It stops short of an explicit when-not or a named alternative to escalate to once the category is known.

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