Loading ToolBench
This server provides two well-defined tools with clear purpose and structured schemas. Both tools have descriptions that clearly state what they do and when to use them. Input schemas are present and mostly complete with proper types and descriptions. However, there are gaps in output schema documentation and parameter descriptions lack some actionable detail (format constraints, examples of valid values). Error handling is basic, errors return a generic message without recovery guidance. The server follows good naming conventions (verb_noun) and avoids the 'and' anti-pattern. No security issues detected (read-only operations, no credential parameters). Composition is appropriate, two specialized tools with clear separation of concerns.
Fetches the content of a Powertools documentation page and returns it as markdown.Use this after finding relevant pages with search_docs to get detailed information.
Search Powertools for AWS Lambda documentation to learn about Serverless best practices. Try searching for features like 'Logger', 'Tracer', 'Metrics', 'Idempotency', 'batchProcessor', event handler, etc. Powertools is available for the following runtimes: python, typescript, java, dotnet. When searching, always specify the version of Powertools you are interested in, if unsure, try to read it from the workspace configuration, otherwise use "latest".
Output schema not documented for either tool. search_docs returns an array of {title, url, score} but this is not formally documented in the tool schema. fetch_doc_page returns markdown content but the output structure is not declared. LLMs cannot plan downstream actions without knowing what fields to expect.
Error messages lack recovery guidance. When search index fetch fails, the tool returns 'Failed to fetch search index for {runtime} {version}: {error}' without suggesting next steps. Per pattern:recovery-guide, errors should guide the agent toward resolution.
Parameter descriptions lack actionable format constraints. The 'version' parameter description says 'version is always semantic 3 digit in the form x.y.z' but does not show a pattern constraint or regex in the schema. The 'url' parameter says 'Must be from docs.aws.amazon.com/powertools domain' but there is no URL validation visible in the input schema. LLMs cannot enforce these constraints without explicit schema validation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
search_docs description includes example values ('Logger', 'Tracer', 'Metrics', 'Idempotency', 'batchProcessor'). Per pattern:tool-description guidelines, example values in descriptions can cause LLMs to reuse them literally rather than adapting to context. Move examples to parameter constraints or separate documentation.
No pagination support for search_docs results. If a search returns many results, there is no mechanism to fetch additional results or limit the response. Large result sets can exhaust context windows. The tool should return a total count and support offset/limit or cursor-based pagination.