Skip to main content
Glama
Sign In

YouSpot

by com.youspot
OverviewDiscussionsAdmin

Add to brain

create_graph_object
Destructive

Create a new object in the user's graph. Use when they ask to add something — a project, note, fact, web link, person, company, product, event, group, tag, or prompt. If an object of the same type and name already exists it is returned instead of duplicated; pass allow_duplicate=true only when the user confirms they want a second one. Set any of the type's own fields at creation with 'fields' (a domain_name's asking_price and source, a contact's phone); a name the type does not have is reported back with the names it accepts. Returns the object with its object_id for follow-up connecting.

Input Schema

NameRequiredDescriptionDefault
urlNoOptional URL (the link itself for web_link).
nameYesThe object's name (e.g. 'UNBOUND26 Keynote').
typeYesWhat kind of object to create.
emailNoFor contacts: their email address. Dedupes per address, and fills the address in on a contact of the same name that has none.
domainNoFor company objects: the company's website domain (e.g. 'openai.com'). Connects the company to its shared enrichment profile and dedupes per domain.
fieldsNoThe type's own fields to set on the new object, e.g. {'asking_price': 75000, 'source': 'GritBrokerage.com'}.
descriptionNoOptional longer description.
allow_duplicateNoCreate even if the same type+name exists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "contact",
-  "company",
-  "product",
-  "event",
-  "group",
-  "project",
-  "note",
-  "fact",
-  "web_link",
-  "tag",
-  "prompt",
-  "domain_name"
-]New value: +[
+  "contact",
+  "company",
+  "product",
+  "event",
+  "group",
+  "project",
+  "note",
+  "fact",
+  "web_link",
+  "tag",
+  "prompt",
+  "domain_name",
+  "linkedin_plan"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / fields
      Added value: +{
+  "description": "The type's own fields to set on the new object, e.g. {'asking_price': 75000, 'source': 'GritBrokerage.com'}.",
+  "type": "object"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and destructiveHint=true; the description adds real behavior beyond that — silent dedupe returning the existing object, what allow_duplicate overrides, that unknown field names are reported back with the accepted names, and that the response carries object_id. It doesn't explain why destructiveHint is true or what side effects creation has for linked/enrichment data.

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?

Five sentences, front-loaded with the core action and then the dedupe caveat, field handling, and return value. Dense but each sentence carries distinct information; the type enumeration in sentence two is slightly list-heavy but useful.

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 an 8-parameter creation tool with no output schema, the description covers creation, dedupe/skip semantics, the duplicate override, custom fields and their failure mode, and the returned object_id for follow-up connect_graph_objects calls. Nothing an agent needs to call it correctly is missing.

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 already 100%, so the bar is higher, yet the description still adds value: it explains the purpose of allow_duplicate in user-intent terms and shows that 'fields' takes the type's own domain fields ('a domain_name's asking_price and source, a contact's phone') with explicit error behavior for invalid names.

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?

The description opens with a specific verb+resource ('Create a new object in the user's graph') and enumerates the object kinds, which lets an agent distinguish it from siblings like set_graph_object_fields, connect_graph_objects, or get_graph_object. The scope is unambiguous.

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?

It gives a clear trigger ('Use when they ask to add something') and a precise rule for the tricky case: dedupe on type+name, and only set allow_duplicate=true when the user confirms a second one. It stops short of naming an alternative sibling (e.g., search_graph_objects to check first), so not a full 5.

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