Atisbo

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

Annotations already mark the tool read-only and non-destructive. The description adds useful behavioral context beyond that: it is an aggregate/broad query and produces a ready-to-render chart artifact, which signals output shape and non-mutating behavior. No contradiction with the annotations.

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

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

Two front-loaded sentences: the first conveys the core function and capabilities, the second gives routing guidance. Every sentence earns its place with no filler or duplication of schema details.

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 10 parameters, nested objects, an output schema, and read-only annotations; the description supplies the missing high-level overview and selection logic. It tells the agent when to call analyze versus lookup, while parameter and output details are fully covered by the schemas.

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 references time filters, grouping, metrics, and chart output, but adds no parameter-level meaning beyond the schema. The schema already documents aliases, defaults, constraints, and filter semantics.

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: 'analytical query over claims, solutions, or activity' with time filters, grouping, metrics, and a chart artifact. It also differentiates itself from atisbo_lookup by noting that lookup suffices for single-entity drill-downs.

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 tells the agent to use this tool first for analytical questions spanning entities or time windows, and names atisbo_lookup mode=claim and mode=node as alternatives for single-entity drill-downs. This provides clear when-to-use and when-not-to-use 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?

The annotations already indicate a destructive write operation (readOnlyHint=false, destructiveHint=true), and the description's 'update, patch or add' is consistent with that. However, the description adds no behavioral detail beyond the annotations—no mention of artefact mutation effects, idempotency keys, dirty_event_id side effects, or mode-specific consequences, which is significant for a destructive tool.

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 compact sentence with no filler, and the primary action is front-loaded. However, it is so terse that it fails to convey mode routing, so conciseness comes at the cost of practical guidance.

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?

This is a high-complexity tool with 26 parameters, six modes, nested objects, and no output schema, yet the description provides only a one-sentence overview. It gives no indication of which parameters apply to which mode, no mode-specific contracts, and no behavioral caveats, leaving the agent severely under-informed for correct invocation.

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 81%, so the schema already documents most parameters in detail, including mode, evidence, and patch_ops. The description itself only restates broad resource categories and provides no extra parameter-level meaning, so it neither helps nor hurts beyond the high-coverage 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?

The description states a clear verb ('Capture') and resource ('Signals or knowledge') and also names additional artefact operations ('update, patch or add evidence to artefacts'). It broadly distinguishes this tool from analysis or support siblings, but it does not explain the mode-driven dispatch, so the scope remains somewhat broad.

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 guidance on when to use this tool versus siblings or how to choose between the six modes in the schema. The description does not mention alternatives, prerequisites, or mode selection criteria, leaving the agent to infer usage entirely from the parameter schema.

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 annotations indicating destructiveHint=true, the description goes beyond by disclosing critical behavioral traits: Atisbo only READS a connected system, never writes; create returns an endpoint + signing secret shown EXACTLY ONCE and must be relayed immediately; config is stored encrypted and never readable again. These are exactly the kind of non-obvious behaviors an agent needs to know.

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 dense and front-loaded with the primary purpose (CONNECTS), and each sentence earns its place: modes summary, list-first rule, boundary expansion, read-only rule, and one-time secret warning. It loses one point because the heavy use of ALL-CAPS and the density of information could be slightly overwhelming, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter tool with no output schema and nested objects, the description supplies the missing contexts: when to call list, catalog fallback behavior, read-only guarantee, one-time secret handling, pull-vs-instant distinction, and mode-to-parameter mapping. There is no output schema, so the return-value guidance ('catalog (ingestible sources; query filters)', 'create returns the endpoint') is appropriately brief but 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?

Although schema coverage is 100%, the description adds crucial cross-parameter semantics: which parameters apply to which modes, that kwargs must pair with native_providers, that json_paths.raw_text is REQUIRED, and that sync_every applies only to PULL sources. It also explains consequences of parameter choices (e.g., email provisions an ingest address). This goes beyond the 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?

