Stobox Intelligence & Tokenization

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

With no annotations, the description carries the full burden of behavioral disclosure. It describes what the tool produces (a briefing with passages, facts, URLs) and that it uses 'verified Stobox knowledge,' but it does not reveal whether the operation is read-only, how it handles unknown queries, or any rate limits/error behavior. This is 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?

The description is two sentences, front-loaded with the core action and output contents, followed by a clear use instruction. Every word earns its place with no fluff or redundancy.

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 tool with no output schema, the description covers the main purpose and output content, but it omits parameter semantics (especially max_chars) and any edge-case behavior. It is sufficient for a basic understanding but lacks full completeness for a new 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 0%, so the description must explain the parameters. It implies 'query' is the tokenization question ('for answering a tokenization question') but never explicitly describes parameters. 'max_chars' is completely undocumented, so the agent has no guidance on how the length limit behaves or why it matters.

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 clearly states the tool's function with a specific verb and resource: 'Build a source-linked briefing' for answering a tokenization question. It lists concrete output components (top passages, entity facts, source URLs) and positions itself as a prompt-ready aggregation tool, distinguishing it from sibling tools like stobox_knowledge_search or stobox_fact_check.

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 provides a clear usage context: 'Use it to ground an answer in verified Stobox knowledge before responding.' This tells the agent when to invoke the tool, but it does not explicitly mention alternative tools or situations where it should not be used, so it stops short of a full when/when-not guide.

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

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

With no annotations, the description carries the full burden. It discloses the return value structure (verdict types, violations with corrections, canonical evidence) and the 'before repeating or publishing' context. It does not mention side effects or permissions, but the read-only nature of fact-checking is reasonably inferred.

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 concise sentences. The first sentence front-loads the purpose and indicates when to use it. The second sentence enumerates expected outputs without redundancy. No filler or repetition of schema fields.

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 tool with no output schema, the description is complete: it explains what the tool does, when to use it, what claims to submit, and what the output will contain. The sibling context is sufficiently differentiated.

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 schema already describes 'claim' as 'The factual claim to verify.' The description adds domain-specific context (Stobox, tokenization, specific topics like STBX and ERC-7943), which helps the agent provide a more targeted claim for verification.

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 begins with a specific verb 'Verify' and clearly identifies the resource: the CANONICAL Stobox knowledge graph. It distinguishes itself from sibling search/answer tools by framing the action as fact-checking with verdict outputs, not general knowledge retrieval.

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 explicit when-to-use guidance: 'Call this on every factual claim about STBX, ERC-7943, Compass chains, Gene Deyev's title, etc.' It does not explicitly state when not to use it or name alternatives, but the context of verification vs. search is clear from the sibling names.

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?

No annotations are provided, so the description carries the transparency burden. It discloses useful behavioral details (verified, source-linked, GraphRAG expansion), but it omits other behavioral aspects like return format, rate limits, or any limitations. This is 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?

The description is two sentences, front-loaded with the main action and scope, and every sentence adds value. There is no unnecessary padding or repetition.

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 search tool with two parameters and no output schema, the description covers the search scope, topics, and retrieval approach. It doesn't detail the response format, but that is not critical for a search tool. The minor gap prevents a 5.

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% for the two parameters (query and k), so the schema already documents them fully. The description adds no extra parameter semantics beyond restating the search scope, 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?

The description clearly states the tool searches Stobox's verified knowledge base on real-world-asset tokenization, listing specific topics covered. However, it does not explicitly differentiate from sibling tools like stobox_fact_check or stobox_term_lookup, so it stops short of a top score.

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 provides a 'Use for any question about...' clause with a comprehensive topic list, giving clear context for when to use the tool. It does not mention alternatives or when not to use it, so it lacks the full when/when-not guidance for a 5.

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

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

With no annotations, the description carries the full burden. It discloses the hop range (1–2) and the nature of traversal, which adds useful behavioral context. However, it does not mention pagination, output format, or any side effects, though it clearly indicates a read-only query operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that communicates the core purpose and key constraint without wasted words. It is efficiently structured and easy to parse.

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?

The tool has no output schema and only two parameters. The description covers the main purpose and relationship scope, but does not mention what the result looks like (e.g., list of terms, types) or handle edge cases like no results or invalid names. It is adequate for a simple query but leaves some operational 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 coverage is 0%, so the description must compensate. It partially explains the 'hops' parameter through '1–2 relationship hops out', but does not explicitly map the parameter to the number of hops or explain the 'name' parameter beyond implying it is the starting term. The description adds some meaning but 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 clearly states the tool shows connected terms in the Stobox knowledge graph with specific relationship types (products, standards, regulations, concepts) and a defined traversal depth (1–2 hops). This distinguishes it from siblings like stobox_term_lookup, which likely returns a single term definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when exploring relationships in the knowledge graph, but it does not explicitly state when to use this tool versus alternatives such as knowledge_search or term_lookup. No exclusions or alternate tool references are given, but the purpose is contextually clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It transparently states that the email is shared with Stobox, that consent is required, that a specialist will contact the user, that a confirmation and next steps are returned, and that the agent must never invent an email. This exceeds the typical level of 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?

The description is a single dense paragraph, but every sentence contributes either a purpose, a condition, or an exclusion. It is front-loaded with the core action and then adds guardrails. Slightly long but appropriately detailed for a tool with consent/privacy implications.

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 there is no output schema, the description explicitly states the return value ('confirmation + next steps'). It covers prerequisites, exclusions, data handling (email sharing with consent), and the do-not-invent rule. This fully equips the agent to use the tool appropriately.

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 high (83%), so the baseline is 3. The description adds important behavioral context beyond the schema: it emphasizes that email is required and must come from the user ('Never invent an email; ask the user for it first'), and that asset_type must be the user's stated intent. This goes beyond the schema descriptions, earning a 4.

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: 'Send the user's request to start tokenizing their real-world asset to the Stobox team.' It clearly distinguishes from the sibling search/lookup tools by saying 'Do NOT call for general questions — use the search/lookup tools for those.' This is a specific, well-scoped action.

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?

Provides explicit criteria for when to call: 'ONLY when the user explicitly wants to BEGIN... has told you what asset... and consents to be contacted.' It also explicitly lists exclusions ('Do NOT call for general questions') and names the alternative tool category (search/lookup tools). This is exemplary 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?

No annotations are provided, so the description carries the burden. It discloses that the tool returns authoritative descriptions, aliases, relationships, and source documents, indicating a read-only lookup. However, it does not mention behavior for unknown terms, case sensitivity, or potential errors, which limits full transparency for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with no unnecessary words. It front-loads the action ('Explain one term'), includes examples, and states the output, making it efficient and easy to parse.

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 lookup tool with no output schema, the description provides sufficient information: input examples and expected output content. It does not cover error handling or integration with sibling tools, but these are not critical for a straightforward lookup of this nature.

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 schema has one 'name' parameter with no description (0% schema coverage), so the description compensates by providing concrete examples ('STBX', 'Compass', 'ERC-7943', 'MiCA') and explaining that the parameter is the term to look up. This adds meaningful value beyond the schema's bare type definition.

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 clearly states the tool explains a single term, product, standard, or regulation from the Stobox knowledge graph, with specific examples. It distinguishes this from sibling tools by emphasizing 'one term' and listing output types (description, aliases, relationships, source documents), making it specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it is used for looking up a specific term, but it does not explicitly state when to use this tool versus alternatives like stobox_knowledge_search or stobox_related_topics. No exclusions or conditions are provided, leaving the usage context implicit rather than explicit.

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