Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
PromptStudio is an ASP.NET Core web application that exposes 22 tools via an HTTP API controller. While tool names follow verb-noun patterns reasonably well, significant gaps exist in parameter descriptions, input validation guidance, output schema documentation, and error recovery messaging. Many tools lack descriptions for their input parameters, and output schemas are not explicitly documented. The server lacks structured error handling that guides LLM recovery. This is a functional CRUD API but falls short of production-grade agent tool standards.
Tools (22)
CreateCollectionwrite50/100
Create a new prompt collection
CreatePromptTemplatewrite50/100
Create a new prompt template
CreateVariableCollectionwrite50/100
Create a new variable collection for batch processing
Missing parameter descriptions in nested objects. Tools like ExecutePrompt, CreatePromptTemplate, CreateVariableCollection, and SavePromptExecutions have complex nested input objects (request.variables, request properties, etc.) but lack descriptions for individual nested fields. LLMs cannot infer what 'variables' dictionary should contain or how 'csvData' should be formatted.
No output schema documentation visible in tool definitions. While the API controller code shows response structures being built (e.g., GetCollection returns nested Prompts and Variables), these response schemas are not formally documented in the tool definitions. LLMs have no guarantees about what fields will be returned or their types.
Add explicit output schemas to every tool definition. Document the fields, types, and meanings of all response objects. For example, GetCollection should document that it returns {id, name, description, createdAt, updatedAt, Prompts: [{id, name, description, ...}]}.
Include WHEN the tool is useful and what distinguishes it from similar tools. Example for ExecutePrompt: 'Execute a prompt template by substituting variables, returning the resolved prompt. Use when you need to generate a final prompt for an LLM. Does not call an external LLM; that step is separate.'
Document all parameter constraints inline in parameter descriptions. For 'limit' in GetExecutionHistory: '(integer, default 50, min 1, max 1000)'. For 'content' in CreatePromptTemplate: '(string, max 10000 chars, supports {{variable}} syntax)'.
Add descriptions to every nested object property. For ExecutePrompt's 'request.variables' parameter, document: '(object: dictionary of {[variableName: string]: value}. Variable names must match {{name}} placeholders in the prompt template.)'.
Implement and document pagination for list tools. Add 'page' (integer, default 1) and 'pageSize' (integer, default 20, max 100) parameters to GetCollections, GetPromptTemplates, GetExecutionHistory, and GetVariableCollections. Document that responses include 'totalCount' and 'hasNextPage'.
Add structured error responses with recovery guidance. Example: 'Collection with ID 999 not found. Available collections: [list]. Try GetCollections() to discover valid IDs.' Categorize errors as retryable (timeout, service unavailable) or user-fixable (not found, invalid input).
Score history
Overall score trend
↑ 41 points across a rubric change (v1 → v2)
41/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
41
2026-07-28+
v2
2026-03-09
F
0
-
v1
GenerateVariableCsvTemplateread only50/100
Generate a CSV template for variable collections
GetCollectionread only50/100
Get a specific collection with its prompts
GetCollectionsread only50/100
Get all collections
GetExecutionHistoryread only50/100
Get execution history, optionally filtered by prompt template
GetPromptTemplateread only50/100
Get a specific prompt template
GetPromptTemplatesread only50/100
Get all prompt templates, optionally filtered by collection
GetVariableCollectionsread only50/100
Get variable collections for a prompt template
ImportCollectionwrite50/100
Import a collection from JSON file
ParseVariableCsvread only50/100
Parse CSV data into variable sets
ResolvePromptread only50/100
Resolve a prompt template with variable substitution
Destructive operations lack confirmation or dry-run capability. DeleteCollection and DeletePromptTemplate are high-risk operations (they delete 'a collection and all its contents' and a 'prompt template' respectively) but have no warning, confirmation step, or recovery mechanism documented. An LLM could accidentally delete data without a safety gate.
Generic error handling without recovery guidance. The API controller returns generic errors like 'Error retrieving collections: {ex.Message}' or 500 StatusCodes without explaining what the LLM should do next. No guidance on whether errors are retryable, user-fixable, or fatal.
Parameter constraints not documented. Numeric parameters like 'limit' in GetExecutionHistory (default 50) lack stated min/max bounds. String parameters like 'name', 'content', and 'csvData' lack length limits, format patterns, or encoding hints. LLMs may pass invalid values.
Tool descriptions lack actionable context. Most descriptions are 30-60 characters and state only WHAT the tool does (e.g., 'Get all collections'). They do not explain WHEN to use the tool, what distinguishes it from similar tools, or what prerequisites exist. For example, ExecutePrompt says 'Execute a prompt template with provided variables' but does not explain what the execution returns or whether it calls an LLM.
No pagination or result-limiting strategy visible. GetCollections, GetPromptTemplates, and GetExecutionHistory do not declare pagination parameters or caps. If hundreds or thousands of records exist, an unbounded list call could exhaust the context window and degrade LLM reasoning.
Idempotency not documented. Tools like CreatePromptTemplate, CreateCollection, and CreateVariableCollection do not state whether repeated calls with the same input return the same result or create duplicates. This affects agent retry behavior, a retried call might create an unintended duplicate record.
No explicit scope or permission declarations. Tools do not declare what permissions or scopes they require (e.g., 'read:prompts', 'write:collections', 'delete:templates'). This prevents least-privilege agent configuration and complicates audit trails.
Implement a confirmation flow for destructive tools. Before DeleteCollection or DeletePromptTemplate, require an explicit 'confirm: true' parameter and document: 'This operation is irreversible. Pass confirm=true to proceed.'
Document idempotency for create and import tools. State: 'This operation is idempotent: calling it twice with the same input returns the same result without creating duplicates.' (if true) or 'This operation is NOT idempotent: repeated calls create duplicate records. Ensure the agent deduplicates.' (if not).
Add permission/scope declarations to each tool. Example: 'Requires scope: read:collections.' Use a consistent format so agents can be configured with minimal necessary permissions.
For CSV-related tools (CreateVariableCollection, ParseVariableCsv, GenerateVariableCsvTemplate), document the exact CSV format, expected headers, and encoding. Example: 'CSV must have headers matching variable names from ExtractVariableNames(). One variable set per row. Use UTF-8 encoding.'
Consider wrapping related multi-step operations into single tools. For example, ExecutePrompt + SavePromptExecutions could combine into ExecuteAndLogPrompt to reduce round-trips and ensure data consistency.