The description names a specific verb (CONNECTS) and resource (Atisbo sources/signals), and immediately distinguishes itself from merely describing them. It enumerates concrete modes list, catalog, create, configure, pause, resume, sync_now, composio variants, making the tool's scope unmistakable and differentiating it from siblings like atisbo_analyze or atisbo_capture.

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 instructions: 'Call list before any mutation', and warns against answering from an empty search, directing the agent to call catalog and read fallback. It also explains the CAPABILITIES boundary ('almost anything connects') and provides alternatives by mode. This is strong routing guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds that mutations self-log, that writes need UUIDs, and that declare_pm_exception marks a claim for human decision, which is useful beyond annotations, but it does not describe what gets destroyed, permission needs, or mode-specific side effects.

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 short, front-loaded with the tool’s role, and groups modes into three readable categories. It avoids restating schema details, though the dense acronyms (SEN-180) and terse mode groups make it less than perfectly clear.

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-mode, 78-parameter facade with no output schema and only minimal annotations, the description gives a useful overview but does not explain how to choose among modes, handle errors, or interpret meta.guidance. Schema coverage is high, so it is adequate but not 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 91%, so the schema already documents nearly all parameters. The description adds little parameter-level meaning beyond reinforcing that writes require UUIDs and one mode-specific rule; 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 names the tool as a 'PM decision facade' and enumerates mode groups (CURATE, EXECUTE, DOCUMENT/GOVERN) plus specific operations like Solutions, Outcomes, living docs. It clearly establishes a broad decision-management purpose, but it does not name a sibling tool or draw an explicit boundary against atisbo_lookup/analyze, so it falls short of a 5.

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

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

It gives category-level routing (CURATE/EXECUTE/DOCUMENT/GOVERN) and one explicit rule—'log_decision is only for external decisions; mutations log themselves'—but lacks when-not-to-use guidance and never names an alternative sibling. This is implied usage rather than explicit alternatives.

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 signal readOnlyHint=true and destructiveHint=false, so the description is not required to re-establish safety. It adds a little behavioral context by listing what modes expose (snippet text, attachment URLs, queues, outcomes, implementation context), but it does not disclose deeper behaviors like pagination, mode-specific meta.guidance, or per-mode result shapes.

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 short, front-loaded, and free of redundant schema repetition. The second sentence is a bit vague but still earns its place by hinting at the breadth of output categories.

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?

This is a complex, mode-driven tool with 32 parameters and no output schema, yet the description only offers a broad overview. It does not explain how modes relate to required inputs, what typical return shapes look like, or how to resolve entities — making the description inadequate for confident first-time invocation.

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 schema already documents all 32 parameters and their mode associations. The tool description itself adds no parameter-level semantics; therefore the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb-resource pair ('Find or open Atisbo entities') and gives a high-level sense of what the modes expose. It does not explicitly differentiate it from sibling tools like atisbo_analyze or atisbo_map, so it stops 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 guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions. The 'lookup' name implies retrieval, but the description never states the boundary against sibling tools or mentions exclusions.

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 indicate destructiveHint=true, and the description warns about STALE_DATA concurrency failures, preview-before-executing for regroup, and the distinction between modes that refuse certain maps. It adds behavioral context about the two ways to put claims on nodes and that mode-specific guidance returns in meta.guidance after the call. It could disclose more about the destructive implications of delete/delete_node/delete_edge modes, but the annotation already flags destructiveness so the bar is lower.

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 dense, front-loaded single paragraph that packs mode semantics into the first sentence, then dedicates the second sentence to the crucial anchor-vs-link_claims distinction. It is long but every clause earns its place, especially the mode list that agents need to understand before touching any parameter. Slight length cost, but high information density.

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 45-parameter tool with no output schema, the description does a solid job orienting the agent to the mode-driven dispatch model, the taxonomy-vs-structural distinction, and the important operational caveats like preview and STALE_DATA. It doesn't enumerate every mode's parameters, but the schema covers parameters and meta.guidance is promised for after-call mode-specific notes. A fuller breakdown per mode would be nice, but the description gives enough to start correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 64% schema coverage, the schema already documents many parameters like mode, name, note, etc. The description adds meaning beyond the schema for the critical distinction between anchor and link_claims membership, the 'refusing non-taxonomy maps' / 'refusing taxonomy maps' constraints, and the preview-before-execute guidance for regroup. Most parameters are individually documented in the schema, so the description complements rather than repeats.

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 a compact facade for map work with explicit mode list: create/apply maps, generate/edit nodes and edges, anchor claims, bind metrics, manage claim-snipe maps, regroup claims. It names the specific resource (map) and differentiates between two ways to put a claim on a node (anchor vs link_claims), which distinguishes its purpose from siblings.

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: 'Prefer mode=apply for full MECE categorization' and clearly distinguishes between mode=anchor (taxonomy category) and mode=link_claims (structural map membership), explaining when each is appropriate and that they are not interchangeable. It also warns about refusing non-taxonomy vs taxonomy maps, which helps the agent select the correct mode.

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 the tool readOnly/non-destructive, so the bar is lower. The description adds behavioral context: it is an orientation/snapshot operation that should continue the existing workflow, never create a parallel backlog, and edits are routed through other tools (lookup then capture), implying orient itself is purely informational. No contradiction with annotations.

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

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

