articles_by_categoryFind source-backed articles in an art, illustration, buying-guide, or creative-career category by category name or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, not destructive), so the description only needs to add behavioral context. It adds 'source-backed' filtering and the name-or-slug input mode, but doesn't describe result shape, pagination, or default limit behavior. No contradiction with annotations.
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 front-loaded sentence that states the verb, resource, scope, and input form with no filler. Every word contributes meaning.
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 simple read-only tool, the description together with annotations and schema covers the essential behavior. It could mention the default limit or returned fields, but those gaps are minor for a category lookup tool.
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 0%, so the description must compensate. It does for the required category parameter by explaining that it accepts a name or slug and listing example categories. The optional limit is largely self-explanatory given schema bounds, though the default limit is not stated.
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?
The description uses a specific verb ('Find') with a clear resource ('source-backed articles') and explicit scoping by named categories. It distinguishes itself from siblings like get_article (single article) and search_articles (free-text search) by focusing on category name/slug lookup.
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 description implies this is for category-based research, but it never states when to use this tool over search_articles, get_article, or latest_articles. No exclusions or alternative routing are provided, leaving the agent to infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: category browsing, article detail retrieval, latest article listing, search, and commission quote preparation. Even among the article tools, the retrieval modes are distinct enough that an agent would not easily confuse them.
Most tool names follow a readable pattern with 'articles' as a common noun and verbs like get, search, and prepare. Names like latest_articles and articles_by_category break the strict verb_noun convention, but the overall pattern remains predictable.
Five tools is a well-scoped size for a server that combines article research with commission quote preparation. Each tool covers a distinct need and none feel redundant or unnecessary.
Article discovery is well covered with search, category, latest, and detail retrieval, and the quote tool handles validation and endpoint preparation. Minor gaps exist, such as no explicit category listing endpoint and no follow-up execution/payment tool, but agents can work around these.