Skip to main content
Glama
Wagner-Emden-IT-Services

placetel-web-api-mcp-server

Fetch all prompts

placetel_list_prompts
Read-onlyIdempotent

Retrieve all Placetel prompts with optional pagination and name or description filters. Use it to browse available prompts and return results as readable Markdown or JSON.

Instructions

Fetch all prompts. (GET /prompts) Read-only.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number, starting at 1.
per_pageNoItems per page (max 100). Not honored by every endpoint.
filter_nameNoQuery filter[name].
response_formatNoOutput format: 'markdown' (human-readable, default) or 'json' (machine-readable).markdown
filter_descriptionNoQuery filter[description].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true, so 'Read-only' merely restates structured data. The only added value is the HTTP route mapping; nothing is said about pagination behavior, filter semantics, or what the response contains.

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 short fragments with the core purpose front-loaded and no filler. It is terse rather than verbose, though the brevity borders on under-specification rather than sharply earned concision.

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

Completeness3/5

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

With a fully documented schema and rich annotations, the definition is functional: an agent can call it correctly. However, for a paginated filtered list endpoint nothing tells the agent about default page size, total counts, or when to prefer json output, leaving gaps the schema cannot fill.

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%, so all five parameters (page, per_page, filter_name, filter_description, response_format) are already documented, establishing a baseline of 3. The description adds no meaning beyond the schema, such as filter matching behavior or how pagination interacts with the filters.

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?

"Fetch all prompts" gives a clear verb and resource, and the GET /prompts route confirms it is a collection read. Combined with the name placetel_list_prompts it is distinguishable from placetel_get_prompt/create_prompt, though the description never explicitly says 'list, not single-record fetch'.

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

Usage Guidelines2/5

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

There is no statement of when to use this versus placetel_get_prompt or placetel_list_prompts alternatives, nor any prerequisites or filter guidance. Usage is only inferable from 'all prompts'.

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