Three sentences front-load the core modes before giving workflow routing, and each sentence carries information. It is dense and slightly jargon-heavy ('claim depth', 'parallel backlog'), but not bloated or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, parameter-rich tool with full schema coverage, the description provides enough operational context, including mode-specific behaviors and how to continue with sibling tools. The absence of any mention of return format is a minor gap since no output schema exists, but the mode semantics and schema largely compensate.

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 covers 100% of parameters, including enum meanings and limit clamp behavior, so the baseline is 3. The description's mode list and 'depth=work for the full corpus' hint lightly supplement the schema but mostly restate it, so no higher score is earned.

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 distinct action, 'Workspace orientation,' and enumerates four modes with parenthetical meanings (snapshot overview, whats_new delta, strategy, integrations), so an agent can identify the resource and primary intent. It does not sharply contrast against siblings like atisbo_map or atisbo_lookup, but the sibling-routing sentences imply orient is the top-level orientation entry point.

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 mentions continuing the user's existing workflow and never creating a parallel backlog, and it directs follow-on actions to atisbo_lookup, atisbo_analyze, and atisbo_capture. However, it does not explicitly state when orient should be preferred over siblings or list exclusions, so the guidance is more workflow context than crisp when-to-use/alternatives 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?

The description states that 'share_report files only diagnostics + your text', and the schema confirms the tool can 'File a verdict-only report', which is a write/side-effect behavior. However, annotations declare readOnlyHint=true, meaning the tool is expected not to modify state. This directly contradicts the described behavior, so the score must be 1 and flagged as an 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?

The description is tight and front-loaded: it names the verb and resource first, gives concrete examples, summarizes the diagnostic pipeline, and closes with sibling routing. Every sentence earns its place, though the dense phrasing around 'gates and key scope' could be clearer.

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 diagnostic tool with an output schema and rich parameter descriptions, this is nearly complete: it covers typical symptoms, what checks run, the playbook return, report filing behavior, and when to use alternatives. It loses a point due to the annotation contradiction and because 'gates and key scope' are named but not clarified.

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 schema already documents all four parameters in detail. The description adds little beyond restating the share_report filing behavior and pointing to alternative tools, which does not materially expand parameter understanding beyond the baseline.

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, 'Diagnose Atisbo', and gives concrete symptom examples that make the tool's job unmistakable. It also names the sibling alternatives for backlog work, so an agent can distinguish it from atisbo_lookup and atisbo_analyze.

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 explicitly says when to use the tool ('I connected a source and nothing appeared', 'I sent text and no opportunity formed', 'my data is missing') and tells the agent to use atisbo_lookup or atisbo_analyze for backlog instead. This is clear, actionable routing guidance.

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