Skip to main content
Glama
Sign In
Maestro Career Studio

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Attach Evidence

attach_evidence

Attach an evidence image to a proposal from inline base64 or a local file path, and label it as step, final review, or submission receipt evidence.

Instructions

Attach an evidence image to a proposal, from exactly one of image_base64 (the image, base64, supplied inline in the call) or file_path (an image file already on this machine's disk, e.g. a browser tool's saved screenshot; its bytes are read and uploaded server-side, so they never enter the model context). Both or neither is refused, and nothing is uploaded. kind must be step | final_review | submission_receipt.

Input Schema

NameRequiredDescriptionDefault
kindNostep
stepYes
labelYes
file_pathNoAn absolute path to an existing PNG or JPEG on this machine, typically as a browser tool reports it (Playwright MCP saves to its --output-dir; with the standard setup that is under the repo's .playwright-mcp/ tree, e.g. /Users/<user>/Projects/maestro-career-studio/.playwright-mcp/<name>.png); a relative or ~ path is resolved against this server's working directory. When this server runs inside the backend container, a host path with a `.playwright-mcp/` segment is read from the container's mount of that tree (paths that leave the tree are refused). PNG/JPEG only, 5 MB max.
proposal_idYes
image_base64No

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.12.0
    • addedInput schema / properties / file_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An absolute path to an existing PNG or JPEG on this machine, typically as a browser tool reports it (Playwright MCP saves to its --output-dir; with the standard setup that is under the repo's .playwright-mcp/ tree, e.g. /Users/<user>/Projects/maestro-career-studio/.playwright-mcp/<name>.png); a relative or ~ path is resolved against this server's working directory. When this server runs inside the backend container, a host path with a `.playwright-mcp/` segment is read from the container's mount of that tree (paths that leave the tree are refused). PNG/JPEG only, 5 MB max.",
+  "title": "File Path"
+}
    • addedInput schema / properties / image_base64 / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / image_base64 / default
      Added value: +null
    • removedInput schema / properties / image_base64 / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
-  "proposal_id",
-  "step",
-  "label",
-  "image_base64"
-]New value: +[
+  "proposal_id",
+  "step",
+  "label"
+]
  2. First observedv0.11.1

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare the safety profile (not read-only, not destructive, not idempotent), and the description adds real value beyond that: file_path bytes are read and uploaded server-side so they never enter model context, invalid source combinations are refused with nothing uploaded, and file type/size limits appear in schema. It does not describe the response after a successful attach, but with annotations carrying the safety profile a 4 is appropriate.

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?

Three tight sentences with the main action and source constraint front-loaded, and the kind enum placed last. Dense but every sentence carries weight; only slightly more could be trimmed.

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 write tool with an output schema absent, the description covers the critical ambiguities: which source parameter to use, the refusal behavior, and the kind enum. The main remaining gap is that proposal_id, step, and label are undefined despite low schema coverage, but their names are largely self-explanatory 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 only 17%, so the description must compensate. It does a good job on the three hardest parameters (mutual exclusivity of image_base64/file_path, the server-side read semantics of file_path, and the kind enum), but it says nothing about the three required parameters proposal_id, step, and label, leaving their meaning to inference. Partial compensation merits a 3.

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 ('Attach an evidence image to a proposal') and immediately enumerates the two mutually exclusive source parameters, so an agent can tell exactly what this does without opening the schema. It is clearly distinct from siblings like get_rendered_pdf_page_image or render_pdf.

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?

It explicitly states the source contract: exactly one of image_base64 or file_path, with both/neither refused and nothing uploaded. That is strong when-to-use guidance for the ambiguous part of the call, but it never states when to attach evidence versus other siblings or any prerequisite context (e.g., proposal state).

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

Deploy Server

Other Tools