Skip to main content
Glama

atisbo_capture

Destructive

Capture Signals or knowledge; update, patch or add evidence to artefacts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesCapture mode. Mode-specific notes return in meta.guidance after the call.
noteNoWhy it matters or ingestion context.
textNoSignal text.
itemsNosignal_batch, max 100.
titleNoKnowledge or evidence title.
sourceNoSignal source. Defaults to manual.
contentNoKnowledge or artefact content.
evidenceNoEvidence fields; document_id is top-level.
modalityNoQ=Quote, O=Observation, M=Metric. Pipeline infers if omitted.
scope_idNoTarget scope UUID.
file_nameNo
mime_typeNo
patch_opsNo
agent_nameNoSigns the change.
scope_typeNoScope kind; company is treated as active workspace.
attachmentsNo1-5 files; 3 MB combined.
document_idNoLiving document UUID for artefact modes.
capture_modeNoKnowledge routing; default signals_only.
captured_fromNo
change_summaryNoArtefact change summary.
classificationNoSignal classification hint.
dirty_event_idNoDirty event resolved on success
knowledge_kindNo
coverage_updatesNoSnippet/idea/claim coverage updates.
expected_content_hashNocontent_hash from doc_patch_context
corrects_prior_evidenceNosignal: CORRECTS prior evidence, not repeats it.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed8 schema fields changed
    • addedInput schema / properties / attachments
      Added value: +{
      +  "description": "1-5 files; 3 MB combined.",
      +  "items": {
      +    "description": "PNG/JPG/WebP/PDF; no extraction.",
      +    "properties": {
      +      "data_base64": {
      +        "description": "Base64, ≤4200000 chars.",
      +        "maxLength": 4200000,
      +        "minLength": 4,
      +        "type": "string"
      +      },
      +      "file_name": {
      +        "description": "Name, ≤200 chars.",
      +        "maxLength": 200,
      +        "minLength": 1,
      +        "type": "string"
      +      },
      +      "mime_type": {
      +        "enum": [
      +          "image/png",
      +          "image/jpeg",
      +          "image/webp",
      +          "application/pdf"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "data_base64",
      +      "file_name",
      +      "mime_type"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 5,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • changedInput schema / properties / capture_mode / description
      Previous value: -"Routing; the signals_only default creates no reusable knowledge unless requested."New value: +"Knowledge routing; default signals_only."
    • changedInput schema / properties / change_summary / description
      Previous value: -"Public change description for update_artefact/patch_artefact (patch_artefact accepts note as fallback)."New value: +"Artefact change summary."
    • changedInput schema / properties / content / description
      Previous value: -"Document content — update_artefact fully replaces the doc."New value: +"Knowledge or artefact content."
    • changedInput schema / properties / evidence / description
      Previous value: -"add_artefact_evidence fields; document_id goes at top level. title aliases label, provider aliases kind."New value: +"Evidence fields; document_id is top-level."
    • changedInput schema / properties / items / description
      Previous value: -"signal_batch; max 100 items. Each needs text + client_request_id."New value: +"signal_batch, max 100."
    • changedInput schema / properties / scope_id / description
      Previous value: -"Required for node, claim, solution, and map scopes."New value: +"Target scope UUID."
    • changedInput schema / properties / text / description
      Previous value: -"Raw feedback/signal text (signal mode)."New value: +"Signal text."
  2. First observed

TDQS

C2.8/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness1/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

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