Loading ToolBench

Reading the current corpus…

TINS-MCP MCP server · F · ToolBench

← Browse

TINS-MCP

github.com/ScuffedEpoch/TINS-MCP

There Is No Software - MCP server for generating applications from README files

2026-07-28+STDIO2 tools

46/100

Definition Quality52

Protocol Readiness50

Supportability33

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

TINS-MCP has 2 tools with basic schemas and descriptions, but significant gaps prevent production use. Both tools have descriptions (good), but parameter descriptions are minimal or missing. The generate_from_readme tool lacks descriptions for 3 of 4 parameters (output_dir, output_type, preferred_language). The validate_readme tool has only 1 parameter with a description. No output schemas are documented. Error handling is absent, no guidance on what happens on failure or how to recover. Tool names follow verb_noun convention (positive), but descriptions lack actionable context about when to use each tool or what they return.

Tools (2)

generate_from_readmewritesource verified53/100

Generate application code from a README.md file following the Zero Source specification

validate_readmeread onlysource verified50/100

Validate a README.md file against the Zero Source specification

Issues (5)

CRITICALtool-description ↗

Missing parameter descriptions: generate_from_readme lacks descriptions for output_dir, output_type, and preferred_language. validate_readme lacks description for readme_path. LLMs cannot infer parameter meaning from names alone.

generate_from_readmevalidate_readme

CRITICALtool ↗

No output schemas documented. LLMs cannot plan downstream calls or extract required data without knowing what fields are returned. Both tools lack return type documentation.

generate_from_readmevalidate_readme

HIGHrecovery-guide ↗

No error handling guidance. Tool descriptions do not explain what happens on failure (e.g., invalid README path, generation failure). No recovery hints provided to LLM.

generate_from_readmevalidate_readme

HIGHtool-description ↗

Tool descriptions lack context about when to use each tool and what they return. 'Generate application code from a README.md file' does not explain prerequisites, expected output format, or when validate_readme should be called first.

Recommendations

Add descriptions to all parameters. For output_dir: 'Directory where generated code will be written. If not specified, defaults to ./generated_app'. For output_type: 'Output format: files (individual files in directory) or zip (single archive). Defaults to files'. For preferred_language: 'Programming language for generated code. Defaults to javascript if not specified'.
Document output schemas for both tools. generate_from_readme should return {files: [{path, content, language}], outputPath, appType, mainFile, commandToRun}. validate_readme should return {isValid: boolean, errors: [{line, message}], warnings: []}.
Add error handling guidance to descriptions. E.g., 'If README is invalid or path does not exist, returns error with specific validation failures. Call validate_readme first to check syntax.'
Expand tool descriptions with context. Add 'Call validate_readme first to ensure README follows Zero Source spec before generating code' to generate_from_readme. Explain that validate_readme is a discovery/validation tool.
Migrate from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote access and hosted client compatibility.

Score history

Overall score trend

First recorded score · v2 rubric

46/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	F	46	2026-07-28+	v2