Access Zain Ahmed’s public engineering profile, project case studies, technical articles, and platform engineering resources through MCP tools and structured resources. Hosted Streamable HTTP endpoint at zainahmed.net; public retrieval requires no API key.
Scored across 13 tools
Most tools are clearly separated by resource+action: list vs. get-by-slug for articles and projects, plus distinct calculator, manifest generator, search, and contact tools. There is mild overlap in the identity cluster (get_profile, get_about, get_skills, get_certifications all return facets of the same person), and get_services is ambiguous (reads like a catalog but actually reports no offerings), but descriptions largely resolve this.
Every name follows a clean verb_noun snake_case pattern (get_*, search_knowledge_base, calculate_finops_roi, generate_architecture_manifest, submit_contact). The list/get-by-slug pairing (get_articles/get_article_by_slug, get_projects/get_project_by_slug) is predictable and idiomatic.
13 tools sits comfortably in the well-scoped range, with each tool mapping to a recognizable capability (identity, content, search, cost modeling, IaC generation, contact). No obvious padding or thin coverage.
The content surface has solid read coverage (list + get-by-slug for articles and projects, global search) plus utility tools, so an agent can traverse the domain without dead ends. Minor gaps: get_services is effectively a no-op that returns no offerings, and there is no write/admin path or filtering (e.g., by tag/certification) beyond full-text search.
Calculate estimated cloud cost savings and ROI from Karpenter container bin-packing, spot orchestration, and Graviton migration.
| Name | Required | Description | Default |
|---|---|---|---|
| cloudProvider | No | Cloud provider (AWS, GCP, Azure, OCI) | |
| monthlyCloudSpend | Yes | Current monthly cloud spend in USD |
| Name | Required | Description |
|---|---|---|
| estimatedAnnualSavings | Yes | |
| estimatedMonthlySavings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds that the output is an estimate driven by three specific optimization levers, but does not disclose that these levers are AWS-native (Karpenter/Graviton) while the tool accepts GCP, Azure and OCI, nor does it discuss assumption sensitivity or result volatility.
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 naming the verb, the deliverable, and the modeled levers. No filler, no restatement of the tool name, and nothing that can be trimmed without losing information.
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?
An output schema exists, so return values need not be described, and annotations cover the read-only safety profile. What remains missing is the modeling caveat implied by the mismatch between AWS-only levers (Karpenter, Graviton) and the multi-cloud enum in cloudProvider, plus any statement of what the estimate assumes about inputs. Adequate but with a visible gap.
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%, so both parameters (cloudProvider and monthlyCloudSpend, with bounds 0–1e9) are already fully documented in the schema. The description adds no extra parameter meaning – it never explains what 'cloudProvider' changes in the calculation or why it matters alongside the AWS-centric levers. Baseline 3 applies when the schema does the heavy lifting.
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 pairs a specific verb ('Calculate') with a specific output ('estimated cloud cost savings and ROI') and names the exact cost levers modeled: Karpenter bin-packing, spot orchestration, Graviton migration. An agent can tell immediately this is a savings/ROI estimator, and no sibling tool comes close to overlapping that purpose.
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 implied by the purpose – you call it to estimate savings from the named optimizations – but there is no explicit when-to-use, prerequisite, or when-not statement. Since it is the only cost-modeling tool among a set of portfolio/blog/knowledge-base siblings, the implied context is adequate, though nothing scopes it further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate production-ready Kubernetes YAML or Terraform infrastructure manifests based on target workload requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| manifestType | Yes | Type of manifest to generate |
| Name | Required | Description |
|---|---|---|
| content | Yes | |
| filename | Yes | |
| manifestType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that outputs are 'production-ready' and may be Kubernetes YAML or Terraform manifests, but it also implies a dependency on 'target workload requirements' that has no corresponding input parameter, creating mild ambiguity about how the tool actually operates.
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?
The description is a single front-loaded sentence with no wasted words. The trailing clause 'based on target workload requirements' is concise but slightly misleading because no such parameter exists, keeping it from a perfect score.
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?
The tool is low-complexity (one required enum parameter), and an output schema exists, so return values need not be described. The description still leaves an important gap: it claims generation is based on 'target workload requirements,' but the schema exposes only a manifest type, so an agent may misunderstand what inputs are needed.
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% and the single required parameter is fully described with an enum in the schema. The description adds no further parameter semantics, so the baseline 3 for high schema coverage is appropriate; however, it does not clarify that manifestType is the sole input.
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 ('Generate') and resource ('Kubernetes YAML or Terraform infrastructure manifests'), making the tool's core purpose immediately clear. It does not differentiate from siblings, but no sibling tools offer similar manifest generation, so the purpose is unambiguous for an agent.
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 provides no when-to-use guidance, prerequisites, or exclusions. It only states what the tool does, leaving the agent to infer context from the purpose alone; there are no explicit conditions for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the complete About story, personal philosophy ('AI makes me faster. The judgment is mine.'), letter from Zain, and operational tenets.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Filter about section: all, philosophy, principles, story |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe read-only, non-destructive operation. The description adds a content inventory, which is useful context, but it does not explain filtering behavior, default section handling, or response shape; the existing output schema reduces the need for return-value detail.
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?
The definition is a single front-loaded sentence with the verb first. The embedded philosophy quote is mild ornamentation but does not materially harm clarity.
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 content retrieval tool with an output schema and a fully documented enum parameter, the description gives enough content detail for an agent to know what will be returned. The only minor gap is not mentioning the section filter, which the schema already documents.
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 single optional 'section' parameter has full enum documentation in the schema with 100% coverage. The description does not mention the parameter or add semantics beyond the schema, so the baseline of 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, 'Retrieve,' and enumerates the exact content returned: the About story, personal philosophy, letter from Zain, and operational tenets. The resource is clear and distinct from data-oriented siblings, though it does not explicitly contrast itself with get_profile.
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 explicit when-to-use guidance, no mention of alternatives such as get_profile, and no explanation of when to request 'all' versus a specific section. Usage is only implied by the retrieval wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full markdown publication content, metadata, reading time, and checkpoints for a specific technical article by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The unique slug of the article (e.g. 'moving-beyond-ai-code-editor-antigravity-2-0', 'soc2-continuous-compliance-blueprint') |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| title | Yes | |
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that content includes markdown, metadata, reading time, and checkpoints, but is silent on failure behavior for a bad slug and on how much content is returned per call. Given the annotations carry the safety profile, this is adequate but thin.
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?
One sentence, front-loaded with the verb and resource, with no redundant or filler clauses. Every phrase adds distinguishing 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 one-parameter read tool with full schema coverage, rich annotations, and an output schema defining return values, the description covers purpose and output scope adequately. Only the not-found/error case and its relationship to the list sibling are unaddressed.
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 the single slug parameter is documented with concrete examples in the schema itself. The description only adds 'by slug', contributing no syntax, formatting, or example beyond what the schema already provides, so the baseline of 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 (Retrieve) and resource (technical article) scoped by a named key (slug), and enumerates what is returned. This clearly separates it from the list-style sibling get_articles and mirrors the get_project_by_slug pattern without ambiguity.
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 'by slug' framing implies this is the single-item fetch versus the get_articles listing, but the description never states when to prefer it over get_articles or search_knowledge_base, nor what happens for an unknown slug. Usage is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query published architectural blueprints, SOC 2 Type II compliance guides, and Kubernetes SRE articles with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag filter (e.g. Kubernetes, SRE, FinOps, SOC 2, Multi-Cloud, Antigravity) | |
| limit | No | Max number of articles to return (default: 10) | |
| offset | No | Offset for pagination (default: 0) | |
| category | No | Article category filter |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint/destructiveHint annotations already establish the safe-read profile, so the bar is lower. The description contributes the 'published' qualifier (drafts likely excluded) and the fact that results are paginated, but omits anything about ordering, rate limits, or what happens beyond limit=50.
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?
One front-loaded sentence with no filler sentences. The enumerated content types (SOC 2 guides, Kubernetes SRE articles) lean toward marketing copy rather than selection-relevant detail, but the sentence remains tight.
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?
An output schema exists and annotations cover the safety profile, so return values and read/write behavior need no elaboration. The remaining gap is that the description never mentions tag/category filtering as a capability, but for a low-complexity read tool the definition is essentially complete.
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%, so tag, limit, offset, and category are fully documented in the schema itself; baseline 3 applies. The description adds no filter syntax or default-value detail beyond what the schema already provides.
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 clear verb ('Query') plus the resource (articles) and scopes it to published content across named domains (blueprints, SOC 2 guides, Kubernetes SRE). An agent can distinguish it from the singular get_article_by_slug by the plural collection scope, though it never explicitly names that sibling.
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 says nothing about when to use this collection endpoint versus get_article_by_slug or search_knowledge_base, two obvious alternatives in the sibling list. Pagination is mentioned but framed as a feature, not as guidance for choosing this tool over a search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all 5x active multi-cloud certifications with issuing institutions, Credly verification URLs, and credential IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Filter certifications by cloud provider: all, AWS, Azure, GCP, OCI, HashiCorp |
| Name | Required | Description |
|---|---|---|
| certifications | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds which credential fields come back (issuing institutions, Credly URLs, credential IDs), but says nothing about ordering, whether the provider filter defaults to 'all', or how many records come back. Some added value, not rich.
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?
One front-loaded sentence with no filler — the verb and resource lead. The only cost is the ambiguous '5x' qualifier, which spends words without resolving anything.
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?
It's a simple read-only getter with one optional enum parameter, an output schema, and read-only annotations, so the burden on the description is light. What's missing is minor: the meaning of '5x' and the filter's default behavior. Return values are already covered by the output schema.
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% and the single enum parameter is fully documented in the schema, so the baseline of 3 applies. The description never mentions the provider filter at all, so it contributes no meaning 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?
States a specific verb (Retrieve) and resource (certifications), plus the scope of the data returned. It's clearly distinguishable from siblings like get_projects or get_skills. The odd token "5x" adds ambiguity rather than clarity, 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?
Usage is implied by the verb 'Retrieve' — the agent can infer this is the lookup for certification data. However, there is no explicit when-to-use guidance, no mention of when a filtered call is preferable, and no alternatives named among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve Zain Ahmed's verified professional profile, 5x multi-cloud credentials (AWS, Azure, GCP, OCI, HashiCorp), location, philosophy, and competencies.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Filter section: all, bio, credentials, certifications, principles, contacts |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds only a content inventory, not behavioral traits such as how the section filter changes the response or whether 'verified' implies anything operationally.
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 with the verb and resource leading. The promotional enumeration ('5x multi-cloud credentials') is slightly wasteful but does convey real scope, so it is not severe bloat.
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?
Complexity is low, an output schema exists, and annotations cover safety, so the core call is covered. The missing piece is routing among the overlapping sibling tools, which the description does nothing to resolve.
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% and the single 'section' parameter is a fully enumerated field already documented in the schema. The description does not mention the parameter or its filter semantics, so it adds nothing beyond the structured field; 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 (Retrieve) and resource (Zain Ahmed's professional profile) and enumerates the content types it returns. However, it never distinguishes itself from near-duplicate siblings get_about, get_certifications, or get_skills, which appear to overlap with the bio/credentials/certifications sections it advertises.
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 when-to-use or when-not-to-use guidance at all. With siblings like get_about and get_certifications that plausibly cover the same ground, an agent gets no rule for choosing get_profile over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive technical case study details for a specific project by slug, including problem, solution architecture, and verified metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The unique slug identifier of the project (e.g. 'pivotal-build', 'yubi', 'dcma') |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope context about what the payload covers (problem, architecture, metrics), but because an output schema exists it does not need to describe returns, and it says nothing about errors for an unmatched slug.
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?
One tight sentence with the verb and lookup key front-loaded. Slightly padded by 'comprehensive technical case study details', but no redundancy or wasted structure.
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?
A single-parameter read-only lookup backed by an output schema and full schema coverage — the description needs to do little, and it correctly conveys the content shape. The only gap is the absence of any guidance on behavior when the slug does not resolve.
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 the single slug parameter is documented with concrete examples ('pivotal-build', 'yubi', 'dcma'). The description adds nothing beyond the schema, so the baseline of 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 (retrieve) and resource (project case study details) scoped by slug, and enumerates the content returned (problem, solution architecture, verified metrics). It is clearly distinct from the list-style sibling get_projects, though it never names an alternative explicitly to draw that contrast.
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: the agent must infer that this is the call to make when it already holds a project slug, and that get_projects is the route when it does not. There is no when-to-use, when-not-to-use, or stated prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query verified enterprise production case studies, system blueprints, and business metrics across CBDC, DevOps, FinTech, and Cloud Engineering.
| Name | Required | Description | Default |
|---|---|---|---|
| tech | No | Filter by technology used (e.g. Kubernetes, Terraform, ArgoCD, GCP, AWS) | |
| limit | No | Max number of projects to return (default: 10) | |
| offset | No | Offset for pagination (default: 0) | |
| category | No | Category filter (e.g. FinTech, Consulting, Healthcare, Cloud Engineering) |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that — no mention of pagination behavior, result ordering, or what the query scope actually returns — so it contributes little on top of structured data.
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 with no redundant filler, which is appropriately sized for this tool. The phrasing is more marketing copy than specification, but nothing is wasted or buried.
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?
An output schema exists, so return-value explanation is not required, and annotations cover the read-only nature. However, for a four-parameter paginated list tool with a similarly named sibling, the description omits list semantics and sibling differentiation, leaving a real gap.
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%, so each of the four parameters is already documented, and convention sets the baseline at 3. The description loosely maps its domain list (CBDC, DevOps, FinTech, Cloud Engineering) onto the tech/category filters, but adds no syntax, default, or combination guidance 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 verb 'Query' and the domain-flavored resource ('verified enterprise production case studies, system blueprints, and business metrics') gesture at the content, but never plainly state that this returns a list of projects. It also fails to distinguish itself from close siblings like get_project_by_slug, so an agent cannot route confidently from the description alone.
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 when-to-use guidance, no mention of when to prefer get_project_by_slug or search_knowledge_base, and no stated prerequisites. The reader is left to infer usage entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check work availability. There are no active paid service offerings.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Filter by engagement model |
| Name | Required | Description |
|---|---|---|
| services | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds the useful content-state disclosure that no active paid service offerings exist, but says nothing about the response shape, pagination, or the optional tier filter's effect.
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 short sentences with no padding, and the potentially decisive fact (no paid offerings) is placed early. Slightly under-specified rather than verbose, but structurally clean.
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 an output schema present, return format needn't be explained, and the safety profile is in annotations. However, the vague purpose and absence of usage guidance leave real gaps for a tool whose relationship to its many get_* siblings is unclear.
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% and the single tier enum is fully described in the schema as "Filter by engagement model." The description adds no meaning beyond that, so the 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?
The name get_services implies listing offered services, but "Check work availability" describes something closer to an availability probe, and the second sentence is a content-state claim (no paid offerings) rather than a statement of what the tool returns. An agent cannot confidently tell whether this returns a service list, an availability flag, or an empty result set.
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 indication of when to call this versus siblings like get_profile, get_certifications, or get_projects, nor any prerequisites or exclusions. The only implied guidance is the negative framing about paid offerings, which does not route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query Zain Ahmed's exhaustive categorized technology stack across Kubernetes, Multi-Cloud, IaC, DevSecOps, Observability, and Agentic AI.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Skill category: all, multiCloud, containersAndOrchestration, infrastructureAsCode, ciCdAndGitOps, agenticAiAndMlOps, observabilityAndSre, securityAndCompliance, programmingLanguages |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that the stack is 'exhaustive' and categorized, without saying whether omitting the category returns everything or how results are grouped.
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 with no filler. It is efficient, though the long adjective phrase ('exhaustive categorized technology stack') is slightly padded relative to the content delivered.
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 an output schema present, return values need not be explained, and a one-optional-parameter read-only tool is simple. Still, the description omits when-to-use guidance and default behavior for the optional category, leaving minor gaps for an agent to resolve.
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%, so the category parameter and its accepted values are already fully documented in the schema; this is the baseline 3 case. The description's domain list (Kubernetes, Multi-Cloud, IaC, etc.) loosely mirrors the enum values but adds no syntax or default behavior 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 uses a specific verb ('Query') and resource ('categorized technology stack'), and lists the domains covered, so an agent knows what comes back. It does not, however, explicitly distinguish itself from sibling data-retrieval tools like get_certifications or get_profile, which also expose portfolio facts.
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 indication of when to call this instead of get_certifications, get_profile, or get_services, nor any note that the category parameter can narrow results. Usage is left entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all case studies, architecture articles, developer documentation, and platform capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword or phrase (e.g. 'Karpenter bin-packing', 'SOC 2', 'Antigravity', 'Zero-Trust') |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| articles | Yes | |
| projects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the searchable-content scope but says nothing about ranking, result limits, pagination, or match behavior that an agent would need to interpret results, so it only modestly exceeds the annotation baseline.
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?
One front-loaded sentence with zero filler; the searchable corpus is stated immediately after the verb.
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 an output schema present and annotations covering the safety profile, the definition is nearly complete for a one-required-param read tool. Only minor gaps remain around result behavior and when to fall back to the slug-based siblings.
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 the single query parameter is documented with concrete example phrases, so the schema carries the semantics. The description adds nothing about syntax, operators, or phrase matching beyond what is already structured.
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?
Specific verb ('Full-text search') plus an explicit enumeration of what is searchable (case studies, architecture articles, developer docs, platform capabilities). The 'search' action is clearly distinguished from the get_* siblings that retrieve known resources by slug.
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 broad scope implies 'use this for discovery when you don't have a slug', but the description never states when to prefer it over get_article_by_slug, get_articles, or get_services, nor any exclusion. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a real email inquiry; unavailable until delivery is configured. Reuse idempotencyKey for retries.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Sender name | |
| Yes | Sender email | ||
| company | No | Company or organization name | |
| message | Yes | Detailed inquiry message | |
| subject | No | Topic or inquiry subject | |
| idempotencyKey | No | Generate once per inquiry; reuse on retries. |
| Name | Required | Description |
|---|---|---|
| success | Yes | |
| referenceId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and destructiveHint=false; the description adds genuine context beyond that — that this dispatches a real outbound email, that it is gated on delivery configuration, and how to make retries safe. It still omits failure modes and whether repeated submissions with new keys create duplicates.
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?
One compact sentence with a semicolon clause: the action, the availability constraint, and the retry rule are all front-loaded with zero filler. Nothing could be removed without losing information.
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 a full output schema present, return values need not be explained, and 100% schema coverage handles parameters. The description supplies the two things structured fields cannot: the external side effect and the configuration precondition. It could still say how an agent detects the unconfigured state, but it is otherwise adequate.
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%, so all six parameters including the idempotencyKey pattern and retry semantics are already documented in the schema. The description's idempotency sentence duplicates what the idempotencyKey schema description already says, adding no new parameter meaning. 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 ('Submit a real email inquiry') and makes the side-effecting nature unmistakable, which naturally distinguishes it from the twelve read-only sibling tools. It stops short of explicitly contrasting itself with any named alternative, but the purpose 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?
Gives a real precondition ('unavailable until delivery is configured') and explicit retry guidance ('Reuse idempotencyKey for retries'), which is more than most tools offer. It does not name when to prefer another tool or state hard exclusions beyond the configuration gate.
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_about1 field changedInput schema / properties / sectionAdded value: +{
+ "description": "Filter about section: all, philosophy, principles, story",
+ "enum": [
+ "all",
+ "philosophy",
+ "principles",
+ "story"
+ ],
+ "type": "string"
+}get_certifications1 field changedInput schema / properties / providerAdded value: +{
+ "description": "Filter certifications by cloud provider: all, AWS, Azure, GCP, OCI, HashiCorp",
+ "enum": [
+ "all",
+ "AWS",
+ "Azure",
+ "GCP",
+ "OCI",
+ "HashiCorp"
+ ],
+ "type": "string"
+}calculate_finops_roigenerate_architecture_manifestget_aboutget_article_by_slugget_articlesget_certificationsget_profileget_project_by_slugget_projectsget_servicesget_skillssearch_knowledge_basesubmit_contact
Add one secure layer between your agents and this server.