moamcp

Overview Schema Source Related Servers Discussions Admin

moa_tip_create

Create a project-level Tip in the explicitly selected workspace, capturing insights with metadata like tags, status, sources, and next actions.

Instructions

Create a project-level Tip in the explicitly selected workspace.

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": {
      "workspace": "<workspace>",
      "title": "<title>",
      "summary": "<summary>"
    },
    "name": "moa_tip_create"
  }
}

Input Schema

Name	Required	Description
`tags`	No
`title`	Yes
`author`	No
`module`	No
`status`	No
`context`	No
`summary`	Yes
`workspace`	Yes	Absolute project path. Tips never infer a workspace from the MCP process cwd.
`nextAction`	No
`sourceRefs`	No
`documentRefs`	No
`relatedTipIds`	No
`relatedProjects`	No
`sourceSessionId`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.13.0Aug 10, 2026

TDQS

B3.1/5.0

Behavior2/5

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

There are no annotations, so the description must fully disclose behavior. It only notes that the workspace must be explicitly selected, but does not describe side effects, required permissions, validation behavior, or what happens on creation. The 'create' action implies mutation but no further details are given.

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 a single sentence with no filler words and is front-loaded with the key action and scope. Every word earns its place, making it highly concise and well-structured.

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

Completeness2/5

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

This create tool has 14 parameters, no annotations, and no output schema, yet the description provides only a minimal purpose statement. It does not explain what constitutes a Tip, required fields, workflow implications, or relationship to other tip operations, making it inadequate for the tool's complexity.

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

Parameters2/5

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

Schema description coverage is only 7%; only the workspace parameter has a description. The tool description does not explain the required 'title' and 'summary' fields or any of the 11 optional parameters. It merely reiterates the workspace selection behavior already in the schema, failing to add meaning beyond it.

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 uses a specific verb+resource ('Create' a 'Tip') and adds scope qualifiers ('project-level', 'explicitly selected workspace'), which clearly distinguishes it from sibling tip tools like read, list, update, archive. This makes the tool's purpose unmistakable.

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

Usage Guidelines2/5

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

No guidance is provided about when to use this tool vs alternatives such as moa_tip_update or moa_tip_archive. The description only states the action and scope, leaving the agent to infer usage from sibling names.

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