Pyxmark

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context about the data source and what kind of records are searched, but says nothing about match behavior (exact vs fuzzy), whether only currently active exclusions are covered, or what the result looks like.

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 well-formed sentence with the verb, source and scope front-loaded and the technical terms glossed inline. No filler and nothing that could be cut.

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 rich annotations, full schema coverage and no output schema to explain, the description covers the essentials an agent needs to invoke it. What is missing is routing versus screen_sanctions and any note on result interpretation, which keeps it short of complete.

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 the 'name' and 'subject_type' parameters are already documented, including the default heuristic for subject_type. The description adds no formatting guidance for the name (e.g., legal suffix or middle-name handling), so it stays at the baseline for a fully documented 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 ('Check') and resource ('a name against SAM.gov federal contracting exclusions') and even unpacks the jargon with '(debarments/suspensions)'. It does not, however, differentiate itself from the closely related sibling screen_sanctions, leaving the agent to guess which screening source applies.

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. The description never mentions screen_sanctions or any other sibling, so an agent cannot tell from this text when federal exclusion screening is preferred over sanctions screening or a full due_diligence_report.

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 and destructiveHint=false, so the safety profile is covered. The description adds real context beyond them: the upstream source is SEC EDGAR, name lookups resolve to a best match rather than failing, and the response bundles filings with links. It stops short of saying what happens on zero matches or how many filings 'recent' means.

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, zero filler. The scope statement and returned-field inventory come first, and the routing instruction to search_company is placed last where it acts as a guard rather than a preamble.

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 return-value burden and does so by enumerating the fields and filing types returned. Remaining gaps are minor: the window/breadth of 'recent' filings is undefined and the behavior on no-match or ambiguous best-match results is not described.

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 baseline is 3. The description adds meaning beyond the one-line schema entries by noting that name matching is fuzzy/best-match and by implying the three identifiers are interchangeable resolution paths for the same record.

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 ('Full SEC EDGAR record for one company') and names the accepted identifiers (CIK, ticker, name). It then enumerates the exact payload — legal name, SIC, incorporation state, address, 3 years of financials, recent 10-K/10-Q/8-K filings — so an agent can distinguish it from siblings like due_diligence_report without opening any 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?

Explicitly routes the agent to an alternative: 'Use search_company first if you only have a partial or ambiguous name.' The condition that selects the sibling is stated, and the parenthetical '(best match)' warns about fuzzy resolution when no exact identifier is available.

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 establish read-only, idempotent, open-world behavior, and the description adds genuinely new context beyond them: first_archived is null when no snapshot exists, archive.status signals archive.org failure, and notes are explicitly 'not flags'. These edge-case disclosures are exactly the kind of behavioral detail the annotations cannot convey, though rate limits or latency are unmentioned.

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?

It is a single dense but front-loaded sentence that leads with the primary outputs before the caveats. Every clause carries information, though packing return-value semantics, error states, and notes semantics into one run-on sentence slightly hurts scannability.

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 explaining returns and does so for the main fields plus null/unavailable edge cases. It is nearly complete for a single-parameter lookup, though it omits any note on response shape or whether lookups can be partial.

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 parameter is fully documented as accepting a 'Domain, URL, or email address', so the baseline is 3. The description adds no syntax or format detail beyond the schema, but none is needed.

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 enumerates the specific data resources returned — registration date/age, registrar via RDAP, email-auth records (MX/SPF/DMARC), and a Wayback first-snapshot date — which is far more than a restatement of the name. It distinguishes itself from siblings like company_profile and screen_sanctions, though it never states an explicit verb ('retrieves'/'reports'), leaving the action inferrable rather than declared.

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 framing 'common fraud signals' implies a due-diligence/investigation use case, but there is no explicit when-to-use statement and no named alternative among the sibling tools (due_diligence_report, screen_sanctions, company_profile). Usage is implied rather than guided.

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 mark this as read-only, idempotent, and non-destructive, but the description adds substantial context: data-source limitations, potential false positives and missed fuzzy matches, the difference between informational output and compliance determination, and the precise meaning of the verdict states. It also explains that address-density signals are informational only and never change the verdict.

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 main purpose and verdict guidance are front-loaded, and most sentences carry relevant caveats or scope limits. It is dense and long for a description, especially the address-density explanation, but the length is largely justified by the tool's complexity and lack of an output schema.

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?

