Agent Know-How

Morgan Stanley models its API program with Architecture as Code (the CALM framework) and generates Model Context Protocol and Agent-to-Agent (A2A) integration surfaces from that description, with governance enforced through deployment gates.

Agent-callable tooling becomes a byproduct of API governance already in place, not a separate integration project with its own servers to hand-write.

Lovable is branching into MCP-powered "capabilities", which CTO Fabian Hedin defines as a part of an application an agent can call directly without a human opening the app. A published app gets two interfaces: the human UI and an MCP endpoint any MCP client can call.

A connector gateway keeps credentials server-side and encrypted; generated app code gets a short-lived key scoped to one user instead of a secret. The protocol argument now reaches the individual SaaS app, not only infrastructure vendors.

AWS and co-authors describe agentic overlays: thin wrapper layers in front of existing REST services that expose them as MCP-compatible tools and let them take part in Agent-to-Agent (A2A) interactions, without changing the underlying system.

This is the brownfield answer to "rebuild agent-native". It trades the cleanliness of purpose-built endpoints for reuse of what already runs in production.

RFC AI Tooling exposes the IETF RFC corpus to agents two ways, as a skill and as an MCP server, both backed by the same stdlib-only Python core. Documents are fetched from the RFC Editor on demand, and obsoleted specs are flagged so agents stop citing dead ones. The author reports a median 41x saving (tokens approximated as bytes divided by 4; single-repo, self-measured).

Takeaway: a thin find-read-flag interface over a large reference corpus beats pasting documents into context. A skill and an MCP server can share one core instead of two implementations.

SkillBrowser targets Selective Skill Exposure: loading procedural skill content only when needed. Progressive disclosure lists metadata for the whole library and pollutes context. Static retrieval from the initial task query misses needs that emerge mid-reasoning.

A meta-skill has the agent name its current capability need, issue a targeted query, and load matching skills on demand. Across six SRA-Bench subsets and five LLMs (paper-reported), it improves aggregate accuracy over static retrieval and LLM-based selection, and limits accuracy loss on instances the model already solves.

The authors report model- and task-dependent gains, under-invocation of useful skills, and added latency. Large skill libraries need a retrieval step the agent controls, not a catalog dumped into the prompt.

Codex 0.151.0 adds a configurable grace period for discovering tools from optional MCP servers, and lets extensions inspect or replace an MCP tool's result before it reaches the model.

The result hook is a client-side filter on the tool-call path: a place to trim oversized payloads or redact fields without changing the server.

Funnel A/B-tested GLM-5.2 against Claude Opus 4.8 on its internal data agent (self-reported). GLM answered each model call faster (7.8s vs 18.1s) but made 66% more tool calls (19 vs 11) and finished tasks 14% slower end to end. Twice it reran the same successful query 113 and 254 times, because the tool returned only a 20-row preview and the model never recognized the limit.

Funnel traced it to the harness: ambiguous tool contracts, saved instructions naming tables that did not exist, and no repeated-call guard. For builders: label previews versus complete results, detect repeated equivalent calls, and cap execution budgets before swapping models.

A developer exposed an ask_user MCP tool (speak a question, listen for the answer) to Claude Code. The agent used it in one project and printed the question on screen in the next, same machine, same day, even though it could quote the instruction back word for word.

This is a single practitioner report, not a controlled study. It shows that registering a tool and instructing its use does not guarantee invocation.

For builders: log tool-call rates per project or prompt context, and test that a tool is actually called, not just available.

Tool descriptions, argument schemas, and the candidate tool list often change after deployment while tool semantics stay fixed. A paper calls this interface drift and tests SchemaShield-Lite: schema validation, a candidate-set retry when the tool name is missing, and one-shot constrained repair, with no retraining.

On Qwen3.5-9B (paper-reported), BFCL-200 accuracy rises from 0.580 to 0.805 and DICE-300 from 0.717 to 0.813. It recovers 33 of 45 and 19 of 22 drift-induced failures with no observed repair harms. Naive retry does not explain the gain. Distractor tools in the candidate set cause most of the damage.

For builders: validate every call against the live schema and keep the candidate list stable.

AWS open-sourced Dogwood (Apache 2.0), which adds temporal operators to Cedar: formerly, count_within, count_distinct_within, sum_within. Rules can read prior tool calls instead of judging one request alone. It is supported in AgentCore Policy, but the reference interpreter is not production-ready.

The motivating case: a $5,000 transfer cap that checks settled responses is defeated by concurrency, because three simultaneous $2,000 requests all pass. The rule must count requests within a time window.

The cost is real: temporal evaluation needs stateful event tracking and gives up Cedar's automated formal-reasoning guarantees.

A Show HN plugin brings the formal-verification work in "Guardians of the Agents" (Erik Meijer; implemented by Nada Amin) to OpenCode. It hooks tool.execute.before to intercept candidate bash, read, edit, and write calls and verifies them statically before execution.

It is a pre-execution check, complementary to sandboxing and authorization, which limit what happens after a call runs. See agent sandboxing.

Jake Mannix proposes an intermediate protocol layer that turns raw APIs into versioned, encapsulated "virtual tools", with interface mapping, dynamic schema projection, and runtime taint tracking to catch data-exfiltration risk at the tool boundary.

This is one engineering leader's architecture, not a benchmarked result. It targets ungoverned tool sprawl through versioning and data-flow tracking rather than schema hygiene alone.

DoorDash built a multi-agent system to clean up stale flags across more than 60,000 flags and 623 repositories. It pulls live experimentation data through MCP, gates each cleanup on engineer approval, and runs parallel agents in isolated Git worktrees with automated validation.

In an evaluation of 50 flags, 45 produced usable pull requests at an average of 13.8 minutes and $4.79 per cleanup (company-reported). MCP here is the access layer into internal engineering systems, not a customer-facing feature.

Ask DoorDash splits work across specialized agents, MCP-based tooling, and a separate intelligence layer with persistent consumer memory and live backend data, rather than one model deciding everything. DoorDash reports up to 24% higher checkout conversion and 17% larger baskets from memory-backed sessions (company-reported).

The pattern narrows what the model owns: deterministic and specialized components carry the task, and the LLM routes and talks.

Azure Functions shipped a serverless agents runtime in public preview at Build 2026. An agent is an .agent.md file with YAML triggers, MCP server access, 1,400+ connectors, and sandboxed execution. The Functions team told InfoQ the runtime adds no cold-start overhead and no billing premium beyond standard Flex Consumption (vendor-reported).

MCP access becomes a default runtime feature rather than something each team wires in, and the cloud platform takes over hosting the tool loop.