Sourced, citable definitions of prompting and LLM techniques, with relations and primary sources.
Scored across 4 tools
Each tool has a distinct primary action: search, retrieve full entry, retrieve relationships, or list categories. There is minor overlap between search_terms and list_categories as discovery paths, but descriptions make the intended use clear.
All names use snake_case and a verb-first pattern, which is predictable. get_related deviates slightly from the verb_noun pattern because 'related' is an adjective rather than a noun, but the set remains highly readable.
Four tools are well-scoped for a read-only technique reference. Search, retrieval, relationship exploration, and category browsing each earn their place without redundancy.
The surface covers the key read-only workflows: keyword search, full entry retrieval, taxonomy browsing, and relationship exploration. No obvious gaps or dead ends for an encyclopedia-style knowledge base.
Get the full Protologue entry for one technique: definition, description, synonyms, introduction year, primary sources, canonical URL, permanent identifier and a ready-made citation. Accepts a name, synonym, slug (e.g. 'react') or identifier (e.g. 'PTL-0058').
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Technique name, synonym, slug or PTL identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds the useful detail of what the response contains, but says nothing about failure behavior (e.g. unknown synonym/identifier) or lookup resolution order among the four accepted forms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-formed sentences, front-loaded with the return payload and then the accepted inputs. The field list is long but each item is load-bearing; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates the returned fields, and the single parameter is fully covered, so an agent has what it needs to call the tool. The main omission is error/not-found behavior for a lookup that accepts four different input shapes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already lists the accepted forms (name, synonym, slug, PTL identifier); the description largely repeats this. The two concrete examples ('react', 'PTL-0058') add a little formatting guidance, but nothing beyond the schema's own enumeration. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get the full Protologue entry for one technique') and enumerates the returned content, so the agent knows exactly what it retrieves. It does not name or contrast itself with the obvious sibling search_terms, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'one technique' framing and the accepted identifier forms imply usage (retrieve a single known term), but there is no explicit 'use this when...' or a pointer to search_terms for discovery. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Protologue's branches (categories) and the techniques in each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds useful context about the shape of the result (categories with their techniques nested underneath), which matters since there is no output schema, but it says nothing about ordering, pagination, or size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource with zero filler. Every clause earns its place by naming both the parent list and the nested content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool whose annotations already convey the safety profile, the description covers what is returned and is sufficient to call it. The absence of any hint about result size or ordering is a minor gap given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering arguments are needed and does not mislead about any inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("List") and resource ("Protologue's branches (categories) and the techniques in each"), and clarifies the domain-specific term "branches" with the generic "categories". It does not explicitly contrast with siblings like get_term or search_terms, but the verb/resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 tool versus the sibling lookup tools (get_term, get_related, search_terms). An agent must infer that this is the enumeration tool and the others are targeted lookups, with no explicit guidance or exclusions offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Protologue for prompting and LLM techniques by name, synonym or keyword. Returns matching entries with their one-sentence definitions and canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results. | |
| query | Yes | Technique name, synonym or keyword, e.g. 'chain of thought' or 'RAG'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the return shape (one-sentence definitions and canonical URLs), though it says nothing about result ordering, matching strictness, or truncation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the verb and resource, with the return format appended efficiently. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema search tool, the description covers purpose, matching modes, and return content, while annotations cover safety. Only minor gaps remain (relevance ordering, behavior on zero matches).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both query and limit are already documented in the schema, including the example values. The description's 'name, synonym or keyword' phrasing merely echoes the query parameter's schema description and adds no new constraint or format detail; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (Protologue prompting/LLM techniques), plus the matching modes (name, synonym, keyword) and what comes back. It does not explicitly name or distinguish itself from siblings like get_term, but the search-vs-retrieve split is inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'search by name, synonym or keyword' suggests this is for discovery when the exact term is unknown, with get_term presumably for exact lookup. No explicit when-to-use, when-not, or named alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_relatedget_termlist_categoriessearch_termsSource-backed prompting and coding-agent guidance with provenance and freshness checks.
Sourced register of open-weight AI model releases and AI news. Every field cites its source.
Your prompt library inside your AI: 1,000+ pro templates, frameworks, vocab & pipelines.
Research-backed lint + generation for agent context files (CLAUDE.md, AGENTS.md) + prompt enhancer.
Add one secure layer between your agents and this server.