Given 16 optional parameters, no output schema, and a broad data-aggregation purpose, the description covers what the report includes, how to interpret the verdict, data limitations, verification expectations, and geographic scope. An agent has enough context to decide when and how to use 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 all 16 parameters are already documented in the input schema. The description reinforces a few constraints, such as Colorado-only scope and state/address relevance, but adds little per-parameter semantics 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 opens with a specific verb and resource: a one-call due-diligence report covering SEC, sanctions, exclusions, domain, and registry data plus a verdict. It clearly positions the tool as an aggregate report rather than a single-purpose sibling like screen_sanctions or domain_age.

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 actionable usage guidance tied to the verdict: do not pay or onboard on 'hold' and ask a person on 'review'. It also limits scope to Colorado vendors and instructs verification against official sources, though it does not explicitly contrast with 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 already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it caps results at 15 with truncation messaging, defines the assessment field values (hold/review/clear), explains how disambiguating inputs alter matching, and discloses false-positive/variant risk, data staleness, and the verify-against-source requirement. No annotation contradiction.

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 purpose and return shape, then disambiguators, matchers, assessment, and caveats in a logical order with no filler. It is dense and longish for a single paragraph, but nearly every clause carries information an agent needs for a compliance-adjacent 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, so the description carries the return-value burden and does so: up to 15 scored matches with source links, truncation behavior, and the hold/review/clear assessment. Combined with the disambiguation rules and legal caveats, an agent has everything needed to call and interpret this 13-parameter 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 coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: address flags comprehensively sanctioned regions (with the specific list), owner percentages trigger the OFAC 50 percent rule, phone matches on the last 9 digits, and dob/nationality/country suppress same-name entries whose listed details differ. This meaningfully enriches understanding of what each input does to the result set.

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 (fuzzy-screen) plus the exact resource and scope: a person or organisation name against OFAC SDN + Consolidated, UN, EU, and UK lists. It also names what comes back (scored matches with source links), which distinguishes it immediately from siblings like company_profile, search_company, or due_diligence_report.

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?

Gives clear context for when each optional input helps (dob/birth_year/nationality/country to set aside same-name matches, owners for the 50 percent rule) and warns that it is informational only, not a compliance determination. It stops short of naming sibling tools or stating when a different tool is the better choice, 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 readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the result shape ('up to 10 candidates... and nothing else'), which sets an expectation about the cap and that no extra fields come back.

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 with no filler; the lookup scope leads and the disambiguation workflow follows. 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?

There is no output schema, so the description takes on the burden of describing the return value (candidates with CIK, tickers, match score, capped at 10) and does so. For a single-parameter read-only lookup, nothing material 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 100% and there is only one parameter, so the schema already documents that 'query' accepts a name, ticker or CIK. The description mirrors rather than extends that, 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?

States a specific verb and resource ('Look up which SEC-registered company a name, ticker or CIK refers to'), and names the follow-on sibling company_profile, so an agent can place it in the workflow without opening any 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?

Explicitly names the trigger condition ('when a name is ambiguous') and the next step ('then call company_profile with that CIK for the details'), which is exactly the when/when-not/alternative guidance the dimension asks for.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint false, non-open-world). The description usefully signals that this yields a link rather than fetched company data, which matters behaviorally, but it never states that the agent must follow the link externally or what the response actually contains.

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 well-formed sentence that front-loads the resource and follows with the purpose. No filler, though the clause list at the end is slightly dense.

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, no-output-schema link tool, the description is nearly adequate, but it leaves the return contract ambiguous — does it emit a URL string, a list, or metadata? An agent cannot fully predict 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?

Schema description coverage is 100%, so both parameters (state, company) are already documented structurally; the description adds no format, casing, or optionality detail beyond what the schema provides. 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 concrete resource (official Secretary of State business-search link for a US state) and the intent behind it (verify status, formation date, registered agent). It is distinguishable from siblings like search_company or company_profile, though it never explicitly contrasts with them.

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 'to verify a private company's status, formation date, and registered agent' implies why an agent would reach for this tool, but there is no explicit when-to-use vs. when-to-use-a-sibling guidance, even though search_company and due_diligence_report overlap heavily with this intent.

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