GitHub’s October 28 connector announcement makes connecting external services to Copilot simpler: sign in once and use their tools across supported surfaces. For a directory builder, a useful next test is surprisingly ordinary. Put two people named Alex in the results and ask the assistant about one of them. Does it keep their biographies, links, and interests separate, or assemble a convincing person who does not exist?
Disclosure: This article was generated and fact-checked with AI using the public sources linked here. It was published through an automated workflow and has not been reviewed by Keith.
GitHub-verified MCP servers, also called connectors, are rolling out in public preview. The connector documentation explains the shared setup and organization controls. This concerns supported connectors and surfaces; it is not a promise that every custom MCP server is included.
Give each result a durable reference
AfroTech Guide’s public case study describes an independent community guide with approved people and events, conversational discovery, comparisons, and editable introduction drafts. Record identity and validation carry through its connected workflows. Private account and contact information are kept separate from approved public records.
The official AFROTECH speaker profile also documents the guide’s MCP integration with ChatGPT and Claude. That provides context for this example; it does not establish inclusion in GitHub’s connector preview or official ownership of the independent guide.
Consider a synthetic directory result with two records. Alex Morgan, record P101, works on accessible interfaces. Alex Morgan, record P202, runs a community food project. Both names and descriptions here are fictional. The records are distinct even though the display names match.
A proposed search response should return a stable reference alongside each name and useful public distinctions. Later lookup and comparison operations should accept that reference. Repeating the name as the only lookup input would recreate the ambiguity at every step.
The exact fields and identifiers in this example are a proposed design exercise, not a description of the guide’s current response schema.
Keep the facts attached to their source record
The assistant needs enough context to help the user choose. Displaying two identical names with hidden IDs would satisfy a database constraint while leaving the person stuck.
Show a short distinguishing description and a link to the corresponding approved profile. Keep the same distinctions in the information returned to the assistant. When the user asks about “the Alex working on accessibility,” the selected reference should resolve to P101, and the answer should use that record’s facts.
A useful test checks more than whether P101 appears in a tool call. It checks whether the resulting explanation accidentally borrows P202’s project, links, or biography. The wrong combination can look polished because every individual fact came from a real-looking record.
Do not make every field mandatory just to create a neat comparison. If P101 has no public organization listed, leave that information unknown. Filling the gap from P202 would make the result more complete-looking and less accurate.
Ask a question that separates the choices
Sometimes the request provides no distinguishing clue. “Tell me about Alex Morgan” should produce a concise clarification when the result set contains both people.
A good clarification gives the user a useful choice: the accessibility practitioner or the community food organizer. It should use approved public information and avoid exposing private details merely to tell records apart.
Clarification has a cost. Asking again when the user already supplied an unambiguous description wastes a turn. The goal is to resolve genuine uncertainty, then retain the chosen reference through the current task. A small test set can include both ambiguous requests and requests with a clear public distinction.
This is also where search ranking needs careful interpretation. A first result can be a reasonable candidate without being a confirmed identity. Ranking and identification answer different questions.
Test the mixed answer, not just the lookup
Run the synthetic pair through search, detail lookup, comparison, and introduction drafting. Check that every claim and profile link stays attached to the intended record. The introduction remains a draft for the user to inspect; this exercise does not send messages.
Then change one display name while preserving its record reference. The workflow should continue to identify the same record. Separately, present an unknown reference and check that the application reports the lookup failure instead of silently substituting the nearest name.
These are proposed acceptance checks, not reported test results from AfroTech Guide. They are small enough to repeat after changing a tool description, a search response, or a host integration.
Easier connector setup can bring more external information into an assistant’s reach. The practical value comes when the answer remains tied to the right entity. A person using a community directory should be able to choose the right Alex, open the right profile, and draft an introduction about that person without auditing a merged biography.
Top comments (0)