eduframe-mcp

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

While annotations indicate this is a non-idempotent write operation (idempotentHint: false, readOnlyHint: false), the description adds no context about this behavior, side effects, or what the tool returns upon success (no output schema exists to compensate). It does not explain that calling this twice creates duplicate materials.

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

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

The description is extremely brief (three words) with no redundant text, but it is under-specified rather than appropriately concise. It fails to front-load critical information about return values or behavioral constraints that structured fields do not cover.

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

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

Given the absence of an output schema, the description should explain what is returned (e.g., the created material ID or object), but it omits this. It also fails to clarify domain-specific concepts like the relationship between materials and material groups, leaving significant gaps despite the well-documented parameter schema.

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

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

The input schema has 100% description coverage for its 3 parameters (name, use_type, material_group_id). Since the schema fully documents the parameters, the baseline score applies; the description itself adds no additional semantic context about parameter relationships or enum implications.

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

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

The description 'Create a material' is tautological, merely restating the tool name with an article added. It fails to specify what constitutes a 'material' in this domain (e.g., physical inventory, digital asset) or how it differs from the sibling tool create_material_group.

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

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

No guidance is provided on when to use this tool versus alternatives like update_material or create_material_group. There is no mention of prerequisites (e.g., requiring an existing material_group_id) or workflow integration despite the presence of related CRUD siblings.

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