Skip to main content
Glama

Picodev Lab

by io.github.PICODEV-SAS
OverviewDiscussionsAdmin

Send the spec to Picodev

brief_submit

Send Picodev the specification of the visitor's project, as a PDF, or only return its preview (send=false). sections: {id: text in simple Markdown}, ids envelope, fonctionPrincipale, fonctions, alimentation, format, environnement, production, preferences (the 8 sections of a product specification), 4000 characters at most each; a missing section reads "À préciser" (to be specified). send=false: preview, nothing is sent, contact and consent are not required. send=true: requires contact {name, email, company?, phone?} and consent=true. nda=true: the visitor wants a non-disclosure agreement first; without sections, only contact and title are sent, without PDF. session and agent_token, optional: the mail also says what the visitor did in the lab. language: fr or en, the PDF's headings. sections.contact and figures: as for spec_draft (refused with nda=true, as sections). Write the sections with spec_draft first. Before passing consent=true, show the visitor the consent text in the visitor's language, and wait until they accept it. In French: "J'accepte que mes coordonnées et la description de mon projet soient envoyées à Picodev par courriel, pour qu'ils me répondent. Picodev les garde 3 ans après le dernier échange et ne les utilise pour rien d'autre. Détails : lab.picodev.fr/confidentialite" In English: "I agree that my contact details and the description of my project are sent to Picodev by e-mail, so that they can answer me. Picodev keeps them for 3 years after our last exchange and uses them for nothing else. Details: lab.picodev.fr/en/privacy" Returns {sent, filename, pdf (base 64, absent with nda), missing (empty or too short sections), next (a sentence for the visitor, to say in their language)}}: write the PDF on the visitor's machine.

Input Schema

NameRequiredDescriptionDefault
ndaNo
sendNo
titleYes
consentNo
contactNo
figuresNo
sessionNo
languageNofr
sectionsNo
agent_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses important side effects beyond the annotations: send=true emails Picodev, send=false sends nothing, nda=true suppresses the PDF, and the PDF is written on the visitor’s machine. It also explains consent requirements, privacy retention, and the exact consent text to show, which is valuable behavioral context not covered by the annotations.

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?

The key action and send/preview distinction are front-loaded, and most of the dense detail is necessary for this complex tool. The description is long and heavily semicolon-driven, but the consent text and conditional rules earn their place.

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

Completeness5/5

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

For a 10-parameter tool with no output schema, the description provides the return shape, conditional behavior for nda and preview, consent prerequisites, section constraints, and PDF-writing side effects. It is complete enough for an agent to invoke the tool safely and correctly.

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?

With 0% schema description coverage across 10 parameters, the description compensates substantially: it explains sections, send, consent, contact fields, nda, session, agent_token, language, and the figures relationship to spec_draft. It still leaves some details implicit, such as the full Figure object shape and the role of title, so it is strong but not exhaustive.

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 gives a specific verb and resource: sending the visitor’s project specification to Picodev as a PDF, or returning a preview when send=false. It also distinguishes this tool from the sibling spec_draft by instructing the agent to write sections with spec_draft first.

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 explicitly states when to use preview versus send, the prerequisites for send=true (contact and consent), how nda=true changes behavior, and the required consent confirmation workflow. It names spec_draft as the prerequisite drafting tool, giving the agent clear routing guidance.

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

All Picodev Lab 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