Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Create or change a goal

connections_notes_save_goal
Destructive

Create a goal, or change one the member already has. A goal is one thing they are working toward, with a short title; Notes ranks notes and to-dos against it and Schedule's Focus blocks point at it. Pass id (from list_goals) to update; leave it out to create. An update replaces the title and the description together, so send the current description back to keep it. Set status to done when the member finishes it and archived to put it away; only active goals rank notes.

Input Schema

NameRequiredDescriptionDefault
idNoOptional. The goal to update, from list_goals. Omit it to create a new goal.
titleYesThe goal in a few words, as the member would say it.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
statusNoOptional. New goals start active; omit it on an update to keep the current status.
dry_runNoPreview only.
projectNoWorkspace to run this call in (id or name).
companyIdNoOptional. Workspace the goal belongs to; omit for the member's own.
descriptionNoOptional. What done looks like, or why it matters - the text notes are ranked against beside the title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview only; nothing is written."New value: +"Preview only."
  2. Changed3 schema fields changed
    • changedInput schema / properties / companyId / description
      Previous value: -"Optional. The workspace the goal belongs to, from the member's own company list. Omit it for the member's own goals."New value: +"Optional. Workspace the goal belongs to; omit for the member's own."
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview only: return what this call would do, with nothing written."New value: +"Preview only; nothing is written."
    • addedInput schema / properties / person
      Added value: +{
+  "description": "Linked person to run this call as (first name). Omit to run as the connection's holder.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

The annotations declare destructiveHint=true; the description explains exactly why — an update replaces title and description together, so the current description must be resent to keep it. It also discloses the side effect that only active goals rank notes, which is behavior no annotation or schema field conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the create/update split, then conceptual grounding, then the two highest-risk details (replace semantics, status effects). Nothing is repeated from the schema and no sentence is filler.

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

Completeness4/5

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

For an eight-parameter mutation with no output schema, the description covers the risky parts — mode selection, overwrite behavior, status transitions, cross-feature effects. It says nothing about what happens with dry_run or the person/project scoping, though those are documented in the schema itself.

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 baseline is 3; the description goes beyond it by stating replacement semantics for description and the lifecycle meaning of the status enum values. The routing fields (person, project, companyId, dry_run) are left entirely to the schema.

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 first sentence gives a specific verb and resource ("Create a goal, or change one") and immediately splits the create/update cases. The second sentence explains what a goal is and where it surfaces (Notes ranking, Schedule Focus blocks), which is enough for an agent to pick this over connections_note_save or connections_todo_add.

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?

Explicit routing: "Pass id (from list_goals) to update; leave it out to create," plus when to set status done vs archived. It does not name other candidate tools for adjacent needs (to-dos, notes), but the create-vs-update decision — the main ambiguity — is fully resolved.

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

All Connections 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