Skip to main content
Glama

Marziale Technologies

by tech.marziale.mcp
OverviewDiscussionsAdmin

Questions and rules

get_questions
Read-only

Get the questions, choices, and rules. Read-only. Call ask_with_picker first. Use this list only if ask_with_picker returns elicitation: false. Ask one question at a time. Show choices word for word as a numbered list. If the person selects Other, ask for a short answer. Keep the person's words.

First, for all:

  • What is your email?

  • What is your name?

  • Which one are you?

    1. Operator: I make decisions inside of a business

    2. Talent: I am talented and would like to talk

Client:

  • What type of business do you have?

    1. Retail or shop

    2. Restaurant or food

    3. Farm, dairy, or food plant

    4. Trades or construction

    5. Health or professional office

    6. Nonprofit or public agency

    7. Other

  • In which town is your business?

  • Which task takes the most time each week?

    1. Scheduling and bookings

    2. Orders and inventory

    3. Billing and payments

    4. Customer calls, texts, and email

    5. Reports and paperwork

    6. Other

  • How many hours a week does that task take?

    1. Under 2

    2. 2 to 5

    3. 5 to 10

    4. 10 to 20

    5. Over 20

  • About how many hours, if you know?

  • Who does that task?

    1. The owner

    2. One staff member

    3. Several staff

    4. An outside service

  • When did this problem start costing you time?

  • Where are you right now?

    1. We do it by hand

    2. We use a tool that falls short

    3. We tried a fix that did not work

    4. Not sure where to start

  • When do you want this fixed?

    1. As soon as possible

    2. Within 3 months

    3. 3 to 6 months

    4. 6 to 12 months

    5. Just looking

  • What is a good result in 90 days?

  • What is the name of your business? (Optional.)

Talent:

  • Where are you right now?

    1. In school

    2. Working full-time

    3. Working part-time

    4. Building my own thing

    5. Between things

  • When could you start?

    1. Already full-time

    2. Within 3 months

    3. 3 to 6 months

    4. 6 to 12 months

    5. Still exploring

  • When did you start building on your own, and why?

  • Give your links: LinkedIn, GitHub, personal site, more links.

  • Give your education: school, degree, field, graduation year. Test scores are optional.

  • Give your experience: title, company, start, end, what you did.

  • Give your projects: name, link, what it is.

  • Give your achievements, each with the year.

  • Give your publications: title, venue, year, link.

  • What's the most impressive thing you've built or done? Be concrete. Numbers beat adjectives. (Max 1200 characters.)

  • Give a link for that, if you have one. (Optional.)

  • Give a link to your resume, if you have one. (Optional.)

Last, for all:

  • Anything else we should know? (Optional. You can skip it.)

Long answers: max 1200 characters each.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint true, and the description's 'Read-only' is consistent with that. Beyond the annotation it discloses real behavioral context: the gating dependency on ask_with_picker's elicitation flag, the ordering constraints, the interaction rules, and the 1200-character cap on long answers. It stops short of explaining what the returned payload looks like, which keeps it at a 4 rather than a 5.

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

Conciseness3/5

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

The purpose and routing rule are front-loaded correctly and the procedural instructions are tight, but the bulk of the description is a verbatim enumeration of the entire questionnaire, choice lists, and question branches. That content is arguably the tool's payload rather than tool documentation, so the description is dominated by material that an output schema would normally carry; it is defensible but far from tight.

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?

For a zero-parameter, read-only tool with no output schema, the description carries the full burden and does supply the branching questions, the answer options, the mandatory/optional markers, and the character limit. It is essentially complete for the agent's task, with only the ambiguity of embedding return content in the description keeping it below a 5.

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

Parameters4/5

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

The tool takes zero parameters (empty object schema), so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level meaning is missing because no parameters exist.

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 opening sentence names a specific verb and resource ('Get the questions, choices, and rules') and immediately distinguishes the tool from its sibling by stating it is the fallback when ask_with_picker returns elicitation: false. An agent can tell exactly what this tool provides and when it is the right one to call without opening any other schema.

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

Usage Guidelines5/5

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

It gives explicit conditional routing against a named alternative ('Call ask_with_picker first. Use this list only if ask_with_picker returns elicitation: false') and then prescribes the interaction protocol: one question at a time, choices shown verbatim as a numbered list, follow-up on 'Other', preserve the person's words. When-to-use, when-not-to-use, and how-to-use are all stated, not inferred.

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

All Marziale Technologies toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources