AI recruiting for mission-aligned engineers — verified across GitHub, X, YouTube, Medium, and more
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: find_candidates for open-source engineers, find_defense_engineers for DoD award holders, find_mechanical_engineers for NASA report authors, find_research_engineers for ORCID researchers, find_similar_projects for project similarity, and get_profile for individual lookup. Descriptions explicitly warn about non-overlap, preventing agent confusion.
All tool names follow a consistent verb_noun pattern: find_candidates, find_defense_engineers, find_mechanical_engineers, find_research_engineers, find_similar_projects, get_profile. No mixing of styles or vague verbs.
With 6 tools covering multiple specialized engineer categories, project discovery, and profile retrieval, the number is well-scoped for the server's purpose. Each tool earns its place without redundancy or excess.
The tool surface covers major engineer types (open-source, defense, mechanical/aerospace, international research) and includes project similarity and profile lookup. Minor gaps like missing direct company search or skill-based filtering exist but are mitigated by the detailed descriptions and the problem parameter in find_research_engineers.
find_candidatesARank engineers for a role or project by their verified open-source contributions and other public work.
Input: pass the richest context you have — (1) a full job description (most common), (2) a synthesized brief after reviewing a company's public repo (README + stack + role needs — preferred over a bare URL when you've evaluated the project), (3) a public github.com repo URL (server fetches README/topics; private repos → paste README as text), or (4) an informal role brief. Longer, more specific input ranks better. Optional location narrows to a city, country, or ISO country code.
Returns up to limit ranked candidates (default 20, max 50) with full inline profiles in structuredContent (view=candidates): login, name, bio, location, followers, reach (cross-platform audience percentile + reach), html_url, top_repos, top_topics, signals, matched_projects, location_match, and contact.
Results never include bots, CI, or service accounts — they are filtered out automatically. Use the optional exclude array (GitHub logins or org names) to drop additional accounts.
AGENT MODE: consume structuredContent only. HUMAN MODE: MCP App panel shows candidate cards; use server instructions for text-only hosts.
Do not call get_profile for handles already in these results unless the user asks for deeper detail.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Search brief: full JD, repo-derived summary (preferred when you've reviewed the project), README excerpt, informal role brief, or a PUBLIC github.com repo URL. Private repos: paste README content as text. | |
| limit | No | Max candidates to return. Default 20, max 50. | |
| exclude | No | Optional. GitHub logins or org names to exclude from results (case-insensitive). Matches a candidate's login AND the owner/org of every repo they matched on — so passing a company's GitHub org (e.g. "livekit", which also covers "livekit-cloud") keeps that company's own engineers out of a shortlist you're building FOR them. Also use it to suppress specific handles you've already contacted. Bots and CI/service accounts are excluded automatically and need not be listed. | |
| location | No | Optional. Restrict results to a place — a city ("Berlin"), country name ("Germany"), or ISO country code ("US"). Matched against the candidate's stated and normalized location. Only pass it when the user explicitly requires a location; results are then hard-filtered to matches. Note ~30% of profiles have a usable location, so a strict location search returns a smaller pool. |
| Name | Required | Description |
|---|---|---|
| view | No | Payload discriminator for MCP App hosts |
| query_ms | No | End-to-end query time in milliseconds |
| candidates | Yes | Ranked engineer candidates, strongest fit first. When presenting to the user, format each item using FindCandidatesPresentationTemplate from server instructions — list every contact.urls entry and every email verbatim. |
| total_count | Yes | Count of candidates returned (≤ requested limit) |
| cache_source | No | |
| precision_gate | No | Whether the LLM precision screen ran. "on" means results were filtered for relevance; "off" means raw retrieval order; "failed_open" means the screen was requested but unavailable, so results are un-gated — treat those with the same caution as "off". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. The description adds valuable behavioral context: automatic filtering of bots/CI/service accounts, the effect of location on pool size, and that longer input ranks better. No contradictions.
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 well-structured with clear sections, but slightly verbose in places (e.g., agent vs. human mode could be shorter). Still, every sentence adds value and it's front-loaded with the core purpose.
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?
Given the tool's complexity (ranking, multiple input types, optional filters, output structure), the description covers all essential aspects: input formats, filtering behavior, return content (structuredContent fields), and usage constraints. No gaps identified.
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 description significantly enhances each parameter: explains why longer input ranks better, how exclude matches both login and org, gives location restrictions and pool size caveat, and clarifies limit default and max.
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 ('rank') and resource ('engineers by verified open-source contributions and other public work'), clearly distinguishing it from sibling tools like find_defense_engineers (domain-specific) and get_profile (individual profile retrieval).
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?
Provides explicit guidance on when to use the tool and alternatives: lists four input types with preference order, explains when to avoid get_profile, and gives detailed instructions for optional parameters (location, exclude) and output consumption per mode (agent vs. human).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_defense_engineersASearch 41,811 named engineers who hold U.S. Department of Defense SBIR/STTR research awards — the federal record of who was funded to build what. Use for defense, aerospace, hypersonics, photonics, materials, autonomy and adjacent hard-tech roles.
IMPORTANT: this is a SEPARATE population from find_candidates, not a filter on it. These people are identified by federal award records, not by GitHub contributions, and the two sets barely overlap. Call find_candidates for software engineers with open-source history; call this for engineers whose verifiable work is DoD-funded R&D.
Each result carries the actual award titles, branch (DARPA, Navy, Army, Missile Defense Agency, SOCOM...), years active and firm, so the claim is checkable on a public government award page.
An award evidences DoD-funded work. It is NOT a security clearance and must not be described as one. No contact details are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 20. | |
| query | No | Free-text subject matched against everything the person was funded to build ("hypersonic", "quantum sensing", "corrugated horn antenna"). Technical terms work best — matching is lexical, so exact terminology beats paraphrase. | |
| state | No | Firm's U.S. state, e.g. "California". | |
| branch | No | DoD component, spelled as the federal record does: "Defense Advanced Research Projects Agency", "Navy", "Army", "Air Force", "Missile Defense Agency", "Special Operations Command". | |
| min_awards | No | Require at least this many defense awards — depth rather than one match. | |
| since_year | No | Only people with an award in or after this year. |
| Name | Required | Description |
|---|---|---|
| people | Yes | |
| source | No | The record these results come from, safe to cite. |
| synced_at | No | When this population was last mirrored. Surfaced so freshness is visible rather than assumed. |
| population | No | Which population was searched: sbir_defense. |
| total_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description explains that results carry award titles, branch, years, firm, that awards are not security clearances, and that no contact details are returned, adding valuable behavioral context.
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 concise (about 5 sentences), front-loaded with purpose, then usage guidelines, then result details, with no superfluous 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?
Given the presence of an output schema, the description adequately explains that each result contains award titles, branch, years, firm, and that no contact details are returned, covering all necessary context for the 6-parameter search 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?
Even with 100% schema description coverage, the description adds useful usage nuance: technical terms work best, matching is lexical, and provides example values for branch and state, going beyond what the schema alone conveys.
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 explicitly states it searches for engineers with DoD SBIR/STTR awards, specifying the domain and distinguishing it from find_candidates by noting it's a separate population based on federal awards rather than GitHub contributions.
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?
Provides clear guidance on when to use this tool (for DoD-funded R&D engineers) versus find_candidates (for software engineers with open-source history), and includes warnings about not confusing awards with security clearances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_mechanical_engineersASearch 21,061 named mechanical, aerospace, structural, thermal and materials engineers who author NASA technical reports. Use for turbomachinery, propulsion, composites, structures, tribology, thermal systems, additive manufacturing and flight hardware roles.
IMPORTANT: this is a SEPARATE population from find_candidates, not a filter on it. These are engineers whose work appears in technical reports rather than code — the disciplines that leave almost no trace on GitHub (the whole corpus holds 5 projects tagged SolidWorks). Call find_candidates for software; call this for people who design hardware.
Set industry_only=true to exclude NASA civil servants and return only engineers whose CURRENT employer is a contractor or university (Jacobs, Boeing, Aerojet Rocketdyne, Analytical Mechanics Associates...). Prefer since_year >= 2020: report volume is front-loaded, so a person last published in 2016 may be a decade stale.
Each result carries actual report titles, subject categories, employer and years active. No contact details exist in this source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 20. | |
| query | No | Free-text subject matched against report titles and keywords ("turbomachinery bearings", "composite structures", "thermal protection"). | |
| subject | No | NASA subject category, e.g. "Mechanical Engineering", "Structural Mechanics", "Composite Materials", "Fluid Mechanics and Thermodynamics", "Aerodynamics". | |
| since_year | No | Only people with a report in or after this year. Prefer 2020 or later. | |
| min_reports | No | Require at least this many reports. | |
| industry_only | No | Exclude NASA civil servants; return only engineers whose CURRENT employer is a contractor or university. Usually what you want for hiring. |
| Name | Required | Description |
|---|---|---|
| people | Yes | |
| source | No | The record these results come from, safe to cite. |
| synced_at | No | When this population was last mirrored. Surfaced so freshness is visible rather than assumed. |
| population | No | Which population was searched: ntrs_mechanical. |
| total_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context: this is a separate population from find_candidates, no contact details exist, and results include report titles and years active. No contradictions.
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?
Three paragraphs, each serving a distinct purpose: first defines the tool and its scope, second provides usage guidance, third explains key parameters. Slightly verbose but well-organized and front-loaded with the most critical information (IMPORTANT note).
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?
Given the tool has 6 parameters (0 required), full schema coverage, annotations, and an output schema, the description is complete. It covers parameter usage, limitations (no contact details), result contents, and clear differentiation from 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 coverage is 100%, so baseline is 3. The description adds meaning beyond schema: explains that 'industry_only' excludes NASA civil servants (useful for hiring), recommends 'since_year >= 2020' due to front-loaded report volume, and clarifies that 'query' matches against report titles and keywords.
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 ('Search') and clearly identifies the resource ('21,061 named mechanical, aerospace, structural, thermal and materials engineers who author NASA technical reports'). It distinguishes from the sibling 'find_candidates' by noting this is a separate population for hardware roles vs software.
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?
Explicitly states when to use this tool ('people who design hardware') and when not to ('call find_candidates for software'). Provides guidance on setting 'industry_only=true' for hiring and preferring 'since_year >= 2020' to avoid stale results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_research_engineersASearch 221,000+ named engineers and researchers worldwide, discovered from the ORCID registry across photonics, robotics, semiconductors, control systems, materials, aerospace, power electronics, remote sensing and adjacent deep-tech disciplines.
THIS IS THE INTERNATIONAL POPULATION. The other people-search tools are anchored to the United States or to GitHub: find_defense_engineers is U.S. DoD by definition, find_mechanical_engineers is NASA, and find_candidates only sees people who publish code. Use this one when the role is not U.S.-bound, or when the discipline is hardware or physics rather than software.
TO TARGET A REGION, country and institution both work. country is an ISO alpha-2 code resolved from the person's enriched profile where available and otherwise from their employer's registered address via ROR; every result reports location_source so you can tell which. institution matches the employer name as a substring ("Fraunhofer", "KAIST", "ETH", "Indian Institute of Technology", "RIKEN") and is the sharper filter when you want a specific lab rather than a country.
IMPORTANT: this is a SEPARATE population, not a filter on find_candidates. Evidence here is published work and institutional affiliation — papers, citations, h-index, employer — NOT commits. Most of these people have no GitHub account. Every result carries has_github so you can tell; when it is false you MUST NOT describe them as a verified open-source contributor, because we have no such evidence.
Publication metrics are present only for people already enriched via OpenAlex; works_count 0 means "not yet looked up", not "has published nothing". Do not read a zero as a negative signal.
TO FIND PEOPLE WORKING ON A SPECIFIC PROBLEM, use problem — a free-text description of the technical problem, not keywords. It searches what these people actually WROTE (paper titles and abstracts) using hybrid semantic + lexical retrieval, so "integrated optical interconnects for datacenter switching" finds silicon-photonics researchers even though those exact words appear in none of their titles. Results carry the specific papers that matched, so the match is checkable rather than a score to trust. Use the other filters to NARROW a problem search, not instead of it.
No contact details are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 20. | |
| query | No | Free-text matched against name, employer, affiliation history and research field ("silicon photonics", "model predictive control", "metamaterials"). Matching is lexical, so exact technical terminology beats paraphrase. | |
| country | No | ISO 3166-1 alpha-2 code ("DE", "JP", "KR", "CH", "IL", "SG", "IN"). Resolved from the person's enriched profile when we have it, otherwise from their employer's registered address. Each result reports location_source so you can distinguish the two. Not every person has a resolved country; those are excluded when you filter on it. | |
| problem | No | Describe the TECHNICAL PROBLEM in a sentence or two, as you would to a colleague ("reducing insertion loss in silicon nitride waveguide couplers", "model predictive control for legged locomotion on uneven terrain"). Searches paper titles and abstracts semantically, so it finds people whose work matches the problem even when their wording differs. Prefer this over `query` when you know what the role needs to SOLVE. | |
| min_works | No | Require at least this many published works. Note that 0 means unenriched, so a minimum also excludes anyone not yet looked up. | |
| discipline | No | Restrict to how the person was discovered, e.g. "keyword:photonics", "keyword:robotics", "affiliation-org-name:\"Fraunhofer\"". Narrower and more literal than `query`; use it when you want a clean discipline cohort. | |
| since_year | No | Only people who published in or after this year. Prefer 2020 or later to avoid stale profiles. | |
| institution | No | Employer or affiliation, matched as a substring — "Fraunhofer", "KAIST", "ETH", "TU Delft", "RIKEN", "Indian Institute of Technology". THE PREFERRED way to target a region or lab: it comes straight from ORCID and covers ~213,000 of ~221,000 people. Matches historical affiliations too, since a current employer is often not the first entry. | |
| industry_only | No | Exclude academic institutions and return only people whose CURRENT employer is a company or research facility. Usually what you want for hiring. |
| Name | Required | Description |
|---|---|---|
| count | No | |
| people | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, idempotent hints. The description adds value beyond: separate population, location_source, has_github, works_count handling, semantic search capabilities, and no contact details. No contradiction.
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 long but well-structured with sections and bullet points. Every sentence adds value, but slight conciseness could be improved 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?
Given 9 parameters and nuanced behavior, the description covers international scope, sibling distinctions, parameter usage, edge cases (unenriched), and notes on returned data. Output schema exists, so return values are covered.
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 all parameters are described. The description adds extra context: country is ISO alpha-2, institution substring match, problem for technical description, min_works caution. This adds value beyond 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 clearly states the tool finds engineers worldwide from ORCID, using verb 'search' with a specific resource. It distinguishes from siblings by noting international scope vs US-bound tools, and hardware/physics vs software focus.
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 explicitly states when to use this tool ('not U.S.-bound, hardware or physics'), compares alternatives, provides parameter guidance (e.g., 'country is ISO alpha-2', 'institution matches substring'), and warns about caveats like min_works meaning unenriched.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_similar_projectsAFind open-source projects similar to a seed GitHub repo, ranked by semantic similarity to its description/topics/README. Each result includes top contributors as leads — not JD-ranked candidates. Returns structuredContent (view=similar_projects). Agents: consume structuredContent only.
Use for landscape mapping or to discover anchor repos; follow with find_candidates for hiring matches.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | Seed repo in `owner/name` form (e.g. 'karpathy/llm.c'). A full github.com URL is also accepted; the server strips the prefix. | |
| limit | No | Number of similar projects to return. Defaults to 10, max 25. |
| Name | Required | Description |
|---|---|---|
| seed | No | The owner/name searched against |
| projects | Yes | Similar projects, ranked by vector similarity to the seed repo. |
| query_ms | No | |
| total_count | No | |
| cache_source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that results include top contributors as leads (not JD-ranked candidates), which is behavioral context beyond annotations. It also mentions the output is structuredContent for consumption. No contradictions.
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 concise with 3 purpose sentences and a brief usage line. No unnecessary words. Front-loaded with main action and result format. Efficient and well-structured.
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 2 parameters, rich annotations, and an output schema (mentioned but not shown), the description covers all necessary aspects: purpose, usage guidelines, result content, and instruction for consumption. It is complete for an agent to select and invoke correctly.
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 baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions; it only restates the 'owner/name' form from the schema. No additional semantic clarification needed.
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 clearly states the tool finds open-source projects similar to a seed GitHub repo, ranked by semantic similarity. It specifies the input (seed repo), the ranking method (description/topics/README), and what results include (top contributors as leads). It distinguishes from sibling tools like find_candidates, which is for hiring matches.
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?
Explicitly states use cases: landscape mapping or discovering anchor repos. Provides a clear alternative: 'follow with find_candidates for hiring matches'. Also instructs agents to consume structuredContent only, which guides proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileAFetch one contributor's profile card for a GitHub handle not already returned by find_candidates — e.g. the user names a specific person, references an external handle, or wants verification before outreach. find_candidates already returns full inline profiles; use get_profile only for handles outside those results or when the user asks for deeper detail.
Returns structuredContent (view=profile). Agents: consume structuredContent only.
IMPORTANT — interpreting recent_activities: indexed GitHub activity in the current ingestion window (2025–2026), up to ~20 events per recent project. NOT a complete career history. Empty or older activity does not mean inactive.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The GitHub handle to look up. Plain login name, no '@' prefix (e.g. 'karpathy', not '@karpathy'). |
| Name | Required | Description |
|---|---|---|
| bio | No | |
| name | No | |
| No | ||
| company | No | |
| html_url | No | Profile URL on GitHub |
| location | No | |
| followers | No | |
| avatar_url | No | |
| login_name | Yes | GitHub handle |
| display_name | No | |
| public_repos | No | |
| top_projects | No | Highest-contribution projects this user worked on |
| profile_readme | No | User's profile README content if present |
| social_accounts | No | Social URLs (twitter, linkedin, etc.) |
| recent_activities | No | Indexed GitHub events from current ingestion window (2025–2026). NOT a full career timeline. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, etc. Description adds key behavioral context: returns structuredContent, interprets recent_activities as limited to current ingestion window (2025–2026, up to ~20 events per project), and clarifies empty/older activity does not mean inactive.
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 well-structured and informative, but slightly verbose in the third paragraph. Every sentence adds value, but could be tightened slightly for conciseness.
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 good annotations and a single parameter, the description covers purpose, usage, behavioral traits, parameter clarification, and output handling. The existence of an output schema further supports completeness.
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?
Single parameter 'handle' has 100% schema coverage. Description adds value by specifying 'Plain login name, no '@' prefix' and gives examples ('karpathy', not '@karpathy'), clarifying usage 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 clearly states 'Fetch one contributor's profile card' and distinguishes from sibling 'find_candidates' which returns full profiles. It specifies the tool is for handles not already returned or when deeper detail is needed.
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?
Explicitly tells when to use (handles outside find_candidates results or deeper detail requested) and when not (find_candidates already returns inline profiles). Also provides agent instruction to consume structuredContent only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
