remoet

Save Project

save_project

Add or update a portfolio project (upsert). Omit id to create (title and shortDescription are required); pass an id (from get_profile) to update, changing only the fields you send. Projects are the #1 differentiator for junior/mid developers. Help the user recognize work they might not think of: side projects, open-source contributions, hackathon entries, internal tools, time-saving scripts, blogs, personal apps. Saving without an id always creates a new entry. Saved entries appear on the user's public profile, so they should describe real work.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Present: update this project (only the fields you pass change). Omit: create a new one (title and shortDescription are required to create).
`role`	No	Your role in the project
`title`	No	Project title
`demoUrl`	No	Live demo URL
`endDate`	No	End date: a date, e.g. "2024-01-15"
`repoUrl`	No	Repository URL
`isRemote`	No	Whether this was remote work (default false on create)
`isCurrent`	No	Whether this is an ongoing project (default false on create)
`startDate`	No	Start date: a date, e.g. "2024-01-15"
`description`	No	Full project description
`isOpenSource`	No	Whether this is open source (default false on create)
`technologies`	No	Technologies used
`shortDescription`	No	A one-line summary of the project

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedSep 25, 2026

changedInput schema / properties / demoUrl / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 500,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / endDate / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 64,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / endDate / description

Previous value: -"End date (ISO 8601)"New value: +"End date: a date, e.g. \"2024-01-15\""

changedInput schema / properties / repoUrl / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 500,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / shortDescription / minLength
```
Added value: +1
```

changedInput schema / properties / startDate / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 64,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / startDate / description

Previous value: -"Start date (ISO 8601)"New value: +"Start date: a date, e.g. \"2024-01-15\""

addedInput schema / properties / title / minLength
```
Added value: +1
```

First observedSep 16, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With annotations declaring readOnlyHint=false, openWorldHint=false, idempotentHint=false, and destructiveHint=false, the description adds critical context: upsert behavior (create if no id, update if id), partial update semantics (only sent fields change), and the public visibility of saved entries. This goes well beyond what annotations provide.

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?

The description is front-loaded with the upsert behavior and create/update conditions, followed by motivational context and examples. Every sentence earns its place, with no redundancy.

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?

Given the 13 parameters, no output schema, and the description's thorough explanation of creation vs. update, required fields, and public visibility, it provides all necessary information for an agent to invoke the tool correctly. The annotations already cover safety hints, and the description fills the remaining gaps.

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 schema already documents all 13 parameters. The description reinforces the core semantics of the id parameter (create vs. update, required fields on create) and emphasizes the upsert pattern, adding clarity beyond the schema's per-parameter descriptions.

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 explicitly states the tool's function as an upsert for portfolio projects, distinguishing create vs. update behavior by the presence of an id. It clearly differentiates from siblings like save_education and save_work_experience by focusing on projects.

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 clearly explains when to create (omit id) and when to update (pass id), and provides detailed guidance on recognizing project types. However, it doesn't explicitly contrast with sibling save tools or mention when not to use this tool.

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

All remoet tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?