DevMatch

get_profile

Read-onlyIdempotent

Fetch one contributor's profile card by GitHub login, ORCID iD (or orcid.org URL), or a find_candidates id (source:name such as ntrs:Ada Lovelace). Do not invent a GitHub handle for research or deep-tech people — pass their id. find_candidates already returns full inline profiles; use get_profile only for ids 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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No	Alias for handle. Pass a find_candidates `id` (GitHub login, ORCID iD, or source:name).
`handle`	Yes	Person to look up: a GitHub login (no '@'), an ORCID iD or https://orcid.org/<id> URL, or a find_candidates id (source:name such as ntrs:Ada Lovelace). Do not invent a GitHub handle for research or deep-tech people.

Output Schema

TableJSON Schema

Name	Required	Description
`bio`	No
`name`	No
`email`	No
`company`	No
`html_url`	No	Profile URL (GitHub or https://orcid.org/<id>)
`location`	No
`followers`	No
`person_id`	No	Stable lookup key: GitHub login, ORCID iD, or source:name.
`avatar_url`	No
`login_name`	Yes	GitHub handle. Empty for ORCID and source:name people — use person_id.
`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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, and open-world hints, so the safety profile is established. The description adds crucial interpretation context: recent_activities is limited to the 2025–2026 ingestion window, ~20 events per project, not a full career history, and empty/older activity does not imply inactivity. This directly prevents misreading returned data.

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?

Three purposeful paragraphs, front-loaded with the core function and identifier options. The usage contrast with find_candidates, the structuredContent consumption note, and the recent_activities interpretation warning all earn their place. No filler or repetition.

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?

Covers the tool's purpose, accepted identifier forms, when to use it versus find_candidates, how to consume output, and a subtle data-interpretation pitfall. With an output schema and rich annotations present, nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the three accepted input forms (GitHub login, ORCID iD/URL, find_candidates id) and adds the rule 'Do not invent a GitHub handle for research or deep-tech people — pass their id,' which adds meaningful selection guidance beyond the schema descriptions.

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?

States a specific verb ('Fetch') and resource ('one contributor's profile card'), enumerates accepted identifier forms, and explicitly contrasts with find_candidates. An agent can tell it apart from siblings immediately without opening the 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?

Explicitly says when to use this tool: for ids outside find_candidates results or when the user asks for deeper detail. It also warns against inventing GitHub handles for research or deep-tech people, giving a clear exclusion rule.

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

All DevMatch tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a distinct role: find_candidates searches for people, find_similar_projects maps repos, and get_profile retrieves a single known profile. The only potential overlap (find_candidates already returns profiles) is explicitly resolved with guidance not to call get_profile unless deeper detail is needed.

Naming Consistency5/5

All tool names follow a consistent find_/get_ verb-noun pattern. The naming clearly communicates the action (search vs retrieve) and the object (candidates, similar_projects, profile).

Tool Count5/5

Three tools is a tight, focused set for this server's purpose: candidate discovery, project landscape mapping, and individual profile lookup. Each tool is independently useful and there are no redundant or filler tools.

Completeness4/5

The core workflow is covered: find candidates, discover similar projects, and fetch deeper profile details. A minor gap is the lack of direct project-detail retrieval or broader project search, but agents can work around this via find_similar_projects and get_profile.

Resources

Need Help?