Source-attributed person, company, contact and entity enrichment with explicit limitations and signed evidence.
Scored across 12 tools
The six *_enrichment_evidence/*_reputation_evidence tools target distinct entity types (agent, company, contact, person, social), and the free utilities (preflight, schema_normalize_free, try_service, verify) are clearly separated. Minor overlaps exist: entity_enrichment_evidence is a generic term that could be confused with company/person/contact enrichment, and inspect_agent vs agent_reputation_evidence both concern agents.
The six paid tools share a clean *_evidence suffix, but the rest mix conventions: verb_noun (inspect_agent, try_service), noun_verb (schema_normalize_free), bare nouns (preflight, verify), and a namespaced verb (phion_execute). Readable but not a single predictable pattern.
Twelve tools is well-scoped for a paid enrichment marketplace: six entity-enrichment services, an execution gateway, and four free lifecycle helpers. Each tool earns its place with no obvious redundancy.
The surface covers a full paid-service lifecycle: preflight, schema normalization, preview (try_service), execution (phion_execute), and receipt verification, plus six enrichment domains. Minor gaps remain, e.g. no explicit budget/status or receipt-listing tool beyond the gateway envelope.
Evidence-bounded agent reputation assessment with confidence, coverage, provenance limitations and a signed receipt; 0.005 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| signals | No | ||
| subject | Yes | ||
| evidence | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the key behavioral traits: results are bounded by supplied evidence, and there are confidence/coverage/provenance limitations plus a signed receipt. It does not state permissions, side effects, or whether the receipt is on-chain. Adequate but not rich.
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 core purpose and enumerating the outputs. It is efficient, though the price is tacked on without saying when it is charged.
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 are three nested parameters at 0% schema coverage, no annotations, and a nested input structure. The description omits parameter semantics, invocation context, and output details present in the output schema. An output schema exists, so return-value explanation is not required, but the input-side gaps are large.
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 description must compensate, but it never mentions subject, signals, or evidence. The example reveals sample fields, but their semantics and the maxItems=32 evidence cap are unexplained. The gap is significant.
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 and resource: an evidence-bounded reputation assessment of an agent, plus the outputs (confidence, coverage, provenance limitations, signed receipt). It is distinguishable from siblings like counterparty_risk_preflight, but it does not explicitly name or contrast against 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 description gives no when-to-use, when-not-to-use, or alternative-sibling guidance. The agent must infer its place among many preflight/evidence tools from the one-line description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Company enrichment with free input preflight, provider attribution and signed evidence; 0.005 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| lid | No | ||
| name | No | ||
| No | |||
| input | No | ||
| phone | No | ||
| query | No | ||
| entity | No | ||
| pdl_id | No | ||
| person | No | ||
| region | No | ||
| school | No | ||
| ticker | No | ||
| company | No | Company name or nested input object | |
| contact | No | ||
| country | No | ||
| profile | No | ||
| subject | No | ||
| website | No | ||
| locality | No | ||
| location | No | ||
| last_name | No | ||
| birth_date | No | ||
| email_hash | No | ||
| first_name | No | ||
| identifier | No | Email, profile URL, phone, company domain, ticker or name; interpreted by service | |
| postal_code | No | ||
| street_address | No | ||
| minimum_likelihood | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose two useful traits that structured fields do not: the cost (0.005 USDC) and that input validation happens before payment. However, it omits auth requirements, rate limits, idempotency, and what happens to a paid call that later fails enrichment.
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 dense sentence with the core function front-loaded; no filler. It is jargon-heavy ('signed evidence', 'provider attribution') but every clause carries 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 28-parameter, paid, no-annotation tool with no output schema, the description is far too thin. It never explains the return shape beyond 'signed evidence', gives no failure or refund behavior, and leaves the identity-input model undocumented for the agent.
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 7% across 28 parameters, so the description is expected to compensate, and it does not — it says nothing about accepted identifier forms or the semantics of nested input/query/entity/company. The useful enumeration of identifiers lives in the schema's own description field, not the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (company enrichment) and differentiates from siblings like person_enrichment_evidence, contact_enrichment_evidence, and entity_enrichment_evidence by naming the company domain. It also names the deliverables (provider attribution, signed evidence) and the price, though the pricing detail slightly crowds out the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no routing to alternatives such as preflight or preflight-free schema_normalize_free. The phrase 'free input preflight' hints that validation happens first, but the agent is left to infer whether this tool should be called before or after the sibling enrichment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Business-contact enrichment with free input preflight, identity limitations and signed receipt; 0.007 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| lid | No | ||
| name | No | ||
| No | |||
| input | No | ||
| phone | No | ||
| query | No | ||
| entity | No | ||
| pdl_id | No | ||
| person | No | ||
| region | No | ||
| school | No | ||
| ticker | No | ||
| company | No | Company name or nested input object | |
| contact | No | ||
| country | No | ||
| profile | No | ||
| subject | No | ||
| website | No | ||
| locality | No | ||
| location | No | ||
| last_name | No | ||
| birth_date | No | ||
| email_hash | No | ||
| first_name | No | ||
| identifier | No | Email, profile URL, phone, company domain, ticker or name; interpreted by service | |
| postal_code | No | ||
| street_address | No | ||
| minimum_likelihood | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose real traits: a free preflight/validation step, a signed receipt, stated 'identity limitations', and an explicit price of 0.007 USDC. That is meaningful context beyond the schema. But the traits are named without detail — what 'identity limitations' or a 'signed receipt' actually mean for the agent, and failure/refund behavior, are left unstated.
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 clauses, and the most decision-relevant facts (what it is, free preflight, price) come early. It is efficient, though 'identity limitations' is vague enough to read as 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 28-parameter, nested-object tool with no annotations and no output schema, one sentence is far too thin. It omits how the many identifier parameters interact, what the result contains, and how it differs from the closely related enrichment siblings, so the agent cannot confidently invoke it from the definition alone.
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 has 28 parameters with only 7% schema description coverage, so the description is required to compensate and instead says nothing about any parameter. The rich identifier semantics ('pdl_id, email, email_hash, phone, lid, profile, or name plus context') live in the schema description, not in the tool description, leaving over two dozen undocumented fields unexplained.
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 ('Business-contact enrichment'), which separates it semantically from the company_/entity_/person_enrichment_evidence siblings. However, the actual operation is nominalized rather than a verb ('enrichment'), and the description never explicitly says what happens to the input or what it returns, so sibling differentiation is implied rather than stated.
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 guidance at all: nothing tells the agent why it would pick contact_enrichment_evidence over person_enrichment_evidence or entity_enrichment_evidence, nor what input combinations are valid contexts. The mention of a 'free input preflight' hints at a workflow step but does not constitute usage guidance or an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Source-bounded entity field coverage with explicit missing facts; 0.008 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| subject | No | ||
| source_urls | Yes | ||
| expected_fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose two real behavioral traits: results are bounded to the supplied sources (no external lookup) and missing facts are reported explicitly rather than silently omitted, plus a per-call cost of 0.008 USDC. It says nothing about permissions, failure modes, or result shape, which leaves a mutation-free but still opaque contract.
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 compact sentence with the scope stated first, which is structurally sound. But the brevity comes at the cost of comprehensibility: three dense compound modifiers and an embedded price are packed into one fragment, so it is terse rather than economical.
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 tool with a nested object parameter, 0% schema coverage, no annotations, and no output schema, the description is far too thin. It should at minimum explain what 'subject' expects, how 'expected_fields' drives the coverage report, and what the missing-facts output looks like.
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% for three parameters, one of them a nested 'subject' object, and the description only obliquely gestures at 'source_urls' (source-bounded) and 'expected_fields' (field coverage). The maxItems constraints (5 sources, 32 fields), the required status of source_urls, and the internal structure of 'subject' are nowhere explained.
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 phrase 'entity field coverage with explicit missing facts' does convey that the tool reports which entity fields are supported by the given sources and flags gaps, and 'source-bounded' sets the scope. However, it is jargon-heavy noun phrasing with no verb, and it never distinguishes itself from the sibling enrichment tools (company/person/contact_enrichment_evidence), so an agent must guess which enrichment variant 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 guidance, no prerequisites, and no named alternative among the many sibling enrichment/evidence tools. The only routing signal is the price tag, which does not tell an agent when this tool is the right choice over company_enrichment_evidence or social_source_evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-payment agent inspection across x402, A2A, ERC-8004, OpenAPI and MCP; failed inspections are not charged; 0.009 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description nonetheless adds genuinely new behavioral context absent from annotations: the cost (0.009 USDC) and the billing rule that failed inspections are not charged. It stops short of describing what an inspection returns or any 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 dense sentence, front-loaded with the core purpose and semicolon-packed with pricing terms. Nothing is wasted and no filler precedes the key 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?
Adequate for a one-parameter read-only tool, but with no output schema the description supplies nothing about what an inspection yields (a score? a report?), and the lone 'url' parameter is left undocumented. It covers purpose, protocols, and billing but leaves return semantics to inference.
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 ('url') with 0% schema description coverage, so the description carries the burden. It never explains what the URL should point to, though the schema's example ('https://agent.example/.well-known/agent.json') and the protocol list give strong implicit hints. Marginal added value.
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 ('agent inspection') and enumerates the supported protocols (x402, A2A, ERC-8004, OpenAPI, MCP), which is well beyond a restatement of the name. It does not, however, distinguish itself from sibling-like tools such as preflight, verify, or try_service.
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 'pre-payment' qualifier implies when to reach for it (before paying an agent), which is useful implicit context. But no explicit when/when-not rules and no named alternatives (preflight, verify) are given, so routing remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Person enrichment with free input preflight, provider attribution, likelihood, limitations and signed receipt; 0.006 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| lid | No | ||
| name | No | ||
| No | |||
| input | No | ||
| phone | No | ||
| query | No | ||
| entity | No | ||
| pdl_id | No | ||
| person | No | ||
| region | No | ||
| school | No | ||
| ticker | No | ||
| company | No | Company name or nested input object | |
| contact | No | ||
| country | No | ||
| profile | No | ||
| subject | No | ||
| website | No | ||
| locality | No | ||
| location | No | ||
| last_name | No | ||
| birth_date | No | ||
| email_hash | No | ||
| first_name | No | ||
| identifier | No | Email, profile URL, phone, company domain, ticker or name; interpreted by service | |
| postal_code | No | ||
| street_address | No | ||
| minimum_likelihood | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses pricing (0.006 USDC), that input preflight/validation happens before payment, and that output includes attribution and a signed receipt. It does not cover authentication, rate limits, failure behavior, or what exactly gets enriched, so the mutation/cost profile is only partially 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?
A single dense sentence that front-loads the core purpose and appends cost. No filler, though the trailing list of output features flattens the emphasis slightly.
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 28-parameter, no-annotation, no-output-schema tool, the description partially compensates by summarizing the response shape (attribution, likelihood, limitations, receipt) and the payment model. It remains incomplete on parameter semantics and usage routing, which are the larger gaps.
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 7% across 28 parameters, so the description must compensate. It names a handful of identifier params (pdl_id, email, email_hash, phone, lid, profile, name) and notes nested input/query/subject/person/contact are accepted, but leaves the majority of parameters (school, ticker, company, region, location, birth_date, minimum_likelihood, etc.) completely unexplained.
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 operation and resource ('person enrichment') and lists the value-adds it returns (provider attribution, likelihood, limitations, signed receipt). This separates it from the sibling enrichment tools (company_, contact_, entity_), though it never names an alternative explicitly.
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 guidance and no comparison to the numerous sibling tools. An agent must infer from the name that this is the person-specific enrichment path rather than contact_enrichment_evidence, which is not self-evident given 'contact' and 'person' overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal PHION execution gateway: enforce a budget and persistent idempotency, execute one selected PHION service, evaluate acceptance criteria, and return a signed completion envelope. No gateway surcharge; the selected service price applies.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| dry_run | No | ||
| objective | Yes | ||
| target_service | Yes | ||
| idempotency_key | Yes | ||
| max_budget_atomic | Yes | ||
| acceptance_criteria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description nonetheless adds real substance: budget enforcement, persistent idempotency, acceptance-criteria evaluation, a signed completion envelope, and the pricing note ('no gateway surcharge'). It stops short of describing failure/retry behavior or the dry-run semantics.
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 gateway purpose and flow, with a pricing clause that earns its place. Dense but not padded; density does cost some readability for a 7-parameter 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?
For a 7-parameter, nested-object, no-output-schema mutation tool, the description leaves meaningful gaps: dry-run behavior, input shape, atomic budget units, acceptance-criteria pointer syntax, and what happens when criteria fail are all unaddressed. Both schema and description are thin on parameters.
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 description carries the burden, and it only partially compensates. It conceptually covers budget (max_budget_atomic), idempotency (idempotency_key), acceptance criteria, and target_service, but says nothing about the 'atomic' unit format, the JSON-pointer syntax for acceptance criteria, the objective field, or what dry_run does.
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 ('execute one selected PHION service') and frames the tool as a 'Universal PHION execution gateway' that also budgets, idempotency-checks, evaluates acceptance criteria, and returns a signed envelope. That is far more informative than restating the name, but it never explicitly contrasts itself with siblings like phion_preflight or verify, so an agent must infer the boundary.
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?
'Execute one selected PHION service' implies this is the terminal step after discovery/selection, but no condition is given for choosing this over phion_preflight or verify, and no prerequisites or exclusions are stated. Usage is deducible from context 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.
Free URL safety and reachability check.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it discloses almost nothing beyond 'free' — no auth requirements, no explanation of what makes a URL unsafe, no behavior on failure, and no rate limits. Calling something a safety check without saying what it inspects or returns leaves real ambiguity.
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 with no filler; the core action leads. It is efficient, though the terseness edges toward under-specification rather than tightness.
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 one-parameter tool with no output schema, the description still omits what a 'safety' verdict consists of and what the caller gets back, which is the main thing an agent needs to decide whether to gate a downstream action on 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 0% for the single required url parameter, and the description only says a URL is checked. It does not clarify expected form (absolute? scheme? relative paths rejected?), which matters because the schema only declares format: uri with no prose.
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 concrete verb-plus-resource framing: it checks a URL for safety and reachability. That is enough for an agent to know what it does, but it never distinguishes itself from the sibling payment_preflight, which sounds nearly identical in kind.
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 payment_preflight, verify, or the other siblings, and no prerequisites (e.g., authenticate first, call before payment). The agent is left to infer the workflow position of a 'preflight' entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free, rate-limited payload validation and safe key normalization before payment. Payment-critical values are never changed.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | ||
| target_service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose genuine behavior beyond the schema: free tier, rate limiting, non-mutation of payment-critical values. But it omits error/invalid-payload behavior, what the rate limit actually is, and whether normalization mutates or returns a new payload.
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 key guarantee front-loaded after the purpose clause; no filler. Slightly dense with unattributed modifiers ('Free, rate-limited') but appropriately sized.
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 and no annotations, with a nested free-form payload object and an undocumented required target_service string. An agent cannot reliably construct a valid invocation from this description alone; payload shape, service identifiers, and failure behavior are all 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%: the nested 'payload' object has no field documentation, and 'target_service' is never mentioned in the description at all, so its expected values are entirely unknown. The description adds some intent ('payment-critical values are never changed') but does not compensate for the uncovered, required parameters.
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 action pair (validation and safe key normalization) on a specific resource (payload) with scope (before payment). The adjectival 'Free, rate-limited' implicitly distinguishes it from the sibling schema_normalize, but the distinction is left for the agent to infer rather than stated.
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 a clear timing context ('before payment'), which implies when to reach for it, but never names the alternative schema_normalize or states when to use the paid variant instead. 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.
Free representative preview, exact price and upgrade instructions for any PHION paid service; no wallet required.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does disclose two important traits: cost is zero ('Free') and no wallet/auth is needed. It stops short of other operational facts an agent needs — whether the preview is truncated/representative-only, rate limits, and whether calling it commits to anything.
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 dense sentence that front-loads the key benefit ('Free representative preview') before the outputs and the 'no wallet required' constraint. Nothing is wasted, though the clause stacking makes it slightly harder to parse at a glance.
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 tool with a 120+ value enum, no output schema, and no annotations, the description is adequate on the basics (free, no wallet, returns price and upgrade path) but does not explain what the 'representative preview' actually contains or how it relates to the real paid response, which matters given the huge service surface.
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 description must compensate. 'For any PHION paid service' does convey that the single parameter selects a service, which is useful, but it adds no format, naming, or constraint detail beyond the 120+ value enum, and gives no hint about the enum itself.
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 action ('free representative preview') plus a concrete scope ('any PHION paid service') and the extra outputs (exact price, upgrade instructions). It is clearly distinguishable from a generic execute tool, but it never names or contrasts any of the many related siblings such as phion_get_service, phion_preflight, or phion_discover.
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 wallet required' implies the usage context (pre-payment evaluation, cold-start without credentials), so the when-to-use is inferable. However, it never states when NOT to use it (e.g. when a paid call is actually intended) nor points at the alternative tool to use in that case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free verification of a PHION signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | ||
| receipt | Yes | ||
| sources | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds only 'Free', which is a useful pricing trait not covered by annotations, but it omits what verification actually checks, what an invalid receipt produces, and any return 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?
The single sentence is front-loaded and free of filler. However, its extreme brevity borders on under-specification for a tool with three parameters and no schema descriptions.
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 and 0% schema description coverage, the description should explain return semantics and parameter roles. It does not, leaving an agent unclear about what verification produces and how to use the optional parameters.
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%, and the description only hints at the required 'receipt' parameter via the phrase 'signed receipt'. It says nothing about the optional 'content' or 'sources' parameters, so it does not compensate for the undocumented 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 ('verification') and resource ('PHION signed receipt'), and adds the pricing trait 'Free'. It does not explicitly differentiate itself from siblings such as phion_preflight or phion_resolve, 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?
The description gives no when-to-use guidance, prerequisites, or alternatives. An agent must infer usage entirely from the tool name and title, with no exclusions or context about when this is preferable to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
agent_reputation_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "evidence": [],
+ "signals": {
+ "endpoint_reachable": true,
+ "identity_registered": true,
+ "successful_settlements": 4
+ },
+ "subject": {
+ "erc8004_agent_id": 86081,
+ "wallet": "0x..."
+ }
+ }
+]company_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "website": "example.com"
+ }
+]contact_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "company": "Example",
+ "minimum_likelihood": 6,
+ "name": "Ada Lovelace"
+ }
+]entity_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "expected_fields": [
+ "name",
+ "domain"
+ ],
+ "source_urls": [
+ "https://example.com"
+ ],
+ "subject": {
+ "name": "Example"
+ }
+ }
+]inspect_agent1 field changedInput schema / examplesAdded value: +[
+ {
+ "url": "https://agent.example/.well-known/agent.json"
+ }
+]person_enrichment_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "email": "ada@example.com",
+ "minimum_likelihood": 6
+ }
+]social_source_evidence1 field changedInput schema / examplesAdded value: +[
+ {
+ "query": "announcement",
+ "source_urls": [
+ "https://example.com"
+ ]
+ }
+]try_service1 field changedInput schema / properties / service / enumPrevious value: -[
- "attest",
- "payment-firewall",
- "web-evidence",
- "mandate-reserve",
- "agent-inspection",
- "commerce-journey",
- "transaction-assurance",
- "transaction-recovery",
- "rwa-asset-due-diligence",
- "rwa-compliance",
- "rwa-nav-reserve",
- "rwa-transaction-assurance",
- "rwa-corporate-actions",
- "schema-normalize",
- "sanctions-screening-evidence",
- "agent-reputation-evidence",
- "counterparty-risk-preflight",
- "tool-output-firewall",
- "delegation-scope-guard",
- "memory-write-guard",
- "mcp-manifest-firewall",
- "tool-call-policy-guard",
- "data-egress-preflight",
- "agent-budget-guard",
- "idempotency-replay-guard",
- "human-approval-policy",
- "secret-redaction-preflight",
- "oauth-token-audience-guard",
- "redirect-callback-validator",
- "tool-capability-drift-monitor",
- "mcp-server-identity-evidence",
- "agent-task-handoff-receipt",
- "context-provenance-labeler",
- "signed-result-comparator",
- "service-sla-attestation",
- "payment-route-selector",
- "x402-quote-comparator",
- "payment-receipt-reconciler",
- "duplicate-charge-detector",
- "subscription-spend-guard",
- "webhook-verifier",
- "delivery-evidence",
- "inter-agent-policy-evaluator",
- "concurrency-guard",
- "resource-cycle-guard",
- "abandoned-tool-detector",
- "manifest-version-diff",
- "dependency-provenance-assessment",
- "conflict-resolution",
- "data-freshness-certificate",
- "domain-ownership-evidence",
- "purpose-bound-consent",
- "retention-deletion-receipt",
- "interrupted-task-recovery",
- "portable-observability-audit",
- "index-feed",
- "verified-web-extract",
- "entity-enrichment-evidence",
- "social-source-evidence",
- "market-data-snapshot",
- "onchain-evidence",
- "verified-news-monitor",
- "multi-source-fact-bundle",
- "document-to-verified-json",
- "source-backed-search",
- "live-data-freshness",
- "person-enrichment-evidence",
- "company-enrichment-evidence",
- "contact-enrichment-evidence",
- "mcp-2026-compatibility-gateway",
- "durable-agent-task",
- "task-checkpoint-evidence",
- "task-cancel-assurance",
- "agent-approval-relay",
- "capability-negotiation-preflight",
- "mcp-catalog-cache-guard",
- "oauth-issuer-binding-evidence",
- "mcp-a2a-task-bridge",
- "quote-freshness-guard",
- "delegated-credential-guard",
- "agent-session-continuity",
- "task-lease-guard",
- "tool-result-schema-validator",
- "agent-memory-provenance",
- "payment-delivery-atomicity",
- "service-failover-selector",
- "agent-rate-limit-negotiator",
- "execution-cost-estimator",
- "cross-agent-receipt-bundle",
- "capability-verification",
- "capability-benchmark",
- "sybil-reputation-guard",
- "agent-behavior-fingerprint",
- "trust-anomaly-detector",
- "economic-loop-detector",
- "provider-quality-predictor",
- "transaction-risk-score",
- "payment-optimizer",
- "x402-v2-router",
- "erc8004-identity-evidence",
- "erc8004-reputation-intelligence",
- "delegated-spend-policy",
- "ap2-mandate-bridge",
- "a2a-transaction-bridge",
- "mcp-transaction-gateway",
- "proof-of-service",
- "automated-dispute-bundle",
- "transaction-recovery-v2",
- "reputation-update-receipt",
- "agent-economic-graph",
- "market-demand-predictor",
- "service-gap-detector",
- "price-discovery-engine",
- "sla-risk-predictor",
- "dynamic-service-pricing",
- "autonomous-procurement",
- "multi-agent-escrow",
- "cross-protocol-receipt",
- "phion-inference",
- "phion-search",
- "phion-enrich",
- "phion-intelligence"
-]New value: +[
+ "attest",
+ "payment-firewall",
+ "web-evidence",
+ "mandate-reserve",
+ "agent-inspection",
+ "commerce-journey",
+ "transaction-assurance",
+ "transaction-recovery",
+ "rwa-asset-due-diligence",
+ "rwa-compliance",
+ "rwa-nav-reserve",
+ "rwa-transaction-assurance",
+ "rwa-corporate-actions",
+ "schema-normalize",
+ "sanctions-screening-evidence",
+ "agent-reputation-evidence",
+ "counterparty-risk-preflight",
+ "tool-output-firewall",
+ "delegation-scope-guard",
+ "memory-write-guard",
+ "mcp-manifest-firewall",
+ "tool-call-policy-guard",
+ "data-egress-preflight",
+ "agent-budget-guard",
+ "idempotency-replay-guard",
+ "human-approval-policy",
+ "secret-redaction-preflight",
+ "oauth-token-audience-guard",
+ "redirect-callback-validator",
+ "tool-capability-drift-monitor",
+ "mcp-server-identity-evidence",
+ "agent-task-handoff-receipt",
+ "context-provenance-labeler",
+ "signed-result-comparator",
+ "service-sla-attestation",
+ "payment-route-selector",
+ "x402-quote-comparator",
+ "payment-receipt-reconciler",
+ "duplicate-charge-detector",
+ "subscription-spend-guard",
+ "webhook-verifier",
+ "delivery-evidence",
+ "inter-agent-policy-evaluator",
+ "concurrency-guard",
+ "resource-cycle-guard",
+ "abandoned-tool-detector",
+ "manifest-version-diff",
+ "dependency-provenance-assessment",
+ "conflict-resolution",
+ "data-freshness-certificate",
+ "domain-ownership-evidence",
+ "purpose-bound-consent",
+ "retention-deletion-receipt",
+ "interrupted-task-recovery",
+ "portable-observability-audit",
+ "index-feed",
+ "verified-web-extract",
+ "entity-enrichment-evidence",
+ "social-source-evidence",
+ "market-data-snapshot",
+ "onchain-evidence",
+ "verified-news-monitor",
+ "multi-source-fact-bundle",
+ "document-to-verified-json",
+ "source-backed-search",
+ "live-data-freshness",
+ "person-enrichment-evidence",
+ "company-enrichment-evidence",
+ "contact-enrichment-evidence",
+ "mcp-2026-compatibility-gateway",
+ "durable-agent-task",
+ "task-checkpoint-evidence",
+ "task-cancel-assurance",
+ "agent-approval-relay",
+ "capability-negotiation-preflight",
+ "mcp-catalog-cache-guard",
+ "oauth-issuer-binding-evidence",
+ "mcp-a2a-task-bridge",
+ "quote-freshness-guard",
+ "delegated-credential-guard",
+ "agent-session-continuity",
+ "task-lease-guard",
+ "tool-result-schema-validator",
+ "agent-memory-provenance",
+ "payment-delivery-atomicity",
+ "service-failover-selector",
+ "agent-rate-limit-negotiator",
+ "execution-cost-estimator",
+ "cross-agent-receipt-bundle",
+ "capability-verification",
+ "capability-benchmark",
+ "sybil-reputation-guard",
+ "agent-behavior-fingerprint",
+ "trust-anomaly-detector",
+ "economic-loop-detector",
+ "provider-quality-predictor",
+ "transaction-risk-score",
+ "payment-optimizer",
+ "x402-v2-router",
+ "erc8004-identity-evidence",
+ "erc8004-reputation-intelligence",
+ "delegated-spend-policy",
+ "ap2-mandate-bridge",
+ "a2a-transaction-bridge",
+ "mcp-transaction-gateway",
+ "proof-of-service",
+ "automated-dispute-bundle",
+ "transaction-recovery-v2",
+ "reputation-update-receipt",
+ "agent-economic-graph",
+ "market-demand-predictor",
+ "service-gap-detector",
+ "price-discovery-engine",
+ "sla-risk-predictor",
+ "dynamic-service-pricing",
+ "autonomous-procurement",
+ "multi-agent-escrow",
+ "cross-protocol-receipt",
+ "phion-inference",
+ "phion-search",
+ "phion-enrich-basic",
+ "phion-enrich",
+ "phion-intelligence"
+]
Add one secure layer between your agents and this server.
social_source_evidenceDInspect
Attributable public social-source observations with identity limitations; 0.006 USDC.
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose two useful facts — the results carry an "identity limitations" caveat and the call costs 0.006 USDC — but says nothing about payment/auth mechanics, whether the operation is read-only, rate limits, or what happens on failure.
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 sentence fragment, but brevity here reflects under-specification rather than tight editing — the price and caveat are packed in while the actual behavior is absent. There is no structure to front-load because there is almost no content.
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?
A paid, 3-parameter tool with a required array, a nested object, no output schema, no annotations, and 0% parameter documentation leaves the agent unable to invoke it correctly. The 0.006 USDC cost and vague identity caveat are nowhere near sufficient.
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% across three parameters, including a nested, unstructured "subject" object, and the description supplies no parameter meaning at all. An agent cannot infer what "subject" should contain or how "query" interacts with "source_urls" (1–5 URLs, required).
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 is a noun phrase ("attributable public social-source observations") rather than a verb+resource statement, so the agent cannot tell what action it performs. It also does not differentiate from siblings such as agent_reputation_evidence, company_enrichment_evidence, or entity_enrichment_evidence, which read almost identically.
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 guidance, no prerequisites, and no mention of any alternative tool such as try_service or preflight despite a large sibling set. The only contextual signal is a price, which does not help selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.