Atisbo

atisbo_map

Destructive

Compact facade for map work: create/apply maps, generate/edit nodes and edges, anchor claims/snippets, bind metrics, manage claim-snipe maps, regroup claims (merge/split — mode=regroup). Prefer mode=apply for full MECE categorization. TWO WAYS TO PUT A CLAIM ON A NODE, not interchangeable: mode=anchor sets the TAXONOMY category (claims.auto_node_id — one per claim, what the Board groups by), refusing non-taxonomy maps; mode=link_claims adds membership in a STRUCTURAL map (KPI tree, opportunity tree) while the claim keeps its category, refusing taxonomy maps.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	Mode-specific notes return in meta.guidance after the call.
`name`	No	Map, node, or metric name depending on mode.
`note`	No	link_claims: why these claims sit under this driver; stored on every link.
`label`	No
`level`	No	Node hierarchy depth.
`map_id`	No	Map UUID.
`anchors`	No	Batch claim anchors.
`edge_id`	No	Edge UUID for delete_edge mode.
`node_id`	No	Node UUID.
`preview`	No	regroup: read-only preview of the merge/split. ALWAYS preview before executing.
`branches`	No	Branches for apply mode.
`claim_id`	No	Claim UUID — resolve names with atisbo_lookup mode=resolve first
`map_type`	No
`provider`	No	Metric provider, e.g. posthog, amplitude, stripe, manual.
`template`	No
`bindingId`	No	Alias for binding_id.
`claim_ids`	No	link_claims: claims to place under node_id.
`direction`	No	regroup: broader merges similar claims, specific splits claims apart.
`edge_type`	No
`new_level`	No	New depth after a move.
`parent_id`	No	Parent node UUID.
`updatedAt`	No	Alias for updated_at.
`binding_id`	No	metric_update: binding to update — from atisbo_lookup mode=node (metrics[].id).
`event_name`	No
`snippet_id`	No
`updated_at`	No	metric_update: binding updated_at from your last read; concurrent edits fail STALE_DATA rather than overwrite.
`assignments`	No
`description`	No	Map/node/branch description. ≤2000 chars.
`metric_name`	No
`metric_type`	No
`currentValue`	No	Alias for current_value.
`target_value`	No
`current_value`	No	metric_update: today's value; appended as a same-day point when no historical_data (re-entry replaces it, not stacked).
`grouping_mode`	No
`new_parent_id`	No	Move target parent; null promotes to root.
`regroup_level`	No	For mode=regroup, direction=broader: how aggressively to merge.
`source_map_id`	No
`branch_options`	No
`historicalData`	No	Alias for historical_data.
`source_node_id`	No
`target_node_id`	No
`context_answers`	No	Grounding answers for AI map generation.
`historical_data`	No	metric_update: full series REPLACEMENT. Omit to append current_value as a same-day point instead.
`time_range_days`	No
`target_threshold`	No	For mode=regroup, direction=specific: split similarity threshold (0.50–0.98).

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already supply readOnlyHint=false and destructiveHint=true. The description adds meaningful behavioral detail beyond that: mode=anchor sets the taxonomy category with one category per claim, refusing non-taxonomy maps, while mode=link_claims adds structural membership without changing the claim's category and refuses taxonomy maps. This helps the agent predict refusals and side effects without contradicting 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.

Conciseness4/5

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

The description is dense but every sentence earns its place: a one-line capability summary, a recommendation for 'apply', then the critical anchor-vs-link distinction. It is appropriately sized for a 17-mode facade, though it could be slightly more scannable with bullet separation.

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

Completeness3/5

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

For a tool with 45 parameters, 17 modes, and no output schema, the description gives solid orientation but leaves several modes under-explained (e.g., claim-snipe sync, edge creation, metric updates). The schema and the in-schema note about 'meta.guidance' help fill gaps, but an agent would still need to discover mode-specific behaviors through experimentation.

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

Parameters4/5

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

With 64% schema coverage, the schema carries much of the parameter documentation, but the description adds high-value semantics for the central 'mode' parameter and related claim-placement fields. It clarifies what 'anchor' vs 'link_claims' actually do to a claim's category and explains the purpose of 'regroup'. The remaining parameters are reasonably documented in the schema, so the description compensates where it matters most.

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

Purpose4/5

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

The description opens with a clear scope ('Compact facade for map work') and enumerates concrete actions: create/apply maps, edit nodes and edges, anchor claims, bind metrics, manage claim-snipe maps, and regroup claims. It is broad because the tool is a multi-mode facade, but it still names specific resources and verbs, and the domain is clearly distinct from the sibling atisbo_ tools.

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

Usage Guidelines4/5

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

The description gives explicit routing guidance: 'Prefer mode=apply for full MECE categorization' and contrasts the two claim-placement modes, stating they are 'not interchangeable' and specifying which map types each mode accepts or refuses. It does not discuss when to prefer this tool over sibling tools, but within the tool's many modes it provides actionable direction.

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

All Atisbo tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool occupies a distinct functional domain: analysis, capture, connections, decisions, lookup, mapping, orientation, and support. Overlapping cases are explicitly disambiguated in descriptions, such as analyze-for-aggregates vs lookup-for-single-entities and the two non-interchangeable claim-to-node modes in map.

Naming Consistency5/5

All tools follow the same atisbo_<verb> pattern with lowercase snake_case and no mixed conventions. The prefix makes the server identity clear, and every tool name is a concise, predictable verb-like facade.

Tool Count5/5

Eight tools is a well-scoped count for a broad product surface: each tool is a compact facade grouping related modes rather than a scattered collection of one-off operations. There are no trivial or redundant tools.

Completeness5/5

The set covers the core workflow end to end: connect sources, capture signals, look up and analyze entities, map claims, make decisions, orient the workspace, and diagnose failures. Cross-references between tools fill in supporting steps like opening snippet refs and patching living docs, leaving no obvious dead ends.

Resources

Need Help?