Skip to main content
Glama

Add to brain

create_graph_object

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

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

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

Goes well beyond the readOnlyHint=false annotation: it discloses dedup-by-type+name behavior, that the existing object is returned instead of duplicated, the exact condition for allow_duplicate, and that unknown field names are reported back with the accepted names. It also states the return shape (object with object_id).

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-loads the core action and dedup rule before secondary details, with no filler sentences. Dense but each clause carries distinct information; slightly long for a single paragraph.

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?

With 8 parameters, a nested 'fields' object, and no output schema, the description covers the missing pieces: dedup semantics, allow_duplicate conditions, field-bag usage, and the return value. Nothing an agent needs to call it correctly is absent.

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 real meaning: it explains the 'fields' bag with concrete per-type examples (domain_name asking_price/source, contact phone) and clarifies url usage for web_link, extending beyond the raw schema text.

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?

States a specific verb+resource ('Create a new object in the user's graph') and enumerates the object kinds it handles. An agent can distinguish this from siblings like connect_graph_objects, set_graph_object_fields, and list_graph_objects without opening any schema.

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?

Gives clear triggering context ('Use when they ask to add something') and a specific exclusion for allow_duplicate ('only when the user confirms they want a second one'). It gestures at follow-up connecting via object_id but does not explicitly name the alternative tool (connect_graph_objects) for that step.

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.