Skip to main content
Glama
Sign In

Shlok Bam's portfolio

by io.github.shlokbam
OverviewDiscussionsAdmin

List projects

list_projects
Read-onlyIdempotent

List Shlok's projects in order of importance (the first five are flagships). Each entry has name, slug, field, one-line summary, tech stack, live demo and code links, its page on the portfolio, and live GitHub details (stars, language, topics, last update) when the code is in a public repository. Filters combine (all must match); a filter that matches nothing returns count 0, not an error. GitHub details are cached up to 6 hours and are missing for private repositories or when GitHub can't be reached. Use get_project for one project's full write-up and metrics, and search_portfolio for topics that are not projects (a skill used at work, an award).

Input Schema

NameRequiredDescriptionDefault
techNoOnly projects using this technology: case-insensitive, matched as part of each tech name and of the write-up, so "lang" finds LangGraph and LangChain. Examples: "LangGraph", "React", "AWS". Empty for all.
categoryNoOnly one kind of project: "ai" (AI, ML and agents), "web" (full-stack and web apps), "devops" (CI/CD and infrastructure), "cloud" (serverless and cloud services), or "all". A project can be in more than one.all
flagship_onlyNoOnly the five flagship projects (his most important work). Combines with the other filters.
include_other_reposNoAlso return otherRepos: his public GitHub repositories the portfolio doesn't feature (forks left out), with GitHub's description, language, stars and last update.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / category / default
      Previous value: -""New value: +"all"
    • changedInput schema / properties / category / description
      Previous value: -"Only this kind of project: \"ai\", \"web\", \"devops\" or \"cloud\". Leave empty for all."New value: +"Only one kind of project: \"ai\" (AI, ML and agents), \"web\" (full-stack and web apps), \"devops\" (CI/CD and infrastructure), \"cloud\" (serverless and cloud services), or \"all\". A project can be in more than one."
    • addedInput schema / properties / category / enum
      Added value: +[
+  "all",
+  "ai",
+  "web",
+  "devops",
+  "cloud"
+]
    • changedInput schema / properties / flagship_only / description
      Previous value: -"Only the five flagship projects."New value: +"Only the five flagship projects (his most important work). Combines with the other filters."
    • changedInput schema / properties / include_other_repos / description
      Previous value: -"Also list his public GitHub repositories that the portfolio doesn't feature."New value: +"Also return otherRepos: his public GitHub repositories the portfolio doesn't feature (forks left out), with GitHub's description, language, stars and last update."
    • changedInput schema / properties / tech / description
      Previous value: -"Only projects using this technology, e.g. \"LangGraph\", \"React\", \"AWS\". Leave empty for all."New value: +"Only projects using this technology: case-insensitive, matched as part of each tech name and of the write-up, so \"lang\" finds LangGraph and LangChain. Examples: \"LangGraph\", \"React\", \"AWS\". Empty for all."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses that filters are conjunctive, that a zero-match filter yields count 0 rather than an error, and that GitHub details are cached up to 6 hours and absent for private repos or when GitHub is unreachable. Those failure modes and staleness bounds are exactly the context an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and ordering come first, then the shape of each entry, then filter semantics, then caveats, then alternatives to sibling tools. Every sentence carries non-redundant information, including the entry-composition sentence, which compensates for the absent output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes on the burden of describing return fields (name, slug, field, summary, tech stack, links, GitHub stars/language/topics/last update) and does so. Combined with caching behavior and the empty-result contract, an agent has everything needed to call this and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so tech, category, and the two booleans are already fully documented, and the description adds little per-parameter detail. The one addition is the cross-parameter rule that all filters must match, which the schema states only for flagship_only, so this sits at the high-coverage baseline with a small increment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ("List Shlok's projects") plus scope and ordering ("in order of importance (the first five are flagships)"). It also separates itself from get_project and search_portfolio by name, so an agent can route without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The final sentence gives explicit alternatives and the condition that selects each: get_project for a single project's full write-up and metrics, search_portfolio for non-project topics like a skill or award. That is a genuine when-to-use/when-not-to-use split rather than an implied one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Shlok Bam's portfolio toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources