get_blog_postGet the full markdown content of a blog post by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The URL slug of the blog post |
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| slug | No | ||
| tags | No | ||
| title | No | ||
| author | No | ||
| content | No | Full article body. Quote and summarize freely; do not republish wholesale. | |
| summary | No | ||
| attribution | Yes | ||
| publishedAt | No | ||
| readingTimeMinutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a read-only, idempotent, non-destructive operation. The description adds that the content is full markdown, but does not discuss behavior for missing slugs or other edge cases; the output schema presumably covers return shape.
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 contains the action, resource, and key parameter with no filler. Every word earns its place.
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 one-parameter lookup with an output schema, strong read-only annotations, and obvious differentiation from list/search siblings, this description is sufficient. No critical information needed to invoke the tool correctly is missing.
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?
Input schema coverage is 100%, with the slug parameter already described as 'The URL slug of the blog post'. The description simply restates 'by its slug' and adds no format, validation, or usage detail beyond the schema.
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 states the specific verb 'Get', the resource 'full markdown content of a blog post', and the required identifier 'slug'. This clearly distinguishes it from sibling tools like list_blog_posts and search_content.
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 clearly implies when to use the tool: when you need a blog post's full content and know its slug. It does not explicitly name alternatives or exclusion conditions, but the intended use is strongly evident.
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.
Several permit-related tools have overlapping boundaries: answer_permit_question, check_permit_requirements, and get_permit_rule_details all return timeline/fee/submittal information and can answer 'do I need a permit' style questions. get_material_catalog and get_material_options also target similar material-selection needs. The descriptions help, but an agent could easily select the wrong tool in the permit cluster.
All 36 tools follow a consistent snake_case verb_noun pattern, with get_ for single-item lookups and list_ for collection queries. There are no camelCase or mixed-style exceptions, so the naming is predictable and scannable.
36 tools is well above the 25+ threshold and feels heavy even for a multi-domain construction assistant. Several retrieval tools overlap (list_services/list_projects/list_blog_posts vs search_content, get_material_catalog vs get_material_options), suggesting consolidation opportunities.
The permit workflow is well covered from parcel lookup through requirements, fees, submittals, and data freshness, and the prospect journey has services, estimates, financing, weather, reviews, and contact submission. Minor gaps exist, such as no active permit-status lookup and no way to create/update content, but these are outside the apparent read-only/lead-gen scope.