Skip to main content
Glama

Frasma

by io.github.francemazzi

Prepare process brief handoff

prepare_project_brief
Read-onlyIdempotent

Validates the process brief used for a quote (name, email, process, optional company/role/systems/volume). Does not send email. The user must confirm before POST /api/request-process-assessment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesClient full name.
roleNoClient role, if known.
volumeNoVolumes or frequency, e.g. 80 documents per week.
companyNoClient company name, if known.
processYesProcess to evaluate, at least 20 characters: trigger, work today, and desired outcome.
systemsNoSystems already in use, e.g. Outlook and ERP.
clientEmailYesClient work email.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
briefYes
handoffYes

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds concrete behavioral boundaries beyond those: it does not send email, and it must be followed by a user-confirmed POST. Validation-failure behavior is not described, but the output schema reduces that gap.

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 two short sentences with three clear clauses. It is front-loaded with the core purpose and includes only high-value information: what is validated, the no-email side effect, and the required next step.

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?

Given the output schema, full parameter coverage, and annotations, the description is nearly complete: it identifies the input groups, side-effect boundaries, and next action. Explicitly naming or contrasting with prepare_diagnostic_summary would make it fully complete, but the current content is sufficient for correct invocation.

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%, with each parameter already documented. The description only groups parameters into required and optional sets, adding no new semantic meaning beyond the schema, so the baseline 3 is appropriate.

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?

The description states a specific verb ('validates'), resource ('process brief'), and context ('used for a quote'), and lists the fields involved. It is clear overall, but it does not explicitly differentiate from the sibling tool prepare_diagnostic_summary, so it stops short of 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 Guidelines4/5

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

The description gives clear context: this tool validates before the actual POST, does not send email, and requires user confirmation first. It lacks explicit when-not-to-use guidance or named alternatives, but the workflow placement is unambiguous.

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

All Frasma toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct roles: getters return canonical framework/profile objects, search handles broad knowledge queries, and the two prepare tools validate different payloads. However, get_frasma_profile and search_frasma_knowledge overlap on sectors and commercial boundaries, and both prepare tools produce handoff payloads, so there is a small amount of potential confusion.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern: get_, prepare_, and search_. The verbs accurately describe the action and the nouns clearly identify the object, making the set predictable and easy to navigate.

Tool Count5/5

With exactly five tools, the server is well-scoped for its purpose: retrieving verified knowledge, accessing canonical profiles/frameworks, and preparing validated handoff payloads. Each tool earns its place and there is no sense of bloat or thinness.

Completeness4/5

The set covers the core pre-submission workflow: retrieving verified facts, mapping diagnostics, and validating project briefs. The only notable gap is that no tool actually submits or confirms the POST /api/request-process-assessment; the descriptions deliberately leave that to an external user action.

Resources