Skip to main content
Glama
Sign In
Pedra MCP Server

Pedra MCP Server

Official
by pedra-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Generate voiceover script

pedra_generate_voice_script

Write a voiceover script from property photos so narration matches what the images show; returns text ready for voice generation.

Instructions

Write a short voiceover script from property photos (and optional facts). GPT-4o vision reads the images so the script reflects what's actually shown. Returns the script text — pass it to pedra_generate_voice.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "pedra_generate_voice_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
imagesNoPhotos to base the script on (URLs or { imageUrl }).
languageNoScript language, e.g. "English", "Español". Defaults to English.
propertyCharacteristicsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • changedInput schema / properties / images / items / anyOf
      Previous value: -[
-  {
-    "description": "Source image: a public https:// URL, a data: URI, or an absolute path to a local image file (the file is read and inlined automatically).",
-    "type": "string"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "imageUrl": {
-        "$ref": "#/properties/images/items/anyOf/0"
-      }
-    },
-    "required": [
-      "imageUrl"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "description": "Source image: a public https:// URL, a data: URI, or an absolute path to a local image file on this computer (the file is read and inlined automatically). If the photo is on the user's device and can't be read from here (e.g. it's on their phone), get a link from pedra_create_upload_link.",
+    "type": "string"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "imageUrl": {
+        "$ref": "#/properties/images/items/anyOf/0"
+      }
+    },
+    "required": [
+      "imageUrl"
+    ],
+    "type": "object"
+  }
+]
  2. Addedv0.3.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the bar for safety disclosure is partially met, but the description adds genuinely useful behavior: GPT-4o vision actually reads the images, and the return value is raw script text meant to be chained into pedra_generate_voice. It omits cost/credit implications, which matters for a paid-generation sibling set.

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?

Three short sentences, no filler, with the core action and its downstream handoff front-loaded. Every sentence carries information an agent needs.

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?

There is no output schema, but the description compensates by stating the return value ('Returns the script text') and its consumer. The remaining gap is operational context such as credit cost and whether images are effectively required despite zero required parameters.

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 coverage is 67%, so the schema already documents the image source formats, language default, and the propertyCharacteristics label/value pair. The description only adds that facts are optional, which is marginal over the schema's own text.

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?

States a specific verb and resource ('Write a short voiceover script from property photos') and immediately distinguishes itself from the sibling pedra_generate_voice by naming it as the downstream consumer. An agent can tell what this produces versus what the voice tool produces without opening either schema.

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 gives clear context for use (photos + optional facts) and explicitly routes the result to pedra_generate_voice, which is a strong 'when to use' signal. It stops short of saying when NOT to use it or what alternative to pick if no photos exist.

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