Skip to main content
Glama

YouSpot

by com.youspot
OverviewDiscussionsAdmin

Delete brain objects in bulk

delete_graph_objects

Delete EVERY object of one type from the user's graph, however many there are: what to reach for when they ask to clear out a whole category ('delete all my HubSpot contacts') rather than one record. Pass import_id instead to delete everything one import added (its contacts, companies, notes and files, the uploaded file and the import itself); imports are graph objects of type 'import_run'. Pass source 'linkedin_import' instead to delete every connection a LinkedIn export loaded and the people made from them. Deleting one object is delete_graph_object instead. This delete is permanent, and at this scale it is the only kind that helps: a synced portal can be millions of records. Use only when the user explicitly asked for these to go, never on your own initiative, and name one type, import or source per call. In chat this tool deletes nothing: it counts the records and returns what to tell the user, and their click starts the deletion.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceNo'linkedin_import': every connection a LinkedIn export import loaded.
import_idNoThe object_id of one import (type 'import_run'), to delete what it added.
object_typeNoThe type to clear out, e.g. 'hubspot_contact'. search_graph_objects and the brain's type counts both report types.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / import_id
      Added value: +{
+  "description": "The object_id of one import (type 'import_run'), to delete what it added.",
+  "type": "string"
+}
    • addedInput schema / properties / source
      Added value: +{
+  "description": "'linkedin_import': every connection a LinkedIn export import loaded.",
+  "enum": [
+    "linkedin_import"
+  ],
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "object_type"
-]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=false, so the description carries most of the burden and does so well: it declares the delete permanent/irreversible, warns about scale ('a synced portal can be millions of records'), and discloses the non-obvious chat behavior where the call only counts records and the user's click performs the deletion. It stops short of stating permissions or rate limits, but the safety-relevant traits are covered.

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?

Front-loaded with the core action and scope, and every subsequent sentence adds routing or safety value rather than filler. It is dense with parentheticals and runs long, which costs a point, but nothing is wasted.

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

Completeness5/5

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

No output schema exists, and the description compensates by explaining what the call returns in chat (a count and a message to relay). For a bulk, permanent deletion tool the agent has the trigger conditions, the destructive implications, and the per-call constraint needed to invoke it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine value beyond the schema: it explains the mutual exclusivity ('name one type, import or source per call') and what each mode actually removes (import_id also clears the uploaded file and the import itself; source clears the connections and the people derived from them). That is more than the enum/param descriptions alone convey.

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

Purpose5/5

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

Specific verb+resource with explicit scope: 'Delete EVERY object of one type from the user's graph.' It distinguishes the sibling that deletes a single record ('Deleting one object is delete_graph_object instead') and names the three distinct modes (type, import_id, source) in a way an agent can act on without opening the schema.

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

Usage Guidelines5/5

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

Gives a concrete trigger ('delete all my HubSpot contacts') versus the single-record case, and an explicit when-not ('Use only when the user explicitly asked for these to go, never on your own initiative'). Alternatives are named rather than implied, which is exactly the routing guidance an agent needs.

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

All YouSpot toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources