Skip to main content
Glama

Dayze — Life Context

Create Project

create_project

Add a project to the user's portfolio: name, kind (own_venture, client_work, side_project, other), status (active, paused, archived, idea), description, website, tags, notes. ($0.10; API key required)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_project"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindNoProject type: own_venture, client_work, side_project or other, e.g. side_project.
nameYesProject name, e.g. Dayze Mobile.
tagsNoTags, e.g. ["work"].
notesNoFree-text note, e.g. Follow up next week.
statusNoProject status: active, paused, archived or idea, e.g. active.
websiteNoWebsite URL, e.g. https://example.com.
request_idNoClient idempotency key (retries return original result).
descriptionNoWhat the project is, e.g. Coffee subscription for offices.
idempotency_keyNoAlias for request_id.

Output Schema

NameRequiredDescriptionDefault
accountNoThe Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
createdNo
messageNo
project_idNo
provenanceNoWhich connector wrote the record and which connected Dayze account received it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / properties / description / description
      Added value: +"What the project is, e.g. Coffee subscription for offices."
    • addedInput schema / properties / kind / description
      Added value: +"Project type: own_venture, client_work, side_project or other, e.g. side_project."
    • addedInput schema / properties / name / description
      Added value: +"Project name, e.g. Dayze Mobile."
    • addedInput schema / properties / notes / description
      Added value: +"Free-text note, e.g. Follow up next week."
    • addedInput schema / properties / status / description
      Added value: +"Project status: active, paused, archived or idea, e.g. active."
    • addedInput schema / properties / tags / description
      Added value: +"Tags, e.g. [\"work\"]."
    • addedInput schema / properties / tags / items / description
      Added value: +"Tag, e.g. work."
    • addedInput schema / properties / website / description
      Added value: +"Website URL, e.g. https://example.com."
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false and openWorld=false, so the safety profile is covered. The description adds genuinely new operational context the annotations do not carry: a $0.10 per-call cost and the API-key requirement, both of which affect whether an agent should invoke it. It does not explain duplicate-name behavior, but the cost/auth disclosure is real value beyond structured fields.

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?

A single front-loaded sentence names the action first, then the fields, then cost/auth as a trailing parenthetical. It is efficient, though re-listing all seven attributes is largely redundant against a fully described schema and the parenthetical is terse to the point of being cryptic.

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?

An output schema exists and annotations cover the safety profile, so the description need not explain returns. For a 9-parameter mutation tool it supplies purpose, cost and auth, leaving only minor gaps such as uniqueness/duplicate handling under retries.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including the enums and the request_id/idempotency_key aliases is already documented. The description's field list and enum values restate the schema rather than adding meaning, and it omits the idempotency behavior entirely, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Add a project to the user's portfolio') and enumerates the creatable attributes, so an agent can tell this is the creation entry point for projects rather than goals or todos. It stops short of naming any sibling to differentiate from, so a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied by 'Add a project to the user's portfolio'; there is no explicit when-to-use, when-not-to-use, or alternative named among the many create_* siblings such as create_goal or create_tracker. The 'API key required' note hints at a prerequisite but is not framed as operational guidance.

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.