amulen-mcp

by lramirezq

Overview Schema Source Related Servers Discussions Admin

Python

Local

amulen_create_project

Creates a new project and makes the creator its admin so MCP clients can start managing boards, tasks, and team access.

Instructions

Create a project. The creator becomes its admin.

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": {
      "nombre": "<nombre>"
    },
    "name": "amulen_create_project"
  }
}

Input Schema

Name	Required	Description	Default
`nombre`	Yes
`descripcion`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.0Nov 13, 2026

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the write nature is covered. The description adds genuinely new context by disclosing that the creator is auto-assigned as admin, but omits what is returned (e.g. a project id) and whether creation is idempotent or name-constrained.

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?

Two short sentences with no wasted words, and the primary action is front-loaded before the side effect. It is efficient, though the brevity leaves real informational gaps.

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

Completeness3/5

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

Annotations cover the safety profile and there is no output schema to explain, but for a creation tool the description should say what comes back or what happens on name collisions. The admin-assignment detail helps, yet key invocation-relevant facts are missing.

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 0%, so the description must carry the burden for "nombre" and "descripcion". It mentions neither, leaving constraints such as uniqueness, length, or what an omitted descripcion means entirely undocumented.

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?

"Create a project" states a specific verb and resource, and the second sentence clarifies the side effect. It is clearly a creation tool distinguishable from list/get/update siblings by the verb alone, though it never names an alternative.

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?

There is no explicit when-to-use or when-not-to-use guidance. Nothing says whether duplicate project names are allowed, what permissions are needed, or how this relates to amulen_create_board or amulen_update_project.

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