Skip to main content
Glama
Sign In

YouSpot

by com.youspot
OverviewDiscussionsAdmin

Delete brain objects in bulk

delete_graph_objects
Destructive

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

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.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description adds what the annotations cannot: the deletion is permanent, it operates at a scale of millions of records where partial cleanup is impractical, and crucially that in chat the tool deletes nothing itself — it counts records and hands the user a message whose click performs the deletion. That last detail materially changes how an agent should call and report the 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 critical scoping and safety information is front-loaded in the first sentence and the alternatives follow logically. It is dense and nearly every clause carries information, though the parenthetical example and the scale remark slightly overlap with the permanence warning.

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?

For a destructive, zero-required-parameter bulk tool with no output schema, the definition covers everything an agent needs: selection modes, exclusivity, permanence, consent requirements, and the actual return behavior (counts plus a user-facing message). Nothing consequential is left to inference.

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

Parameters5/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 goes well beyond the schema by explaining the side-effect footprint of each parameter: import_id removes 'its contacts, companies, notes and files, the uploaded file and the import itself', and source removes 'every connection a LinkedIn export loaded and the people made from them'. It also clarifies the three parameters are alternative selectors, not combinable filters.

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?

Opens with a specific verb and resource plus scope: 'Delete EVERY object of one type from the user's graph, however many there are.' It immediately distinguishes the bulk case from single-record deletion, so an agent can tell it apart from delete_graph_object and delete_selected_graph_objects without opening a 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?

Names the alternatives explicitly ('Deleting one object is delete_graph_object instead') and gives the trigger conditions for each mode: object_type for a whole category, import_id to undo one import, source for a LinkedIn export. It also sets a hard guardrail ('Use only when the user explicitly asked for these to go, never on your own initiative') and one-scope-per-call constraint.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources